SSL kendi altında güvenilir bir protokole ihtiyaç duyar, bu
da TCP protokolü. Dolayısıyla SSL iletişiminden bahsedebilmek için öncelikle
TCP 3-way handshake ile TCP bağlantının kurulması gereklidir. Paket
dosyasındaki ilk 3 paket 3-way handshake mekanizmasına ait. TCP bağlantı
kurulduktan sonraki aşama SSL Handshake’tir. Bunu da en basit haliyle aşağıdaki
resmi kullanarak tarif edilenecek.
SSL self-delimiting bir protokol olması nedeniyle birden fazla mesajı (2-3-4, 5-6-7, 8-9) tek bir TCP segmentte gönderebiliyor.
1-Client
Hello
İstemci SSL
iletişimi kurma isteğini ClientHello mesajı göndererek belirtiyor. Bu mesajın
içine desteklediği SSL protokol versiyonu, şifreleme mekanizmaları (Cipher
Suites olarak gösterilen alan, key exchange + cipher + hash algoritmaları
bütünü ), destekleyebildiği sıkıştırma yöntemi ( SSL v3 ve TLS'de şuan için bir
sıkıştırma algoritması yok bu nedenle bu alan NULL ), SessionID ( yeni kurulan
bağlantılarda 0 değeri taşır ) ve RandomNumber denen ve 32 byte'lık bir değer (
bu değer sunucunun da göndereceği random number değeriyle birlikte şifreleme
anahtarı üretiminde kullanılır, ilk 4 byte'ı tarih ve saat bilgisini taşır )
yerleştirir.
2-Server
Hello
Server
Hello,Certificateve Server Hello Done mesajları paket dosyasında. Sunucu Client
Hello mesajını aldığında Server Hello mesajıyla yanıt verir. İstemcinin Client
Hello mesajından destekleyebildiği protokolleri,mekanizmaları öğrenen sunucu,
SSL iletişiminde kullanılacak şifreleme mekanizmasını, SSL versiyonu, SessionID
numarasını, sıkıştırma metodunu belirler ve yine şifreleme(Simetrik Şifreleme)
anahtarının oluşturulmasında kullanılmak üzere ürettiği RandomNumber değerini
de bu mesaj içine yerleştirir.
3-Certificate
Sunucu public
sertifikasını(Public Key) bu mesajla gönderir. Public sertifika CA
(Certificate Authority) private sertifikası tarafından imzalandığından ve CA
public sertifikasıyla bu imza doğrulanabildiğinden, sunucu sertifikasının
gerçekten güvenilir CA tarafından verilip verilmediği istemci tarafından
kolaylıkla kontrol edilir. Kontrol edilemezse sertifikanın güvenilir olmadığına
dair kullanıcı uyarılır.
4-Server
Hello Done
Bu mesaj
anlaşmanın ilk fazının bittiğini belirtir ve böylece istemci handshake'i
tamamlamak üzere ClientKeyExchange,ChangeCipherSpec ve Finished mesajlarını
gönderebilir.
5-ClientKeyExchange
Bu aşamada
istemci daha önce değiş tokuş edilen RandomNumber'lar ile birlikte kullanılarak
iletişimin daha doğrusu şifresi iletişimin bel kemiğini oluşturacak simetrik
key (anahtar) üretiminde kullanılacak 46 byte uzunluğunda "pre-master
secret" da denen gelişigüzel bir numara üretir ve bu numarayı, MAC
(Message Authentication Code) değeriyle birlikte sunucunun daha önce
"Certificate" mesajıyla kendisine gönderdiği public sertifikasını
kullanarak şifreler (Aşağıdaki resimde) . Bu mesajın yapısı ve içeriği, uzunluğu
da kullanılan key-exchange algoritmasına göre değişiyor. Aşağıdaki ekran
görüntüsü RSA algoritmasında kullanılan mesaj yapısını gösteriyor.
"Certificate"
mesajında gönderilen public sertifikayla şifrelenen bu değeri deşifre
edebilecek olan da sadece bu public sertifikanın private sertifikasına sahip
olan uçtur(Private Key). Yani bu iletişim kötü nihetli biri tarafından dinlense
bile, "ClientKeyExchange" mesajıyla şifrelenen değer sadece public
sertifikanın private eşleniğine sahip iletişim ucu tarafından deşifre
edilebileceğinden ele geçen bu bilgi bir işe yaramaz.
Genel kanının aksine şifreleme işleminde aslında anahtar bu sertifika değil; sertifika aslında şifreleme işleminde kullanılacak anahtarı üretmede kullanılan "ön anahtar" diyebileceğimiz sayıyı şifrelemek için kullanılıyor. Asıl anahtar asla istemci ve sunucu arasında karşılıklı ya da tek taraflı gönderilmiyor. Anahtarı, daha önce iletilen bilgiler (RandomNumber) ışığında istemci ve sunucu kendi kendilerine (pre-master secret ı da kullanarak) üretiyorlar ama ve istemci-sunucu tarafında sonuç olarak ayrı ayrı üretilen bu anahtar aslında aynı anahtar oluyor (simetrik anahtar).
Genel kanının aksine şifreleme işleminde aslında anahtar bu sertifika değil; sertifika aslında şifreleme işleminde kullanılacak anahtarı üretmede kullanılan "ön anahtar" diyebileceğimiz sayıyı şifrelemek için kullanılıyor. Asıl anahtar asla istemci ve sunucu arasında karşılıklı ya da tek taraflı gönderilmiyor. Anahtarı, daha önce iletilen bilgiler (RandomNumber) ışığında istemci ve sunucu kendi kendilerine (pre-master secret ı da kullanarak) üretiyorlar ama ve istemci-sunucu tarafında sonuç olarak ayrı ayrı üretilen bu anahtar aslında aynı anahtar oluyor (simetrik anahtar).
6,8-ChangeCipherSpec
İstemci bu mesajla sunucuya bundan sonraki iletişimde üzerinde mutabık olunan protokoller,algoritmalar, anahtarla SSL protokolünü kullanma isteğini bildirir.
İstemci bu mesajla sunucuya bundan sonraki iletişimde üzerinde mutabık olunan protokoller,algoritmalar, anahtarla SSL protokolünü kullanma isteğini bildirir.
7,9-Finished
ChangeCipherSpec mesajını gönderir göndermez taraflar bu mesajla, istemci ve sunucu kendilerinden gelecek mesajların Simetrik anahtarla şifreleneceği bilgisini içeren bir mesaj gönderir. Finished mesajı şifrelenen ilk mesajdır ve bundan sonraki iletişim de şifrelenir. Şifrelenen veri ise daha önceki SSL handshake mesajlarının hashi, ve gönderen tarafın istemci ya da sunucu olduğunu belirten bir başka değerdir.
Aşağıdaki
ekran görüntüsü Finished mesajındaki şifreli veriyi gösteriyor.
Şifreli Metin
TCP 3-way
handshake'le TCP bağlantı, SSL Handshake'le de güvenli iletişim kanalı kurulduktan
sonraki iletişim, gönderilen Request ve Response'lar aynıdır,hiç bir farkı
yoktur.
<<Önceki Bölüm
