TLS 1.3 Nedir ve TLS 1.2'den Farkı Ne?

Bir kullanıcı tarayıcısına adresinizi yazıp Enter'a bastığında, o sayfa yüklenmeden önce arka planda sizin sunucunuzla tarayıcı arasında görünmez bir pazarlık yaşanır. Bu pazarlıkta iki taraf hangi şifreleme yöntemini kullanacaklarına karar verir, kimlik doğrular ve ortak bir gizli anahtar üretir. İşte bu sürecin adı TLS el sıkışması (handshake) ve hangi TLS sürümünü konuştuğunuz, hem sitenizin ne kadar hızlı açıldığını hem de ne kadar güvenli olduğunu doğrudan belirler. TLS 1.3, 2018 yılında RFC 8446 ile standartlaştırılan ve bugün modern web'in fiili varsayılanı olan sürümdür.

Yıllardır TLS 1.2 üzerine kurulu bir dünyada yaşadık ve açıkçası TLS 1.2 hâlâ güvenli sayılabilecek şekilde yapılandırılabilir. Ancak TLS 1.3, yalnızca küçük bir iyileştirme değil; protokolün baştan sona gözden geçirildiği, onlarca yıllık saldırı deneyiminin ışığında güvensiz her şeyin söküldüğü bir yeniden tasarımdır. Bu yazıda TLS 1.3'ün neden ortaya çıktığını, hangi zayıf halkaları temizlediğini, el sıkışmayı nasıl tek gidiş-gelişe indirdiğini ve 0-RTT'nin hem baş döndürücü hızını hem de gizli risklerini bir kıdemli sistem yöneticisinin gözünden anlatacağım. Sonunda da Nginx ve Apache üzerinde TLS 1.3'ü açıp eski sürümleri güvenle kapatmanın somut örneklerini bulacaksınız.

TLS Sürümlerinin Kısa Tarihi ve TLS 1.3 Neden Geldi#

TLS'in atası SSL'dir. Netscape'in 1990'ların ortasında geliştirdiği SSL 2.0 ve SSL 3.0 bugün tamamen kırık kabul edilir; POODLE gibi saldırılar SSL 3.0'ı kullanılamaz hâle getirdi. Ardından TLS 1.0 (1999), TLS 1.1 (2006) ve TLS 1.2 (2008) geldi. TLS 1.2 uzun süre standart oldu ve iyi yapılandırıldığında güçlüydü. Sorun şuydu: TLS 1.2 esneklikten yana o kadar cömertti ki, içinde artık güvensiz sayılan onlarca şifre takımını (cipher suite) ve zayıf algoritmayı barındırıyordu. Yöneticinin yanlış bir tercihi tüm bağlantıyı kırılgan hâle getirebiliyordu.

TLS 1.3 tam olarak bu "ayağına sıkma" özgürlüğünü ortadan kaldırmak için doğdu. Tasarım felsefesi netti: güvensiz olan her seçeneği protokolden fiziksel olarak çıkar, geriye yalnızca modern ve kanıtlanmış yöntemleri bırak. Aynı zamanda el sıkışmayı hızlandırarak performansı da bir üst seviyeye taşıdı. Yani TLS 1.3 aynı anda iki hedefi birden vurdu; hem daha güvenli hem de daha hızlı. Bu ikili kazanç, sektörün TLS 1.3'e neden bu kadar hızlı geçtiğini açıklar.

Bir başka önemli motivasyon geriye dönük gizlilikti. Eski TLS sürümlerinde RSA anahtar değişimi kullanıldığında, sunucunun özel anahtarı bir gün ele geçirilirse, saldırgan geçmişte kaydettiği tüm trafiği geriye dönük olarak çözebiliyordu. TLS 1.3 bu senaryoyu tamamen imkânsız kılar. Bu kavramın adı ileri gizliliktir (forward secrecy) ve TLS 1.3'te artık bir seçenek değil, zorunluluktur.

TLS 1.3'ün Kaldırdığı Güvensiz Özellikler#

TLS 1.3'ün en büyük katkısı eklediği değil, çıkardığı şeylerdir. Protokolden sökülen unsurlar yıllar içinde gerçek saldırılara yol açmış zayıflıklardır. Aşağıdaki liste, TLS 1.3'te artık desteklenmeyen başlıca öğeleri özetler.

• RSA anahtar değişimi: İleri gizlilik sağlamadığı ve Bleichenbacher türü saldırılara zemin hazırladığı için kaldırıldı. Yerini yalnızca geçici Diffie-Hellman (ECDHE) aldı.
• Statik Diffie-Hellman: Yine ileri gizlilik eksikliği nedeniyle elendi.
• RC4 akış şifresi: Yıllar önce kriptografik olarak kırıldı, tamamen yasaklandı.
• 3DES ve blok bazlı CBC modları: BEAST, Lucky13 gibi saldırılara açık oldukları için çıkarıldı. TLS 1.3 sadece AEAD (Authenticated Encryption with Associated Data) modlarını kabul eder.
• MD5 ve SHA-1 imza algoritmaları: Çakışma saldırılarına karşı savunmasız oldukları için yasaklandı.
• Sıkıştırma (TLS compression): CRIME saldırısının kaynağıydı, kaldırıldı.
• Yeniden pazarlık (renegotiation): Karmaşık ve tehlikeli bir mekanizmaydı, protokolden çıkarıldı.
• Özel/statik IV ve ad hoc yapı taşları: Yerini temiz ve tutarlı bir tasarım aldı.

Sonuç olarak TLS 1.3'te desteklenen simetrik şifre takımı sayısı beş civarına indi. TLS 1.2'de yüzlerce kombinasyon arasından "doğru" olanı seçmek yöneticinin sorumluluğundayken, TLS 1.3'te her seçenek zaten güvenlidir. Bu yalınlık, yanlış yapılandırma kaynaklı güvenlik açıklarını neredeyse imkânsız hâle getirir. SSL sertifikalarının bu resimdeki rolünü merak ediyorsanız SSL sertifikası nedir yazımız iyi bir başlangıç noktasıdır.

Tek Gidiş-Gelişe İnen El Sıkışma (1-RTT)#

Performans farkının kalbi el sıkışmanın kaç tur sürdüğüdür. Burada RTT (Round-Trip Time) yani bir paketin gidip dönme süresi kritik bir metriktir. TLS 1.2'de tam bir el sıkışma iki RTT gerektirirdi. İstemci "merhaba" der, sunucu sertifikasını ve parametrelerini gönderir, istemci anahtar bilgisini paylaşır, ancak bundan sonra şifreli uygulama verisi akmaya başlayabilir. İki taraf arasında iki tam tur.

TLS 1.3 bu süreci tek RTT'ye indirdi. Bunu başarmanın yolu, istemcinin ilk mesajında tahminde bulunmasıdır. İstemci daha en baştan, muhtemelen kullanılacak anahtar değişim gruplarını (örneğin X25519) ve kendi geçici anahtar paylaşımını (key share) "merhaba" mesajına iliştirir. Sunucu bu tahminin doğru olduğunu görürse tek yanıtta hem sertifikasını hem kendi anahtar paylaşımını hem de "el sıkışma bitti" onayını gönderir. Böylece ikinci tura gerek kalmaz.

Aşağıdaki tablo iki sürüm arasındaki tur farkını netleştirir.

Pratikte bu ne demek? Türkiye'den ABD'deki bir sunucuya gecikmenin 120 ms olduğu bir senaryoda, tek fazla RTT'yi ortadan kaldırmak her yeni bağlantıda yaklaşık 120 ms kazandırır. Mobil ağlarda ve yüksek gecikmeli bağlantılarda bu fark, sayfanın açılma hissini gözle görülür şekilde iyileştirir. Özellikle çok sayıda farklı alan adına bağlanan modern web sayfalarında bu kazanç katlanarak artar.

0-RTT Nedir, Avantajları ve Riskleri#

TLS 1.3'ün en çok konuşulan ve en yanlış anlaşılan özelliği 0-RTT'dir (Zero Round-Trip Time). Fikir şudur: daha önce bağlandığınız bir sunucuya tekrar bağlanırken, önceki oturumdan hatırladığınız bir "ön paylaşılan anahtar" (PSK) sayesinde el sıkışmayı beklemeden, ilk pakette hemen uygulama verisi göndermek. Yani istemci "merhaba" ile birlikte ilk HTTP isteğini de yollar. Bu, tekrar eden bağlantılarda gecikmeyi teorik olarak sıfıra indirir.

Kulağa mükemmel geliyor, ama bir bedeli var ve bu bedeli anlamadan 0-RTT'yi açmak tehlikelidir. 0-RTT verisi, tam el sıkışma tamamlanmadan gönderildiği için tekrar saldırısına (replay attack) açıktır. Bir saldırgan 0-RTT ile gönderilen şifreli paketi yakalayıp aynı sunucuya defalarca yeniden gönderebilir. Eğer bu istek durum değiştiren bir işlemse, örneğin "hesabımdan 100 TL transfer et" gibi, aynı işlem birden çok kez tetiklenebilir. Ayrıca 0-RTT verisi, normal el sıkışma verisinin sahip olduğu ileri gizlilik güvencesinden yoksundur.

Bu yüzden altın kural nettir: 0-RTT yalnızca idempotent (tekrarlanması zarar vermeyen) ve yan etkisi olmayan isteklerde kullanılmalıdır. GET türü, salt okuma isteklerinde sorun yoktur; ama POST, PUT, DELETE gibi durum değiştiren isteklerde asla 0-RTT'ye izin verilmemelidir. Çoğu web sunucusu 0-RTT'yi varsayılan olarak kapalı tutar. Açacaksanız uygulama katmanınızda tekrar korumasına (replay protection) sahip olduğunuzdan emin olun. Benim önerim, gerçekten yüksek gecikmeli bir kullanıcı kitleniz ve uygun bir uygulama mimariniz yoksa 0-RTT'yi kapalı bırakmanızdır. Hız kazancı çoğu site için, açtığı risk yanında marjinaldir.

Nginx'te TLS 1.3'ü Açma ve Eski Sürümleri Kapatma#

TLS 1.3 desteği için Nginx'in OpenSSL 1.1.1 veya üzeri ile derlenmiş olması gerekir. Güncel bir dağıtım kullanıyorsanız bu koşul zaten sağlanmıştır. Önce OpenSSL sürümünüzü doğrulayın.

nginx -V 2>&1 | grep -o 'OpenSSL[^ ]* [0-9.]*'
openssl version

Çıktıda OpenSSL 1.1.1 veya OpenSSL 3.x görüyorsanız hazırsınız. Şimdi sunucu bloğunda ya da SSL yapılandırma dosyanızda protokol sürümlerini ayarlayın. Amaç TLS 1.2 ve TLS 1.3'ü açık tutup, TLS 1.0 ve 1.1'i tamamen kapatmaktır.

server {
    listen 443 ssl;
    http2 on;
    server_name ornek.com.tr;

    ssl_certificate     /etc/ssl/ornek/fullchain.pem;
    ssl_certificate_key /etc/ssl/ornek/privkey.pem;

    # Sadece modern sürümler
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.3 şifre takımları OpenSSL tarafından otomatik seçilir.
    # Aşağıdaki liste yalnızca TLS 1.2 içindir.
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

    # TLS 1.3'te sunucu tercihi kavramı değişti; bu satır TLS 1.2 için anlamlı.
    ssl_prefer_server_ciphers off;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off;

    # 0-RTT varsayılan olarak kapalı; bilinçli açmadıkça dokunmayın.
    # ssl_early_data on;
}

Burada önemli bir ayrıntı var: TLS 1.3 şifre takımları ssl_ciphers direktifiyle yönetilmez. OpenSSL, TLS 1.3 için kendi güvenli varsayılan takımlarını (AES-GCM ve ChaCha20-Poly1305) otomatik kullanır. Yani ssl_ciphers satırınız yalnızca TLS 1.2 bağlantılarını etkiler. Değişikliği yaptıktan sonra yapılandırmayı test edip yeniden yükleyin.

nginx -t
systemctl reload nginx

Bağlantınızı hemen komut satırından doğrulayabilirsiniz. Aşağıdaki komut sunucuya doğrudan TLS 1.3 ile bağlanmayı dener.

openssl s_client -connect ornek.com.tr:443 -tls1_3 </dev/null 2>/dev/null | grep -i 'Protocol\|Cipher'

Çıktıda Protocol: TLSv1.3 ve TLS_AES_256_GCM_SHA384 gibi bir şifre görürseniz her şey yolundadır. HTTPS'e geçiş ve yönlendirme kurgusuyla ilgili bütünsel bir bakış için HTTPS yönlendirme yazımızı da inceleyebilirsiniz.

Apache'de TLS 1.3 Yapılandırması#

Apache tarafında da mantık aynıdır; yeter ki mod_ssl, OpenSSL 1.1.1 veya üzeri ile derlenmiş olsun. Apache 2.4.37 ve sonrası TLS 1.3'ü tam destekler. Sanal sunucu yapılandırmanızda SSLProtocol direktifini kullanarak eski sürümleri kapatın.

<VirtualHost *:443>
    ServerName ornek.com.tr

    SSLEngine on
    SSLCertificateFile    /etc/ssl/ornek/fullchain.pem
    SSLCertificateKeyFile /etc/ssl/ornek/privkey.pem

    # TLS 1.0, 1.1 ve daha eskisini devre dışı bırak
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # TLS 1.2 şifre takımları
    SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384

    # TLS 1.3'e özel şifre takımları (isteğe bağlı, varsayılanlar zaten güvenli)
    SSLOpenSSLConfCmd Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

    SSLHonorCipherOrder off
</VirtualHost>

SSLProtocol -all +TLSv1.2 +TLSv1.3 ifadesi "her şeyi kapat, sonra sadece 1.2 ve 1.3'ü aç" anlamına gelir; bu, eski sürümleri kapatmanın en temiz yoludur. TLS 1.3 şifre takımlarını özelleştirmek isterseniz SSLOpenSSLConfCmd Ciphersuites satırını kullanabilirsiniz, ancak varsayılanları değiştirmeye çoğu durumda gerek yoktur. Yapılandırmayı test edip Apache'yi yeniden başlatın.

apachectl configtest
systemctl reload apache2   # Debian/Ubuntu
# veya
systemctl reload httpd     # RHEL/AlmaLinux

Sunucu yönetimi konusunda kendinizi rahat hissetmiyorsanız veya bu ayarları sizin adınıza güvenle yapacak bir ekip istiyorsanız sunucu yönetimi hizmetimiz tam da bu tür yapılandırmaları kapsar.

Yapılandırmayı Doğrulama, Test Etme ve HSTS#

Değişikliği yapmak yarısı; doğru yaptığınızı kanıtlamak diğer yarısıdır. En pratik yöntem, hangi sürümlerin açık olduğunu tek tek denemektir. Aşağıdaki komut TLS 1.0 ile bağlanmayı dener ve başarısız olmasını (yani kapalı olmasını) beklersiniz.

# Bu bağlanma reddedilmeli:
openssl s_client -connect ornek.com.tr:443 -tls1 </dev/null

# Bu bağlanmalı:
openssl s_client -connect ornek.com.tr:443 -tls1_3 </dev/null

Daha kapsamlı bir tarama için nmap betiği tüm desteklenen sürüm ve şifreleri listeler.

nmap --script ssl-enum-ciphers -p 443 ornek.com.tr

Yapılandırmanızı tamamladıktan sonra tarayıcının siteye asla düz HTTP ile bağlanmamasını garantilemek için HSTS başlığını da eklemenizi öneririm. Bu, TLS'in üzerine oturan tamamlayıcı bir güvenlik katmanıdır.

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Son olarak, dışarıdan bağımsız bir değerlendirme için SSL Labs gibi çevrimiçi test araçlarını çalıştırın; A veya A+ notu almak, hem sürüm hem şifre yapılandırmanızın sağlıklı olduğunun iyi bir göstergesidir. Güvenlik denetimi ve site sağlığı araçlarını topluca kullanmak isterseniz araçlar sayfamıza göz atabilirsiniz.

TLS 1.3'ün SEO ve Kullanıcı Deneyimine Etkisi#

Güvenlik kadar önemli bir başka boyut da performans ve arama motoru sıralamasıdır. Google, HTTPS'i uzun süredir bir sıralama sinyali olarak kullanıyor ve Core Web Vitals metrikleri sayfa hızını doğrudan ödüllendiriyor. TLS el sıkışmasının bir RTT kısalması, özellikle bağlantı kurma süresinin (connection setup) baskın olduğu mobil senaryolarda, ilk baytın gelme süresine (TTFB) olumlu yansır. Yani TLS 1.3'e geçmek yalnızca güvenlik hijyeni değil, aynı zamanda ölçülebilir bir hız kazancıdır.

Bu kazanç, özellikle çok sayıda üçüncü taraf kaynağa bağlanan içerik ağırlıklı sitelerde birikir. Her yeni alan adına yapılan TLS el sıkışması bir RTT daha az sürerse, sayfanın etkileşime hazır olma süresi kısalır. WordPress gibi eklenti yoğun platformlarda bu fark hissedilir hâle gelir; WordPress hosting altyapımızda TLS 1.3 zaten varsayılan olarak açıktır. Arama görünürlüğünüzü bütünsel iyileştirmek istiyorsanız teknik hız optimizasyonunu içeriğe dayalı SEO çalışmalarıyla birlikte ele almanız en verimli sonucu verir. Kısacası TLS 1.3, güvenlik ve performansı aynı anda iyileştirdiği için nadir bulunan bir "kaybedeni olmayan" güncellemedir.

Sıkça Sorulan Sorular#

TLS 1.2 hâlâ güvenli mi, yoksa hemen kapatmalı mıyım?#

TLS 1.2 doğru şifre takımlarıyla yapılandırıldığında hâlâ güvenli kabul edilir ve pek çok eski istemci yalnızca TLS 1.2'yi desteklediği için tamamen kapatmak uyumluluk sorunları yaratabilir. Önerilen yaklaşım, TLS 1.2 ve TLS 1.3'ü birlikte açık tutup TLS 1.0 ile 1.1'i tamamen devre dışı bırakmaktır. Böylece hem modern istemcilere en hızlı ve en güvenli deneyimi sunar, hem de eski cihazların erişimini korursunuz. Zamanla istatistiklerinizde TLS 1.2 kullanımı ihmal edilebilir düzeye indiğinde onu da kapatmayı düşünebilirsiniz.

TLS 1.3'ü açmak için sertifikamı değiştirmem gerekiyor mu?#

Hayır, mevcut SSL sertifikanız TLS 1.3 ile sorunsuz çalışır. Sertifika, sunucunuzun kimliğini doğrulayan bileşendir; TLS sürümü ise o kimlik doğrulamadan sonra kullanılan protokoldür. Yani aynı Let's Encrypt veya ticari sertifikanızla hem TLS 1.2 hem TLS 1.3 bağlantılarını aynı anda sunabilirsiniz. Değiştirmeniz gereken tek şey sunucu yazılımınızın protokol yapılandırmasıdır. Sertifikaların nasıl çalıştığını daha derin anlamak isterseniz konuyla ilgili ayrı rehberimiz yardımcı olur.

0-RTT'yi açmalı mıyım?#

Çoğu web sitesi için kısa cevap hayırdır. 0-RTT, tekrar saldırısı riskini beraberinde getirir ve yalnızca tekrarlanması zararsız olan salt okuma istekleri için güvenlidir. Eğer uygulamanız kritik veya durum değiştiren işlemleri düzgün ayırt etmiyor ve tekrar korumasına sahip değilse, 0-RTT açmanın getireceği küçük hız kazancı, yaratacağı güvenlik riskine değmez. Yüksek gecikmeli bir kullanıcı kitleniz varsa ve uygulama mimariniz uygunsa, dikkatli bir değerlendirmeyle açmayı düşünebilirsiniz.

Sunucumun TLS 1.3 desteklediğini nasıl anlarım?#

En pratik yöntem komut satırından doğrudan bağlanmayı denemektir. openssl s_client -connect siteadi.com:443 -tls1_3 komutunu çalıştırıp çıktıda Protocol: TLSv1.3 ifadesini görürseniz sunucunuz TLS 1.3'ü destekliyor demektir. Ayrıca nginx -V veya openssl version komutuyla OpenSSL sürümünüzün 1.1.1 ya da üzeri olduğunu doğrulayabilirsiniz, çünkü TLS 1.3 bu sürümlerle gelir. SSL Labs gibi çevrimiçi test araçları da desteklenen tüm sürümleri görsel bir raporla listeler.

TLS 1.3 kullanınca eski tarayıcılar siteme erişemez mi?#

TLS 1.2'yi de açık tuttuğunuz sürece eski istemciler sorun yaşamaz; onlar otomatik olarak TLS 1.2 ile bağlanır, yalnızca TLS 1.3 destekleyen modern tarayıcılar daha hızlı olan yeni protokolü kullanır. Sorun ancak yalnızca TLS 1.3'ü açıp TLS 1.2'yi de kapatırsanız ortaya çıkar; bu durumda eski Android sürümleri veya çok eski masaüstü tarayıcıları erişemeyebilir. Bu yüzden geçiş dönemi boyunca iki sürümü birlikte sunmak en güvenli stratejidir.

TLS 1.3 gerçekten siteyi hızlandırır mı, yoksa fark ihmal edilebilir mi?#

Fark gerçek ve ölçülebilir, ama büyüklüğü kullanıcının gecikmesine bağlıdır. El sıkışmanın bir RTT kısalması, düşük gecikmeli yerel bağlantılarda birkaç milisaniye kazandırırken, yüksek gecikmeli mobil veya uluslararası bağlantılarda yüz milisaniyeye varan iyileşme sağlar. Bu kazanç özellikle çok sayıda yeni bağlantı kuran sayfalarda birikerek belirginleşir. Performansın kritik olduğu senaryolarda TLS 1.3'ün katkısı hem kullanıcı deneyimine hem de arama motoru metriklerine yansır.

Kapanış#

TLS 1.3, güvenlik ve performansı aynı anda iyileştiren nadir güncellemelerden biridir. Güvensiz her şeyi protokolden söküp yalnızca modern yöntemleri bırakması, yanlış yapılandırma kaynaklı açıkları neredeyse imkânsız kılar; el sıkışmayı tek RTT'ye indirmesi ise her yeni bağlantıda gözle görülür hız kazandırır. 0-RTT gibi ileri özellikleri ise ancak riskini anlayarak ve uygulamanız buna hazırsa kullanmalısınız. Yapmanız gereken temel adım nettir: TLS 1.2 ve 1.3'ü birlikte açın, 1.0 ile 1.1'i kapatın ve yapılandırmanızı bağımsız araçlarla doğrulayın.

Bu ayarları kendiniz yönetmek yerine altyapının sizin için doğru yapılandırıldığı bir ortam istiyorsanız, Clou.TR paketleri işinizi kolaylaştırır. Modern TLS'in varsayılan geldiği hosting ve web hosting planlarımıza göz atabilir, tam kontrol isteyen ekipler için sanal sunucu ve VDS çözümlerimizi değerlendirebilir, güçlü bir uçtan uca koruma için SSL ve WAF hizmetlerimizle bağlantınızı katmanlı biçimde güvenceye alabilirsiniz. Güvenli ve hızlı bir web deneyimi, doğru altyapıyla başlar.