TLS 1.3 kullanmak için yeni bir TLS sertifikası gerekir mi?

Hayır, TLS 1.3'e geçmek tek başına yeni bir sertifika alınmasını gerektirmez. Sertifikadaki açık anahtarın türü ve imza algoritması TLS 1.3'ün kimlik doğrulama kurallarıyla uyumlu olmalı ve sertifika zinciri geçerli olmalıdır.

TLS 1.3'te RSA sertifikası kullanılabilir mi?

Evet, uyumlu bir RSA anahtarı içeren sertifika TLS 1.3'te sunucu kimliğini doğrulamak için kullanılabilir. El sıkışma imzası için RSA-PSS yönteminin desteklenmesi gerekir. TLS 1.3'te kaldırılan unsur RSA sertifikaları değil, statik RSA anahtar değişimidir; sertifikaya atılan imza ile el sıkışma imzasının koşulları da aynı değildir.

TLS 1.2 kullanan bir site otomatik olarak güvensiz midir?

Hayır, TLS 1.2 desteği tek başına bağlantının güvensiz olduğunu göstermez. Bu sürümde seçilen anahtar değişimi, şifreleme paketi ve diğer güvenlik ayarları bağlantının güvenliğini önemli ölçüde etkiler. TLS 1.3 ise eski seçeneklerin çoğunu protokolden çıkarır.

TLS 1.2 ve TLS 1.3 aynı sunucuda birlikte açık olabilir mi?

Evet. Bir sunucu veya TLS bağlantısını sonlandıran ara bileşen her iki sürümü de destekleyebilir ve istemciyle ortak olan sürümü el sıkışma sırasında seçebilir. Böylece TLS 1.3 kullanabilen istemciler yeni sürümle, yalnız TLS 1.2 destekleyen uyumlu istemciler eski sürümle bağlanabilir.

TLS 1.3 destekleyen bir istemci neden bazen TLS 1.2 ile bağlanır?

TLS 1.3 karşı uçta desteklenmiyor veya bağlantı için etkin değilse ortak sürüm TLS 1.2 olabilir. İstemci isteklerini asıl sunucuya ileten ters proxy ya da trafiği sunuculara dağıtan yük dengeleyici TLS bağlantısını sonlandırıyorsa sürüm seçimi orada yapılır. Asıl sunucunun TLS 1.3 desteği, aracıyla kurulan bağlantının sürümünü tek başına belirlemez.

0-RTT her TLS 1.3 bağlantısında kullanılabilir mi?

Hayır, 0-RTT yalnız önceden paylaşılmış uygun bir PSK bulunduğunda, sunucu erken veriyi kabul ettiğinde ve uygulama buna izin verdiğinde kullanılabilir. TLS 1.3 desteğinin etkin olması, 0-RTT'nin otomatik olarak kullanılacağı veya kabul edileceği anlamına gelmez.

0-RTT neden tekrar oynatma riski taşır?

TLS katmanı, el sıkışma tamamlanmadan gönderilen 0-RTT verisinin yalnız bir kez işleneceğini her durumda garanti edemez. Sunucu ve uygulama tekrar oynatma saldırılarına karşı ek önlemler uygulamalıdır. Uygulama, yinelendiğinde yan etki doğurabilecek işlemleri erken veri olarak kabul etmemelidir.

TLS 1.3 her zaman TLS 1.2'den daha hızlı mıdır?

Her zaman değil. TLS 1.3, tam el sıkışmada gereken ağ gidiş-dönüşlerini azaltabilir; fakat bu tek başına her bağlantının veya web sayfasının daha hızlı olacağını garanti etmez. Ağ gecikmesi, oturum sürdürme yöntemi, taşıma katmanı, sunucu işlem süresi ve uygulamanın yaptığı istekler toplam süreyi ayrıca belirler.

TLS 1.3'te şifreleme paketi adları neden farklıdır?

TLS 1.3'te anahtar değişimi ile kimlik doğrulama, şifreleme paketinin kapsamından çıkarıldığı için adlandırma değişmiştir. Paket adı, şifreleme ve bütünlük denetimini birlikte yapan AEAD algoritmasını ve anahtar türetme ile el sıkışma özetinde kullanılan özet algoritmasını belirtir.

Bir bağlantının TLS 1.2 mi TLS 1.3 mü kullandığı nasıl anlaşılır?

El sıkışmada seçilen protokol sürümü, bağlantının TLS 1.2 mi TLS 1.3 mü kullandığını gösterir. Tarayıcının bağlantı güvenliği ayrıntıları, komut satırındaki bir TLS istemcisi veya sunucuya yönelik bir TLS testi bu bilgiyi gösterebilir. Sertifika tek başına kullanılan TLS sürümünü göstermez.

TLS 1.2 ve TLS 1.3 Arasındaki Farklar Nelerdir?

TLS 1.2 ve TLS 1.3'ün ortak amacı, istemci ile sunucu arasında kimliği doğrulanmış, gizliliği ve bütünlüğü korunan bir iletişim kanalı kurmaktır. Aralarındaki asıl fark, bu güvenli kanalı hangi mesajlarla kurdukları ve kriptografik seçenekleri nasıl düzenledikleridir.

TLS 1.3, TLS 1.2'nin el sıkışma yapısını sadeleştirir, eski şifreleme seçeneklerinin önemli bir bölümünü protokolden çıkarır ve şifreleme paketlerinin kapsamını değiştirir. Cipher suite (şifreleme paketi), bağlantıda kullanılacak kriptografik algoritmaların birlikte adlandırılmasıdır. İstemci ile sunucunun önceden paylaştığı uygun bir PSK (Pre-Shared Key) bulunduğunda, sunucunun yanıtını beklemeden uygulama verisi göndermeye yarayan 0-RTT erken veri seçeneği de kullanılabilir. Bu özellik tekrar oynatma, yani aynı isteğin yeniden gönderilip işlenmesi riskini taşıdığı için her uygulama verisine uygun değildir.

Bu değişiklikler yalnız güvenlik mimarisini değil, bağlantının kurulma süresini ve uyumluluk davranışını da etkiler. Bir sunucu iki sürümü birlikte destekleyebilir; hangi sürümün kullanılacağı istemci ve sunucunun ortak desteğine göre bağlantı sırasında belirlenir.

El Sıkışma Yapısı ve Bağlantı Gecikmesi

TLS el sıkışması, bağlantının başında tarafların sürümü ve kriptografik seçenekleri belirlemek, kimlik doğrulamak ve oturum anahtarlarını oluşturmak için yaptığı mesaj alışverişidir. Sunucu kimliği doğrulanır; istemci kimliğinin doğrulanması ise yapılandırmaya bağlıdır. TLS 1.2 ile TLS 1.3 arasındaki gecikme farkının temel nedeni, bu işlemlerin mesaj akışında farklı noktalara yerleştirilmesidir.

TLS 1.2'de Tam El Sıkışma

TLS 1.2'nin tam el sıkışmasında istemci, desteklediği seçenekleri ClientHello mesajıyla bildirir. Sunucu, seçtiği seçenekleri ServerHello ile yanıtlar; kullanılan yönteme göre sertifikasını, anahtar değişimi bilgilerini içeren ServerKeyExchange mesajını ve diğer gerekli mesajları gönderir. ServerHelloDone, sunucunun bu ilk mesaj grubunun bittiğini belirtir. İstemci, istenmişse sertifikasını, ardından ClientKeyExchange ile anahtar değişimi bilgisini ve gerekiyorsa özel anahtarını kullandığını kanıtlayan CertificateVerify imzasını gönderir. Sonra ChangeCipherSpec ile seçilen şifreleme ayarlarına geçer ve Finished ile el sıkışmanın bütünlüğünü doğrulayan bilgiyi gönderir. Sunucu da kendi ChangeCipherSpec ve Finished mesajlarıyla el sıkışmayı tamamlar. İlk bağlantıdaki sertifika ve anahtar değişimiyle ilgili birçok mesaj, şifreleme ayarları etkinleşmeden önce gönderilir.

Bu yapı tam bir bağlantıda birden fazla mesaj alışverişi gerektirir. İstemci ile sunucunun karşılıklı uygulama verisi göndermeye başlaması, TLS 1.2'nin tipik tam el sıkışmasında yaklaşık iki ağ gidiş-dönüşü gerektirir. TLS 1.2, önceki oturumun güvenlik parametrelerini yeniden kullanarak daha kısa bir el sıkışma da yapabilir; bu nedenle her TLS 1.2 bağlantısının gecikmesi aynı değildir.

TLS 1.3'te Daha Kısa Tam El Sıkışma

TLS 1.3'ün açık anahtarlı tam el sıkışmasında istemci, ClientHello içinde desteklediği sürümlerle birlikte anahtar değişiminde kullanacağı açık değerleri de gönderebilir. Sunucu uygun seçeneği seçip kendi açık değerini ServerHello ile döndürür. Taraflar bu bilgiler ve kendi geçici gizli değerleriyle ortak sırrı hesaplar, ardından el sıkışma anahtarlarını türetir. ServerHello'dan sonraki EncryptedExtensions, Certificate, CertificateVerify ve Finished gibi mesajlar şifreli olarak taşınır.

TLS 1.3'ün normal tam el sıkışmasında istemci, yaklaşık bir ağ gidiş-dönüşünün ardından uygulama verisi göndermeye başlayabilir. RTT (Round-Trip Time), bir iletinin karşı tarafa ulaşıp yanıtının geri dönmesi için geçen süredir. Buradaki bir ve iki RTT karşılaştırması TLS içindir; örneğin verinin sıralı ve güvenilir iletimini sağlayan TCP bağlantısının kurulma süresi bu sayılara dahil değildir. Sunucunun farklı bir anahtar grubu istemesi nedeniyle HelloRetryRequest göndermesi gibi durumlar ek gidiş-dönüş oluşturabilir. Dolayısıyla TLS 1.3'ün daha kısa el sıkışması gecikmeyi azaltabilir, ancak ağ mesafesi, TCP veya başka taşıma katmanı işlemleri ve uygulamanın kendi istekleri toplam sayfa yüklenme süresini ayrıca etkiler.

Gecikme kazancı özellikle istemci ile sunucu arasındaki ağ gidiş-dönüş süresi yüksek olduğunda daha görünür olabilir; çünkü TLS 1.3'ün daha az mesaj alışverişi gerektirmesi ağ üzerindeki beklemeyi azaltır. Buna karşılık aynı veri merkezindeki çok düşük gecikmeli bağlantıda veya uzun süre açık kalan bağlantılarda farkın toplam kullanıcı deneyimine etkisi daha sınırlı kalabilir. Bu nedenle el sıkışma süresi ile uygulamanın toplam yanıt süresi aynı şeyi ölçmez.

TLS 1.3'te Şifreleme Paketi Yapısındaki Değişiklikler

Şifreleme paketleri, TLS 1.2 ve TLS 1.3'te aynı kapsamı taşımaz. TLS, taşınacak veriyi kayıt adı verilen parçalara ayırır ve bu kayıtları şifreleyip bütünlüklerini korur. TLS 1.3, bu kayıt korumasını anahtar değişimi ve kimlik doğrulama seçeneğinden ayırır.

AEAD, şifreleme ile verinin değiştirilip değiştirilmediğinin doğrulanmasını birlikte sağlayan algoritma türüdür. HKDF, ortak gizli bilgiden farklı amaçlarla kullanılacak anahtarların türetilmesini sağlar. Bu işlemde kullanılan özet algoritması da şifreleme paketinde belirtilir.

Özellik	TLS 1.2	TLS 1.3
Şifreleme paketinin kapsamı	Anahtar değişimi, kimlik doğrulama, şifreleme, ileti bütünlüğü ve anahtar türetmeyle ilgili bileşenleri aynı paket adı altında tanımlar.	Şifreleme paketi esas olarak AEAD kayıt koruma algoritmasını ve HKDF ile kullanılan özet algoritmasını belirtir; anahtar değişimi ve imza seçimi ayrıdır.
Simetrik şifreleme yaklaşımı	AEAD yanında, veriyi bloklar halinde şifreleyen CBC modu ile ayrı bir MAC (Message Authentication Code) kullanan seçenekler de tanımlar.	Tanımlanan simetrik seçeneklerin tamamı AEAD, yani şifreleme ile bütünlük doğrulamasını birlikte sağlayan algoritmalardır.
Statik anahtar değişimi	TLS 1.2 şifreleme paketleri, uzun süreli anahtarlara dayanan statik RSA ve statik Diffie-Hellman anahtar değişimini içerebilir.	Statik RSA ve statik Diffie-Hellman şifreleme paketleri kaldırılmıştır.

Şifreleme paketi adları bu mimari farkı somutlaştırır. TLS 1.2'deki TLS_RSA_WITH_AES_128_CBC_SHA örneği statik RSA anahtar değişimini, AES algoritmasının 128 bit anahtarlı CBC kullanımını ve bütünlük denetimindeki HMAC-SHA1 kodunu birlikte belirtir. Bu eski paket yalnız adlandırmayı göstermek için verilmiştir; önerilen bir sunucu ayarı değildir. TLS 1.3'teki TLS_AES_128_GCM_SHA256 ise anahtar değişimi veya sertifika imza türünü adında taşımaz; kayıt koruması için AES'in 128 bit anahtarlı GCM kullanımını ve anahtar türetme ile el sıkışma özetinde SHA-256 seçimini belirtir.

Bir bağlantının TLS 1.2 kullanması, etkin güvenlik düzeyini tek başına açıklamaz. Seçilen anahtar değişimi ve şifreleme paketi de önemlidir. TLS 1.3, desteklenen kombinasyonları daraltarak eski yapıların yeni sürümde yanlışlıkla seçilmesini önler.

TLS Kayıtlarının Sıkıştırılması Neden Kaldırıldı?

TLS 1.2, iletilen kayıtların sıkıştırılmasına izin verir; TLS 1.3'te bu özellik kaldırılmıştır. Belirli koşullarda sıkıştırılmış verinin boyutundaki farklardan gizli bilgiler çıkarılabildiği için web bağlantılarında TLS 1.2 kayıt sıkıştırması kullanılmamalıdır.

Sertifika sıkıştırması farklı bir işlemdir. TLS 1.3, ayrı bir uzantıyla sertifika mesajının boyutunu küçültebilir. Kayıt sıkıştırmasının kaldırılması, sertifikaların veya HTTP yanıtlarının hiç sıkıştırılamayacağı anlamına gelmez.

TLS 1.2 ve TLS 1.3'te İleri Gizlilik

İleri gizlilik, uzun süreli bir özel anahtar daha sonra ele geçirilse bile geçmiş bağlantıların oturum anahtarlarının hesaplanamamasını hedefler. TLS 1.2'de bu özellik kullanılan anahtar değişimine bağlıdır. Geçici Diffie-Hellman yöntemleri her bağlantı için geçici anahtarlar kullanır ve tarafların ortak sırrı ağ üzerinden göndermeden hesaplamasını sağlar. Bu geçici sırlar daha sonra silindiğinde geçmiş trafiğin gizliliği, uzun süreli sertifika anahtarının sonradan ele geçirilmesine karşı korunur; statik anahtar değişimi aynı özelliği vermez.

TLS 1.3 statik RSA ve statik Diffie-Hellman yöntemlerini kaldırdığı için açık anahtar temelli anahtar değişimlerinde ileri gizliliği temel tasarıma taşır. Bununla birlikte “TLS 1.3 her koşulda ileri gizlilik sağlar” demek fazla geneldir. Geçici Diffie-Hellman anahtar değişimi kullanılmadan yalnız PSK ile kurulan bağlantılarda ileri gizlilik garanti edilmez; 0-RTT erken verisi de tam ileri gizlilik sağlamaz.

0-RTT Bağlantı Kurulumunu Nasıl Etkiler?

0-RTT, TLS 1.3'ün her yeni bağlantıda otomatik olarak kullandığı bir hızlandırma değildir. İstemci uygun bir PSK'ya ve erken veri için gerekli bağlantı ayarlarına sahipse bazı uygulama verilerini ClientHello ile birlikte göndermeyi deneyebilir. Böylece uygulama verisinin ilk bölümünü göndermek için normal el sıkışmanın tamamlanmasını beklemek gerekmez.

Bu kazancın karşılığında önemli bir güvenlik sınırı vardır: TLS katmanı 0-RTT verisi için kendiliğinden tam tekrar oynatma koruması sağlayamaz. Erken veri şifrelidir, fakat saldırgan kaydettiği şifreli veriyi çözmeden yeniden iletmeye çalışabilir. Sunucu tarafında tekrar önleme mekanizmaları uygulanabilse de uygulama, 0-RTT ile hangi işlemlerin gönderilmesinin güvenli olduğunu ayrıca tanımlamalıdır.

Örneğin ödeme yapma veya sipariş oluşturma isteği, tekrar gönderildiğinde ikinci bir işlem doğurabilir; uygulama bu tür istekleri özel koruma olmadan 0-RTT ile kabul etmemelidir. Sunucu 0-RTT'yi reddedebilir ve bağlantı normal 1-RTT el sıkışmayla devam edebilir. Önceki bir oturumdan alınmış veya harici olarak tanımlanmış uygun bir PSK bulunmayan TLS 1.3 bağlantısında 0-RTT kullanılamaz.

Uyumluluk ve Sürüm Pazarlığı

TLS 1.3, TLS 1.2 el sıkışmasının yalnız küçük bir uzantısı değildir; el sıkışma mesajlarının içeriği ve sırası değişmiştir. Buna rağmen sürüm pazarlığı, istemci ve sunucunun ortak desteklediği TLS sürümünü seçmesine olanak tanır. Bir sunucu uygulaması her iki sürümü de destekliyorsa, tarafların güvenlik ayarları uyuştuğunda TLS 1.3 destekleyen istemciyle yeni sürüm; yalnız TLS 1.2 destekleyen uyumlu istemciyle eski sürüm seçilebilir.

Uyumluluk yalnız uçtaki web sunucusuna bağlı olmayabilir. İstemci isteklerini asıl sunucuya ileten ters proxy, trafiği sunuculara dağıtan yük dengeleyici veya güvenlik ağ geçidi TLS bağlantısını sonlandırıyorsa sürüm seçimi o bileşende yapılır. TLS 1.3, eski ara cihazlarla yaşanan uyumluluk sorunlarını azaltmak için bazı eski biçim alanlarını ve gerektiğinde uyumluluk amaçlı ChangeCipherSpec davranışını korur; TLS 1.3'ü doğru işlemeyen ara sistemler yine de bağlantıyı etkileyebilir.

TLS 1.3 ayrıca sürüm düşürme girişimlerini saptamaya yardımcı olan koruma mekanizmaları tanımlar. Bunun amacı, iki taraf da daha yeni sürümü desteklediği halde ağ üzerindeki bir müdahalenin bağlantıyı sessizce daha eski sürüme zorlamasını engellemektir. Normal uyumluluk pazarlığı ile saldırgan tarafından zorlanan sürüm düşürme aynı durum değildir.

Ortak bir sürüm bulunamazsa el sıkışma tamamlanmaz. Bu yüzden sunucuda TLS 1.3 desteğinin etkin olması, tüm istemci ve ara katmanların aynı sürümü kullanacağını tek başına göstermez; gerçek bağlantıda seçilen sürümü ayrıca kontrol etmek gerekir.