HTTPS nasıl çalışır?

Bu flood’da HTTP’nin güvenli hali olan HTTPS protokolünün nasıl çalıştığını anlatacağım.

HTTPS, HTTP’nin iletim (Transport) katmanının güvenli hale getirilerek gizliliğin (Confidentiality) sağlanması ve önceki flood’da anlatılan dijital sertifikalarla istemcinin sunucunun kimliğini doğrulaması (Authenticity) ile çalışır.

Gizlilik, iletim katmanı (TCP) şifrelenerek sağlandığı için protokol seviyesinde (GET, PUT, POST, vb) HTTP ve HTTPS arasında herhangi bir farklılık yoktur. İstemci, sunucu ile HTTP bağlantısını kurmadan önce ve TCP bağlantısını kurduktan sonra SSL/TLS Handshake adlı akışı başlatır. Bu akışta istemci ve sunucu iletim katmanının şifrelenmesi için gerekli olan kripto parametrelerini konuşur. Mekanizmanın nasıl çalıştığına flood'un sonlarına doğru detaylı olarak değineceğiz.

SSL/TLS Handshake mekanizması protokol bağımsız çalıştığı için HTTP dışında TCP üzerinde çalışan herhangi bir protokolde (Kazım adındaki kendi özel protokolünüz de olabilir) iletim katmanında gizlilik sağlamak için de kullanılabilir. Uygulama (örneğin HTTP veya Kazım) katmanında hazırlanan veri TCP katmanına iletilirken SSL/TLS katmanında şifrelenir ve karşı tarafa gönderilir. Karşı tarafın TCP katmanından uygulama katmanına iletilirken verinin şifresi yine SSL/TLS katmanında çözülür, böylece uygulamanın şifreleme mantığından haberdar olması gerekmez. Aşağıdaki şekilde bu mekanizma görselleştirilmeye çalışılmıştır.

Şimdi SSL/TLS Handshake'e detaylı bir şekilde bakabiliriz. HTTPS'te TCP üzerinden iletilen veri simetrik anahtar şifreleme (Symmetric Key Encryption) ile şifrelenir çünkü simetrik şifreleme asimetrik şifrelemeye göre daha hızlı çalışır. Önceki flood'da bahsi geçtiği gibi simetrik şifrelemede ortak anahtarın dağıtımı ile ilgili problem vardır. Yine önceki flood'da yazıldığı gibi asimetrik şifreleme ile anahtar dağıtım problemi çözülebilir.

HTTPS’in ilk dönemlerine simetrik ve asimetrik şifreleme birlikte kullanılmıştır. Asimetrik şifreleme ile, simetrik şifrelemede kullanılacak olan ortak anahtar belirlenmiş, konuşmanın devamı belirlenen bu simetrik şifreleme ile yapılmıştır. İstemci SSL/TLS Handshake sırasında, sunucu sertifikasından aldığı Public Key ile konuşmanın devamında kullanılacak simetrik şifrelemenin ortak anahtarını asimetrik olarak şifreleyip sunucuya gönderir. Sunucu asimetrik olarak şifrelenmiş bu veriyi kendi Private Key'i ile çözerek simetrik şifrelemede kullanılacak anahtarı elde eder. SSL/TLS Handshake bittikten sonra istemci ve sunucu değişimi yapılan simetrik anahtar ile gizli konuşmayı sürdürürler.

Yukarıda anlatılan mekanizmadan geçmiş zamanla bahsedilmesinin sebebi bu yöntemin güvenli olmamasıdır. Bahsi geçen sunucu ile yapılan bütün şifreli trafik bir yere kaydedilir ve sunucunun Private Key'i uzun zaman sonra olsa bile ele geçirilirse kaydedilen konuşmalarda kullanılan simetrik anahtarlar açığa çıkan Private Key ile çözülebilir ve bütün trafik deşifre edilebilir. Burada meraklı okuyucu Snowden ve Forward Secrecy kelimeleri ile araştırma yapabilir.

Geçmişte yapılan konuşmaların deşifre edilememesi için istemci ve sunucunun her session için ayrı bir simetrik anahtar üretmesi gerekliliği açıktır. Burada imdada Diffie-Hellman Key Exchange yetişmektedir. Diffie-Hellman, detayına burada girmeyeceğimiz matematiksel yöntemlerle istemci ve sunucunun güvensiz ağ (internet) üzerinde simetrik anahtar şifreleme için ortak bir anahtar belirlemesine olanak tanır. Yine meraklı okuyucu bu akıl dolu mekanizmayı araştırabilir.

Diffie-Hellman iki partinin ortak bir anahtar belirleyerek iletim katmanını şifreleyip güvenli konuşmasını, Confidentiality, sağlar fakat güvenli olarak şeytanla konuşmadığınızı garanti etmez, yani Authenticity sağlamaz :-)

Diffie-Hellman akışı sırasında araya giren bir kişi istemciye sunucu rolünde, sunucuya da istemci rolünde görünerek her ikisi ile de Diffie-Hellman akışı yürüterek bütün konuşmayı dinleyebilecek simetrik anahtarlara sahip olabilir.

Tam bu noktada devreye önceki flood’da kısaca bahsettiğimiz Public/Private Key'ler ile oluşturulan PKI altyapısı ve dijital sertifikalar girer. Şeytan yerine, gerçekten konuşmak istediğimiz sunucu ile konuşup konuşmadığımızı anlamak için tarayıcımız SSL/TLS Handshake sırasında sunucudan SSL sertifikasını ister. Sunucunun sertifikasının kendisinin de önceden güvendiği üçüncü parti bir kurum tarafından imzalanıp imzalanmadığını kontrol eder. Eğer SSL sertifika üçüncü parti yerine onun vekili tarafından imzalanmışsa bu kez vekilin sertifikasının güvenli kurum tarafından imzalanıp imzalanmadığına bakar. Tarayıcı, sertifika zincirindeki bütün sertifikaları en yukarıda güvendiği bir sertifika buluncaya kadar doğrulamaya devam eder. Bu işleme Certificate Chain Validation adı verilir. Bu mekanizmayı PKI (Public Key Infrastructure)'ı inceleyeceğimiz flood'da detaylı olarak ele alacağız.

Aşağıdaki Garanti Bankası sertifikası öncelikle Symantec Class 3 EV SSL CA tarafından, o da VeriSign Class 3 CA tarafından imzalanmıştır. VeriSign sertifikası tarayıcıda önceden yüklü olduğu için Garanti sertifikasına güvenilmiştir.

Özetle SSL/TLS Handshake iletilen verilerin şifrelenebilmesi için simetrik anahtarı üretmek yani gizliliği sağlamak ve iletişim kurulan sunucunun gerçek kimliğini doğrulamakla yükümlüdür ve bunları anlatılan yöntemlerle yapmaktadır.