SSL/TLS — nedir, protokoller ve şifrelemenin çalışma prensibi

SSL/TLS Nedir?

SSL (Secure Sockets Layer), 1995 yılında Netscape tarafından web trafiğini korumak için geliştirilmiş bir protokoldür. İlk sürüm SSL 1.0 hiçbir zaman yayınlanmadı; SSL 2.0 (1995) ve SSL 3.0 (1996) 2000'lerin başına kadar kullanıldı ancak kritik güvenlik açıkları içeriyordu. SSL'nin yerini TLS (Transport Layer Security) aldı — IETF tarafından standartlaştırılmış geliştirilmiş bir sürüm. TLS 1.0 (1999), SSL 3.0'a dayanıyordu; sonraki sürümler TLS 1.1 (2006), TLS 1.2 (2008) ve TLS 1.3 (2018) ise kademeli olarak orijinal mimariden uzaklaştı, yeni şifreleme algoritmaları ekledi ve güvenlik açıklarını düzeltti. Bugün SSL eskimiş kabul edilir ve tüm modern sistemler TLS kullanır, ancak her iki protokol de alışkanlıkla genellikle SSL/TLS olarak birlikte anılır.

Protokolün Tarihçesi

SSL/TLS'nin tarihi, erken web'de güvenli veri iletimi ihtiyacıyla başladı. 1994 yılında Netscape, Navigator tarayıcısı için SSL 1.0'ı geliştirdi, ancak ciddi güvenlik sorunları nedeniyle protokol hiçbir zaman yayınlanmadı. SSL 2.0 1995'te piyasaya sürüldü ve pratikte kullanıldı, ancak çok sayıda güvenlik açığı içeriyordu: Ortadaki Adam saldırılarına karşı koruma eksikliği, zayıf şifreleme algoritmaları ve kesme saldırılarına karşı hassasiyet. SSL 3.0 (1996) çoğu sorunu düzeltti, ancak 2014 yılına kadar POODLE güvenlik açığı keşfedildi ve bunun üzerine IETF tüm SSL sürümlerini resmen geçersiz ilan etti. TLS 1.0–1.3, kriptografik gücü, performansı ve gizliliği aşamalı olarak iyileştirdi; TLS 1.3, el sıkışmayı iki gidiş-dönüşten bire indirdi — bu, istikrarsız bağlantılı mobil uygulamalar için kritik öneme sahiptir.

SSL/TLS El Sıkışması Nasıl Çalışır

El Sıkışma (Handshake), bir istemci ile sunucu arasında güvenli bağlantı kurma sürecidir. Tarafların protokol sürümü üzerinde anlaştığı, şifreleme algoritmalarını seçtiği, anahtarları değiştirdiği ve birbirlerini doğruladığı birkaç ardışık adımdan oluşur. TLS 1.3'te el sıkışma yalnızca bir ağ gidiş-dönüşü (1-RTT) alırken, TLS 1.2'de iki (2-RTT) gerekiyordu.

İlk adım, istemcinin bir ClientHello göndermesidir — desteklenen TLS sürümlerinin, şifre takımlarının ve rastgele bir sayının listesini içeren bir mesaj. Sunucu, seçilen sürüm ve şifre, X.509 sertifikası ve dijital imza ile bir ServerHello ile yanıt verir. İstemci, sertifikayı sertifika otoritesi (CA) zinciri aracılığıyla doğrular, bir oturum anahtarı oluşturur ve bunu sertifikadaki sunucunun genel anahtarıyla şifreleyerek gönderir. Sunucunun onayından sonra güvenli veri iletimi başlar. Tüm el sıkışma modern cihazlarda 1–3 milisaniye sürer ve kullanıcı tarafından fark edilmez.

X.509 Sertifikaları ve Güven Zinciri

TLS kimlik doğrulamasının temeli, X.509 formatındaki sertifikalar üzerine inşa edilmiş Açık Anahtar Altyapısıdır (PKI). Her sertifika şunları içerir: bir alan adı (Common Name veya Subject Alternative Name), sunucunun genel anahtarı, verenin adı (Sertifika Otoritesi), bir son kullanma tarihi ve CA'nın dijital imzası. İstemci, sunucu sertifikasını güven zinciri boyunca doğrular: sunucu sertifikasından, sertifikası işletim sistemine gömülü olan kök CA'ya kadar. Android cihazlarda, kök sertifikalar sistem anahtar deposunda saklanır ve Google Play Services aracılığıyla güncellenir; iOS'ta — iOS güncellemeleri aracılığıyla. Zincirdeki herhangi bir halka kırılırsa (süresi dolmuş sertifika, alan adı uyuşmazlığı, bilinmeyen CA), istemci bağlantıyı sonlandırır. Kendinden imzalı sertifikalar (geliştirmede kullanılan) için açık güven gereklidir — Android'de Network Security Config aracılığıyla, iOS'ta Info.plist'te NSExceptionDomains aracılığıyla. Sertifika zinciri doğrulama süreci, CRL (Sertifika İptal Listesi) veya OCSP (Çevrimiçi Sertifika Durum Protokolü) aracılığıyla iptal durumu kontrolünü de içerir, ancak mobil cihazlarda OCSP istekleri bağlantıyı hızlandırmak için genellikle atlanır — bu, mimarların dikkate alması gereken güvenlik ve performans arasında bir ödünleşimdir.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()