TLS 1.3: 0-RTT, Erken Veri ve Oturum Sürdürme

TLS 1.3 (RFC 8446, 2018), gecikmeyi azaltmak ve eski gereksiz yükleri kaldırmak için TLS el sıkışmasını yeniden tasarlamıştır. Tam bir TLS 1.3 el sıkışması 1-RTT'de tamamlanır: istemci, ilk iletimde desteklenen key_shares'ları (geçici ECDH açık anahtarları) içeren ClientHello'yu gönderir; sunucu ise ServerHello, kendi key_share değerini, şifrelenmiş uzantıları, sertifikayı ve tamamlama iletisini tek bir yanıtta gönderir. İstemci, kendi tamamlama iletisini gönderir ve hemen uygulama verileri göndermeye başlayabilir. TLS 1.2'nin 2-RTT süren el sıkışmasıyla karşılaştırıldığında bu, yeni oturumlarda bağlantı kurulumu süresini yarıya indirir.

TLS 1.3, yapılandırılmış bir anahtar çizelgesiyle HKDF'yi (HMAC tabanlı Anahtar Türetme İşlevi) kullanır. ECDHE anahtar değişiminden sonra paylaşılan sır, bir hiyerarşiye aktarılır: Extract(early_secret, DHE) -> handshake_secret; ardından Extract(handshake_secret, 0) -> master_secret. HKDF-Expand-Label, bunlardan istemci ve sunucu el sıkışma trafiği, uygulama trafiği ve oturumun yeniden sürdürülmesi için ayrı anahtarlar türetir. Bu temiz ayrım, bir anahtar katmanının ele geçirilmesinin diğerlerini etkilememesini sağlar; bu da TLS 1.2'nin daha gelişigüzel PRF tabanlı anahtar türetme yöntemine kıyasla önemli bir iyileştirmedir.

TLS 1.3'te oturumun sürdürülmesi, önceki oturumlardan türetilen Önceden Paylaşılan Anahtarları (PSK'ler) kullanır. El sıkışması tamamlandıktan sonra sunucu, bir PSK kimliği ve bilet değeri (oturumun sürdürülmesi sırrını içeren şifrelenmiş bir veri bloğu) barındıran bir NewSessionTicket iletisi gönderir. Yeniden bağlanırken istemci, PSK kimliğini ClientHello içine ekler. Sunucu bunu tanırsa her iki taraf da PSK ile yeni bir ECDHE çıktısını birleştirerek yeni bir oturum anahtarı türetir ve ileriye dönük gizlilik sağlayan 1-RTT'lik oturum sürdürme elde edilir. Biletin yapılandırılabilir bir ömrü vardır (genellikle 24 saat) ve sunucu tarafında döndürülen bir anahtarla şifrelenmelidir.

TLS 1.3, sürdürülen oturumlar için 0-RTT erken verisine izin verir. İstemci, önceki bir oturumdaki PSK'yi kullanarak, herhangi bir sunucu onayından önce ilk iletimde gönderilen uygulama verilerini şifreler. Bu, daha önce ziyaret edilmiş sunuculara yapılan bağlantılarda bir gidiş-gelişi ortadan kaldırır ve tekrarlanan bağlantılar için sıfıra yakın gecikme sağlar. Sunucu, NewSessionTicket içinde max_early_data_size değerine sahip early_data uzantısı aracılığıyla 0-RTT desteğini bildirir. Sunucunun 0-RTT verisini kabul edecek veya reddedecek bir mekanizması bulunmalı ve kabulü EncryptedExtensions içinde bildirmelidir.

0-RTT verilerinin temel bir güvenlik sınırlaması vardır: tekrar oynatma saldırılarına karşı savunmasızdır. İlk iletimi ele geçiren iletişim yolundaki bir saldırgan, bunu sunucuya yeniden göndererek sunucunun erken veriyi tekrar işlemesine neden olabilir. Bu durum kaçınılmazdır; çünkü sunucu henüz hiçbir ileti göndermemiştir ve bu nedenle sunucunun sağladığı bir tazelik bulunmaz. Önlemler: (1) Tek kullanımlık biletler (sunucu, memcached/Redis gibi dağıtık bir önbellek kullanarak ilk kullanımdan sonra bileti geçersiz kılar). (2) Süreyle sınırlı biletler (örneğin 5 saniyelik kısa bir aralıktan sonra 0-RTT'yi reddetmek). (3) Uygulama düzeyinde aynı sonucu veren işlemler (0-RTT'ye yalnızca güvenli GET eşdeğeri işlemler için izin vermek).

En sağlam 0-RTT tekrar oynatma önleme mekanizması, tek kullanımlık oturum biletleridir. Sunucu, "kullanılmış bilet" deposunu tutar (çok sunuculu dağıtımlarda bu, dağıtık bir önbellektir). 0-RTT verisi geldiğinde sunucu, biletin daha önce görülüp görülmediğini denetler; daha önce görülmüşse erken veriyi reddeder ve 1-RTT'ye geri döner. Daha önce görülmemişse bileti kullanılmış olarak işaretler ve erken veriyi işler. Doğru çalışması için bir kümedeki tüm sunucuların kullanılmış bilet önbelleğini paylaşması gerekir. Bilet ömrüyle eşleşen kısa TTL değerlerine sahip Redis, yaygın bir uygulamadır. Bu mekanizma olmadan 0-RTT, ödemeler gibi aynı istek tekrarlandığında sonucu değişebilen işlemler için güvenli değildir.

DHE içermeyen TLS 1.3 PSK ile oturum sürdürme, sürdürülen oturum için ileriye dönük gizlilik sağlamaz; PSK daha sonra ele geçirilirse sürdürülen oturum trafiğinin tamamı çözülebilir. İleriye dönük gizliliği korumak için TLS 1.3, PSK-with-DHE'yi destekler: ClientHello hem bir PSK kimliği hem de yeni bir key_share içerir. Sunucu, PSK ile ECDHE çıktısını birleştirerek oturum anahtarlarını türetir. PSK ele geçirilse bile ECDHE katkısı, geçmiş trafiğin korunmasını sağlar. RFC 8446, ileriye dönük gizliliğin gerekli olduğu tüm oturum sürdürme durumlarında PSK-with-DHE kullanılmasını önerir.

TLS 1.2'de 300'den fazla şifre paketi bileşimi vardı ve bunların çoğu güvenli değildi. TLS 1.3 bunu, tümü AEAD kullanan 5 şifre paketine indirir: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 ve TLS_AES_128_CCM_8_SHA256. Anahtar değişimi ve kimlik doğrulama, supported_groups ve signature_algorithms uzantıları aracılığıyla ayrı ayrı görüşülür. Bu ayrım, TLS 1.2'nin birleşimsel karmaşıklığını ortadan kaldırır ve her TLS 1.3 bağlantısında kimlik doğrulamalı şifreleme kullanılmasını sağlar.

Uygulamada 0-RTT, daha önce ziyaret edilmiş bir sunucuya güvenli ve aynı sonucu veren bir GET isteğini yineleyen HTTP/2 bağlantıları için en kullanışlıdır. Tarayıcılar 0-RTT'yi dikkatli bir şekilde uygular: Chrome bunu güvenli HTTP yöntemleri için etkinleştirir; POST istekleri hiçbir zaman 0-RTT verisi olarak gönderilmez. QUIC üzerinden HTTP/3, TLS 1.3'ü yerel olarak bütünleştirir; QUIC'in 0-RTT'si TLS 1.3'ün mekanizmasını yeniden kullanır. QUIC'te 0-RTT ayrıca önceki oturumdaki taşıma parametrelerini (akış denetimi, akış sınırları) geri yükleyerek yalnızca TLS katmanının ötesinde kurulum ek yükünü de azaltır.

TLS 1.3, sürüm düşürme saldırılarını önleyen mekanizmalar içerir. TLS 1.3 görüşüldüğünde ServerHello'nun rastgele alanı bir işaretçi değer içerir: son 8 bayt, TLS 1.2'ye geri dönüş için sabit bir değere (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01) ayarlanır. TLS 1.3 destekli istemciler, sunucu TLS 1.2'yi görüştüğünde bu işaretçiyi denetleyerek etkin sürüm düşürme girişimlerini algılar. Ayrıca tamamlama ileti dökümü karması, sürüm görüşmesi de dahil olmak üzere tüm el sıkışmasını kapsar; bu nedenle herhangi bir kurcalama algılanabilir. SCSV (Şifre Paketi Değerlerini Bildirme) gibi değerler, örneğin TLS_FALLBACK_SCSV, eski TLS sürümleri için ayrı bir sürüm düşürme sinyali sağlar.

TLS 1.3'ü dağıtmak, çeşitli işletimsel ayrıntılara dikkat edilmesini gerektirir. Oturum bileti şifreleme anahtarları düzenli olarak döndürülmeli (genellikle 24 saatte bir) ve oturumun herhangi bir sunucuda sürdürülebilmesi için sunucu kümeleri arasında eşitlenmelidir. Gereksiz el sıkışması hatalarını önlemek için eski bilet şifre çözme anahtarları, biletin ömrü boyunca tutulmalıdır. OCSP zımbalama, TLS 1.3'te daha önemlidir; çünkü sertifika durumunu denetlemek için bir gidiş-gelişi ortadan kaldırır. Yük dengeleyiciler, TLS 1.3 ClientHello iletisini değiştirmeden geçirmelidir; bazı eski ara ağ cihazları bilinmeyen uzantıları bozduğundan uyumluluk kipleri gerekebilir.

TLS 1.3'te 0-RTT erken verileri neden tekrar oynatma saldırılarına karşı savunmasızdır?

TLS 1.3, PSK oturum biletleri aracılığıyla 1-RTT'lik tam el sıkışmaları ve 0-RTT'lik oturum sürdürmeyi mümkün kılar. Anahtar türetme, yapılandırılmış bir çizelgeyle her trafik katmanı için ayrı anahtarlar üreten HKDF'yi kullanır. 0-RTT erken verisi bir gidiş-gelişi ortadan kaldırır; ancak tekrar oynatmaya karşı savunmasızdır. Bu risk, tek kullanımlık biletlerle ve 0-RTT'yi aynı sonucu veren işlemlerle sınırlayarak azaltılır. PSK-with-DHE, oturum sürdürme sırasında ileriye dönük gizliliği korur. TLS 1.3, şifre paketlerini 5 AEAD seçeneğiyle sınırlandırarak eski ve güvenli olmayan bileşimleri ortadan kaldırır. Sürüm düşürmeyi önleme, sunucunun rastgele alanındaki işaretçi değerleri kullanır.