TLS 1.3 geçişi ve şifre seçimi

TLS 1.3 ile ne değişti

TLS 1.3 (RFC 8446, 2018), 1.2 sürümünün küçük bir revizyonu değildir. Yıllar boyunca güvenlik açığı üreten özellikleri tümüyle kaldırmıştır: ileri gizlilik sağlamayan RSA anahtar değişimi, statik Diffie-Hellman, CBC modundaki şifreler, RC4, sıkıştırma ve yeniden anlaşma. Her TLS 1.3 bağlantısı geçici anahtar değişimi kullanır, yani her oturum için yeni ve yalnızca o oturuma ait bir anahtar üretilir. Bunun pratik sonucu şudur: çalınan bir sunucu anahtarı, daha önce kaydedilmiş trafiğin şifresini çözmeye yetmez.

El sıkışma da belirgin biçimde hızlanmıştır. Yeni bir bağlantıda uygulama verisi akmaya başlamadan önce, TLS 1.2'deki iki gidiş-dönüş yerine tek bir gidiş-dönüş yeterlidir ve el sıkışmanın çok daha büyük bir bölümü, sunucu sertifikası da dahil olmak üzere şifrelenir. İsteğe bağlı 0-RTT modu, daha önce bağlanmış istemcilerin veriyi hemen ilk mesajda göndermesine izin verir; bunun bedeli, o erken verinin bir saldırgan tarafından tekrar oynatılabilmesidir.

Hangi protokol sürümlerine izin vermeli

RFC 8996, TLS 1.0 ile 1.1'i 2021'de resmen kullanımdan kaldırdı; büyük tarayıcılar ise desteği zaten bir süre önce kesmişti. Bu iki sürümü açık tutmak yalnızca çok eski birkaç istemciye yarar sağlar, buna karşılık herkesi sürüm düşürmeye dayalı zayıflıklara açık bırakır ve uyumluluk taramalarında başarısız olmanıza yol açar. Herkese açık web siteleri için pratik taban çizgisi bu yüzden TLS 1.2 ve TLS 1.3'tür.

Yalnızca TLS 1.3 kullanan bir yapılandırma, yani Mozilla'nın modern profili, istemcilerini sizin kontrol ettiğiniz API'ler ve iç servisler için makul bir seçimdir. Herkese açık siteler ise eski işletim sistemleri, gömülü cihazlar ve bazı kurumsal vekil sunucular nedeniyle genellikle TLS 1.2'yi de açık tutmayı sürdürür. Aradaki fark güvenlikten çok erişilebilirlikle ilgilidir: doğru paketlerle sınırlandırılmış bir TLS 1.2 bugün hâlâ güvenlidir. Bir bağlantının hangi sürümde anlaştığını görmek için TLS Kontrolü aracını kullanabilirsiniz.

Şifre paketlerini seçmek

TLS 1.3

TLS 1.3 küçük bir paket kümesi tanımlar ve yaygın olarak açık olanların hepsi güçlüdür. Sunucuların çoğu makul varsayılanlarla geldiği için burada genellikle yapılandırılacak bir şey yoktur. Paket yalnızca AEAD şifresini ve özet algoritmasını belirler; anahtar değişimi ile imza algoritmaları bundan bağımsız olarak ayrıca müzakere edilir.

TLS 1.2

Yapılandırmanın gerçekten önem taşıdığı yer TLS 1.2'dir. Yalnızca ileri gizlilik sağlayan ECDHE anahtar değişimini ve AEAD şifrelerini kullanan paketlere izin verin, geri kalan her şeyi kapatın. RFC 9325 (BCP 195) IETF'in bu konudaki güncel önerilerini toplar ve bakımı sürdürülen profillerin kullandığı listelerle örtüşür.

Tarayıcı bulgularının anlamı

TLS tarayıcıları bulguları eski saldırıların adlarıyla raporlar; bu da hangisinin gerçekten önemli olduğunu anlamayı ve önceliklendirmeyi zorlaştırır. İyi haber şu ki bu bulguların çoğu, TLS 1.0 ile 1.1 kapatılıp TLS 1.2 yalnızca AEAD şifreli ECDHE paketleriyle sınırlandığında hep birlikte ortadan kalkar. Aşağıdaki tablo, sık karşılaşılan bulguları onları ortadan kaldıran yapılandırma değişikliğiyle eşleştirir.

Eksik bir HSTS başlığı gibi HTTP başlıklarıyla ilgili bulgular çoğu zaman aynı raporda görünür, ancak bunlar TLS ayarlarında değil web sunucusunun başlık yapılandırmasında düzeltilir. İki konuyu birbirinden ayırmak, hangi değişikliğin hangi bulguyu kapattığını izlemeyi kolaylaştırır. HTTP Başlıkları Kontrolü bu bulguları ayrı olarak listeler.

Oturum sürdürme ve performans

Tam bir el sıkışma bir gidiş-dönüşe ve bir miktar işlemci zamanına mal olur; bu yüzden istemciler fırsat buldukları her yerde daha önceki oturumları sürdürmeyi tercih eder. TLS 1.3, eski oturum kimliği ve bilet mekanizmalarının yerine önceki bir oturumdan türetilen önceden paylaşılan anahtarları koydu ve varsayılan olarak sürdürmeyi yine de taze bir anahtar değişimiyle birleştirir. Böylece ileri gizlilik, sürdürülen oturumlar için de korunmuş olur.

TLS 1.2'de ise uzun ömürlü tek bir anahtarla şifrelenen oturum biletleri ileri gizliliği zayıflatır, çünkü o anahtarı ele geçiren biri, biletlerini koruduğu tüm kayıtlı oturumların şifresini sonradan çözebilir. Mozilla'nın profilleri bu nedenle, bilet anahtarları sık sık değiştirilmediği sürece TLS 1.2 oturum biletlerini kapatır. Sunucu üzerindeki paylaşılan bir oturum önbelleği ise bu ödünleşmeye girmeden performans kazancının büyük bölümünü size verir.

HTTP/2 ve HTTP/3, tek bir bağlantıyı çok sayıda istek için yeniden kullanarak TLS el sıkışmalarının sayısını daha da azaltır. HTTP/3, TLS 1.3'ü doğrudan taşıma katmanına gömen QUIC üzerinde çalışır; bunu açmak sertifikanızı değiştirmez ama UDP 443 portunun dışarıya açık olmasını gerektirir. Güvenlik duvarı kuralları yalnızca TCP'ye izin veriyorsa istemciler sessizce TCP üzerinden HTTP/2'ye geri düşer.

Sunucu yapılandırma örnekleri

Aşağıdaki örnekler, bu yazının hazırlandığı tarihteki Mozilla intermediate profilini izler. Öneriler zaman içinde değiştiği için, kendi sunucu ve kitaplık sürümlerinize uyan güncel yapılandırmayı Mozilla SSL Configuration Generator ile üretin. Her değişiklikten sonra sunucuyu yeniden yükleyin ve sonucu dışarıdan bir taramayla kontrol edin. Yapılandırma dosyasının doğru göründüğüne güvenmek yerine, bağlantının gerçekte ne müzakere ettiğine bakın.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:TLS:10m;
ssl_session_tickets off;

SSLProtocol             -all +TLSv1.2 +TLSv1.3
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder     off
SSLSessionTickets       off

example.com {
    tls {
        protocols tls1.2 tls1.3
    }
}

ssl_prefer_server_ciphers off ayarı, izin verilen paketler arasından seçimi istemciye bırakır. Güncel öneri budur, çünkü izin verdiğiniz her paket zaten güçlüdür ve istemci kendisinde AES donanım hızlandırması olup olmadığını sunucudan daha iyi bilir. TLS 1.3 paketleri OpenSSL tabanlı sunucularda ayrı bir ayarla yapılandırılır ve bunların değiştirilmesi nadiren gerekir.

Bir CDN ya da yük dengeleyicinin arkasındayken TLS'i ziyaretçiler için uç nokta sonlandırır; dolayısıyla TLS Kontrolü ve tarayıcılar sizin sunucunuzun değil, o uç noktanın TLS politikasını görür. Minimum sürümü orada ayarlayın ve uç nokta ile kendi sunucunuz arasındaki bağlantıda da TLS kullanın.

Sertifikalar ve anahtar türleri

Özel anahtarları yalnızca TLS'i sonlandıran sunucularda ya da uç platformlarda tutun ve onları yalnızca ihtiyaç duyan servis hesabının okuyabilmesini sağlayın. Herhangi bir sızıntı şüphesinin ardından sertifika yeniden düzenlenirken sadece sertifikayı değil, anahtarı da mutlaka değiştirin. Aynı anahtarla yeniden düzenlenen bir sertifika, sızmış olabilecek anahtar materyalini olduğu gibi kullanımda tutar.

Sertifikanın anahtar türü, hangi paketlerin kullanılabileceğini doğrudan belirler. ECDSA P-256 sertifikaları RSA'ya göre daha küçüktür ve doğrulanmaları daha hızlıdır; RSA 2048 ise neredeyse her yerde desteklenmeye devam eder. Birçok sunucu ikisini aynı anda sunup istemciye göre birini seçebilir, ancak bugünkü istemcilerle tek bir ECDSA ya da RSA sertifikası fazlasıyla yeterlidir.

• Tam zinciri sunun: yaprak sertifika ve ara sertifikalar, kök sertifika değil.
• Yenilemeyi otomatikleştirin; herkesçe güvenilen sertifikaların ömrü CA/Browser Forum kurallarıyla giderek kısalıyor.
• Süre bitimini yenileme işinden bağımsız olarak izleyin; örneğin zamanlanmış bir kontrolde TLS Kontrolü ile ya da XGM API'si ile.
• HTTPS her yerde sorunsuz çalıştıktan sonra HTTP Strict Transport Security ekleyin; HSTS rehberi bu geçişin nasıl yapılacağını anlatır.

Yapılandırmanızı test etmek

Testi her zaman kendi ağınızın dışından yapın, çünkü vekil sunucular ve CDN'ler ziyaretçilerin gördüğü sonucu değiştirir. TLS 1.3 ile 1.2'nin bağlandığını, 1.0 ile 1.1'in reddedildiğini ve sunucunun gerçekte hangi paketleri sunduğunu tek tek kontrol edin. Aşağıdaki komutlar, her ikisi de hemen her sistemde bulunan OpenSSL ve nmap araçlarını kullanır.

# TLS 1.3 should connect
openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null | grep -E 'Protocol|Cipher'

# TLS 1.1 should fail (depending on your OpenSSL build, the client may refuse locally)
openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

# list offered protocol versions and suites
nmap --script ssl-enum-ciphers -p 443 example.com

Taramayı otomatikleştirin. Aynı kontrolleri haftada bir kez ya da her altyapı değişikliğinin ardından çalıştırmak, varsayılan ayarlarıyla devreye alınmış yeni bir yük dengeleyici veya eksik zincirle yenilenmiş bir sertifika gibi gerilemeleri erkenden yakalar. Sonuçları saklayın; böylece yalnızca mevcut durumun yanlış olduğunu değil, bozulmanın tam olarak ne zaman başladığını da görebilirsiniz.

Bir kontrol yalnızca bazı konumlardan başarısız oluyorsa, farklı uç konumların farklı yapılandırmalarla çalıştığı bir CDN ya da anycast kurulumundan veya henüz her çözümleyiciye ulaşmamış bir DNS değişikliğinden şüphelenin. Ana makine adının arkasındaki IP adreslerini tek tek denemek, yani curl'de --resolve ya da OpenSSL'de belirli bir IP'ye -connect kullanmak sorunu çok hızlı biçimde daraltır.

Diğer TLS uç noktalarını da unutmayın: 25, 465 ve 587 portlarındaki posta sunucuları, 993'teki IMAP ve standart dışı portlarda çalışan yönetim panelleri. Bunlar çoğu zaman daha eski varsayılanlarla gelen bambaşka yazılımlar çalıştırır. Port Tarayıcı internet üzerinden hangi portlara erişilebildiğini gösterir.

Uyumluluk ve devreye alma

TLS 1.0 ile 1.1'i kapatmak yalnızca TLS 1.2 konuşamayan istemcileri etkiler; bu da bugün çok eski işletim sistemleri, güncellenmemiş gömülü cihazlar ve birkaç eski entegrasyon demektir. Sunucu günlüklerinizde protokol sürümü kayıtlıysa, kapatma kararını vermeden önce kaç isteğin hâlâ eski sürümleri kullandığına bakın. Birçok ekip bu sayının, tarama botları dışında fiilen sıfır olduğunu görür.

1. Sunucunuz destekliyorsa bir hafta boyunca anlaşılan protokolü ve şifre paketini günlüğe yazın.
2. Geriye kalan eski istemcileri belirleyin; önemli entegrasyonların sahipleriyle önceden iletişime geçin.
3. TLS 1.0 ile 1.1'i ve zayıf TLS 1.2 paketlerini tek bir değişiklikte kapatın, ardından tarayın.
4. Birkaç gün boyunca hata oranlarını ve gelen destek taleplerini yakından izleyin.
5. Yapılandırmayı yılda bir kez güncel Mozilla profiliyle karşılaştırarak gözden geçirin.

SSS

Kaynaklar

• RFC 8446: Aktarım Katmanı Güvenliği (TLS) Protokolü Sürüm 1.3
• RFC 8996: TLS 1.0 ve TLS 1.1'in kullanımdan kaldırılması
• RFC 9325: TLS ve DTLS'in güvenli kullanımı için öneriler (BCP 195)
• RFC 7568: Secure Sockets Layer Sürüm 3.0'ın kullanımdan kaldırılması
• Mozilla SSL Configuration Generator
• Mozilla wiki: Sunucu tarafında TLS