Trafiğin detaylarına girmeden önce basit ve bu yazıda örnek alınacak trafiğin wireshark'la yakalanmış ekran görüntüsünü de ekliyorum. Yukardaki mekanizmayı anlamada yardımcı olacak.
Benim önerim yazıyı okurken biryandan da wireshark'la yazının sonuna eklediğim pcap (Packet Capture) dosyasını açmanız ve paketleri incelemeniz olacak.
Dedik ya SSL kendi altında güvenilir bir protokole ihtiyaç duyar, bu da meşhur TCP protokolü. Dolayısıyla SSL iletişiminden bahsedebilmek için öncelikle TCP 3-way handshake ile TCP bağlantının kurulması lazım. Paket dosyasındaki ilk 3 paket 3-way handshake mekanizmasına ait. TCP bağlantı kurulduktan sonraki aşama SSL Handshake. Bunu da en basit haliyle aşağıdaki resmi kullanarak tarif edeceğim.
SSL self-delimiting bir protokol olması nedeniyle birden fazla mesajı (2-3-4, 5-6-7, 8-9) tek bir TCP segmentte gönderebiliyor. Örneğimizde
192.168.227.133 XP Pro istemci
192.168.227.128 Windows 2008 Server
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,Certificate ve Server Hello Done mesajları paket dosyasının 6 numaralı paketinde.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 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ı 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
"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. 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.
Evet, 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). Bu bölümde siz de film kopmuş, gözünüzün önünde anahtarlar uçuyor olabilir, biraz ara verin kafanızı toplayın tekrar tekrar okuyun.
6-ChangeCipherSpec
İstemci bu mesajla sunucuya bundan sonraki iletişimde üzerinde mutabık olunan protokoller,algoritmalar, anahtarla SSL protokolünü kullanma isteğini bildirir.
7-Finished
ChangeCipherSpec mesajını gönderir göndermez taraflar bu mesajla, iletişim kanalının kurulduğunu ve düzgün çalıştığını doğrularlar. 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
Aşağıdaki ekran görüntüsü de aynı mesajın şifresiz hali
Şifresiz
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.
Şifreli HTTP Get Request
Şifresiz HTTP Get Request
Kitabına ya da standardına uygun bir SSL Handshake mekanizmasını inceledik,Wireshark kullanarak HTTPS trafiğin deşifre edilmesi ( Sunucu Private Sertifikanın edinilebildiği varsayılarak ) de bir başka yazı konusu olsun.Yazıda kullanılan paket dosyasını ve paket dosyasını deşifre etmede kullanılabilecek sunucu sertifikasını da ekliyorum. Sertifika parolası "badpass".
İlgili Yazılarım
HTTP - Nass oluyor da oluyor? 3-way-handshake
HTTP - Nass oluyor da oluyor? HTTP Headerlar ve HTTP Mesaj Yapısı
HTTP - Nass oluyor da oluyor? HTTP Basic Authentication
HTTP - Nass oluyor da oluyor? HTTP Windows Authentication
HTTP - Nass oluyor da oluyor? HTTP Digest Authentication
Hiç yorum yok:
Yorum Gönder