TLS 1.3 Nedir? Avantajları ve Yapılandırması

Ağ trafiğinizi dinleyen biri olduğunu düşünün. Eski TLS sürümleri bu senaryoda ciddi bir risk oluşturuyor. TLS 1.3, bu riski minimize etmek için tasarlanmış ve önceki sürümlere kıyasla hem güvenlik hem de performans açısından devrim niteliğinde değişiklikler getiriyor. 2018 yılında RFC 8446 ile standart hale gelen bu protokol, artık modern sistemlerin vazgeçilmezi. Bu yazıda TLS 1.3’ü derinlemesine inceleyecek, gerçek dünya senaryolarıyla yapılandırmasını göstereceğiz.

TLS 1.3 Neden Önemli?

TLS 1.2, yıllarca güvenilir bir protokol olarak hizmet verdi. Ancak zamanla ortaya çıkan POODLE, BEAST, CRIME gibi saldırılar ve zayıf cipher suite’lerin kullanımı, bu protokolün ciddi güvenlik açıkları barındırdığını gözler önüne serdi. TLS 1.3 ise bu sorunları köklü biçimde ele alıyor.

En temel fark şu: TLS 1.3, handshake sürecini sadeleştirdi. TLS 1.2’de tam bir el sıkışma işlemi 2 round-trip (RTT) gerektirirken, TLS 1.3 bunu 1-RTT’ye indirdi. Hatta önceden bağlanılmış sunucularla 0-RTT bile mümkün. Bu sadece teorik bir gelişme değil; gerçek dünyada sayfa yükleme sürelerinde ölçülebilir iyileşmeler sağlıyor.

Güvenlik tarafında ise şu değişiklikler çok kritik:

Perfect Forward Secrecy (PFS) artık zorunlu, isteğe bağlı değil
RSA key exchange tamamen kaldırıldı, sadece ephemeral Diffie-Hellman kullanılıyor
MD5, SHA-1, RC4, DES, 3DES gibi zayıf algoritmalar protokolden çıkarıldı
Compression desteği kaldırıldı (CRIME saldırısına karşı)
Desteklenen cipher suite sayısı 37’den 5’e indirildi

Desteklenen Cipher Suite’ler

TLS 1.3 sadece şu cipher suite’leri destekliyor:

TLS_AES_256_GCM_SHA384: En güçlü seçenek, kritik sistemler için önerilir
TLS_AES_128_GCM_SHA256: Dengeli performans ve güvenlik
TLS_CHACHA20_POLY1305_SHA256: Mobil cihazlar için optimize, AES donanım hızlandırması olmayan sistemlerde tercih edilir
TLS_AES_128_CCM_SHA256: IoT cihazları için
TLS_AES_128_CCM_8_SHA256: Kısıtlı ortamlar için

Pratik açıdan bakıldığında, web sunucularında genellikle ilk üçü etkinleştirmek yeterli.

Nginx’te TLS 1.3 Yapılandırması

Nginx 1.13.0 ve üzeri sürümler TLS 1.3’ü destekliyor. Ayrıca sisteminizde OpenSSL 1.1.1 veya üzeri kurulu olması gerekiyor.

OpenSSL sürümünüzü kontrol edin:

openssl version -a
nginx -V 2>&1 | grep -o 'with-openssl[^ ]*'

Temel TLS 1.3 yapılandırması:

# /etc/nginx/conf.d/ssl.conf

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # Sadece TLS 1.2 ve 1.3 destekle, eski sürümleri devre dışı bırak
    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.3 cipher suite'leri
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256';

    # Sunucu tercihlerini öne çıkar
    ssl_prefer_server_ciphers on;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # HSTS - 1 yıl, subdomainler dahil
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Session yönetimi
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # DH parametreleri (TLS 1.2 geriye dönük uyumluluk için)
    ssl_dhparam /etc/ssl/dhparam.pem;
}

DH parametrelerini oluşturun:

openssl dhparam -out /etc/ssl/dhparam.pem 4096

Bu komut biraz zaman alabilir, 4096-bit için dakikalarca sürebilir. Sabırlı olun.

Apache’de TLS 1.3 Yapılandırması

Apache 2.4.36 ve üzeri ile OpenSSL 1.1.1 kombinasyonu gerekiyor.

# /etc/apache2/sites-available/example.com-ssl.conf

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    # TLS sürüm kısıtlaması
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # TLS 1.3 için cipher suite'ler
    SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256

    # TLS 1.2 için cipher suite'ler (geriye dönük uyumluluk)
    SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256

    SSLHonorCipherOrder on
    SSLCompression off
    SSLSessionTickets off

    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:/run/apache2/ssl_stapling(32768)"

    # HSTS Header
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Apache’de mod_ssl ve mod_headers modüllerini etkinleştirmeniz gerekiyor:

a2enmod ssl headers
systemctl restart apache2
apache2ctl -M | grep ssl

HAProxy ile TLS 1.3 ve Load Balancer Senaryosu

Büyük ölçekli ortamlarda TLS termination genellikle load balancer katmanında yapılır. HAProxy 2.0 ve üzeri TLS 1.3’ü destekliyor.

# /etc/haproxy/haproxy.cfg

global
    ssl-default-bind-ciphers TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

    # TLS 1.3 0-RTT için dikkat: Replay saldırılarına karşı dikkatli olun
    # ssl-default-bind-options ssl-min-ver TLSv1.3

frontend https_frontend
    bind *:443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1
    mode http

    # TLS sürüm bilgisini backend'e ilet
    http-request set-header X-TLS-Version %[ssl_fc_protocol]
    http-request set-header X-TLS-Cipher %[ssl_fc_cipher]

    # Eski TLS sürümlerini reddet
    http-request deny if { ssl_fc_protocol -i TLSv1 }
    http-request deny if { ssl_fc_protocol -i TLSv1.1 }

    default_backend web_servers

backend web_servers
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check

TLS 1.3’ü Test Etme ve Doğrulama

Yapılandırmayı tamamladıktan sonra test etmek şart. Birkaç farklı yöntem var.

OpenSSL ile bağlantı testi:

# TLS 1.3 bağlantısını test et
openssl s_client -connect example.com:443 -tls1_3

# Hangi protokol ve cipher kullanıldığını gör
openssl s_client -connect example.com:443 -tls1_3 2>&1 | grep -E "Protocol|Cipher"

# Sertifika zincirini kontrol et
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Subject|Issuer|Not After"

# TLS 1.1 ve altını reddettiğini doğrula (bağlantı hata vermeli)
openssl s_client -connect example.com:443 -tls1_1
echo "Çıkış kodu: $?"

Nmap ile tarama:

# SSL/TLS bilgilerini tara
nmap --script ssl-enum-ciphers -p 443 example.com

# Zayıf cipher'ları tespit et
nmap --script ssl-cert,ssl-enum-ciphers -p 443 example.com | grep -E "TLSv|cipher"

Gerçek Dünya Senaryosu: E-Ticaret Sitesinde TLS 1.3 Geçişi

Geçen yıl bir e-ticaret müşterisinin sistemlerini TLS 1.3’e geçirdik. Süreç oldukça öğreticiydi.

Problem: Site PCI DSS uyumluluğu için denetimden geçmesi gerekiyordu. Denetçiler TLS 1.0 ve 1.1’in aktif olduğunu, bazı zayıf cipher’ların kullanıldığını tespit etti.

Ortam: 3 Nginx load balancer, 8 uygulama sunucusu, Ubuntu 20.04

İlk adım mevcut durumu belgelemek oldu:

#!/bin/bash
# tls_audit.sh - Mevcut TLS durumunu belgele

SUNUCULAR=("lb1.internal" "lb2.internal" "lb3.internal")
DOMAIN="example.com"

for sunucu in "${SUNUCULAR[@]}"; do
    echo "=== $sunucu ==="

    # Desteklenen protokolleri kontrol et
    for protokol in tls1 tls1_1 tls1_2 tls1_3; do
        sonuc=$(openssl s_client -connect ${DOMAIN}:443 -${protokol} 2>&1 | grep -E "Protocol|no peer certificate|alert")
        echo "$protokol: $sonuc"
    done

    # Nginx sürümünü kontrol et
    ssh $sunucu "nginx -v 2>&1"
    ssh $sunucu "openssl version"
    echo ""
done

Bu script çıktısında TLS 1.0 ve 1.1’in aktif olduğunu, SHA1 kullanan eski cipher’ların listede bulunduğunu gördük.

Geçiş Planı:

1. Hafta: Staging ortamında TLS 1.3 yapılandırması ve test
2. Hafta: Üretimde bir load balancer’da uygula, monitoring ile izle
3. Hafta: Tüm load balancer’lara yay
4. Hafta: Uygulama sunucularında da güncelle

Kritik nokta şuydu: Bazı eski ödeme sistemleri ve bankacılık API’leri hâlâ TLS 1.2 kullanıyordu. Bu yüzden TLS 1.2’yi tamamen kapatmak yerine, TLS 1.3’ü öncelikli tutup TLS 1.2’yi de etkin bıraktık.

Geçişten sonra şu sonuçları gözlemledik:

Ortalama SSL handshake süresi 45ms’den 28ms’ye düştü
Sayfa yükleme süresi %8 oranında iyileşti
PCI DSS denetiminden başarıyla geçildi

0-RTT Özelliği ve Güvenlik Riskleri

TLS 1.3’ün en çekici özelliklerinden biri 0-RTT (Zero Round Trip Time Resumption). Daha önce bağlanılan sunucularla bağlantıyı neredeyse anında yeniden kurabiliyorsunuz. Ancak bu özellik beraberinde bir güvenlik riski getiriyor: Replay saldırıları.

0-RTT’de gönderilen veriler, saldırgan tarafından yakalanıp tekrar gönderilebilir. Bu yüzden 0-RTT’yi sadece idempotent işlemler için (GET istekleri gibi) kullanmak gerekiyor.

Nginx’te 0-RTT yapılandırması:

# /etc/nginx/conf.d/0rtt.conf

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_protocols TLSv1.3;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # 0-RTT'yi etkinleştir (dikkatli kullanın!)
    ssl_early_data on;

    location / {
        # 0-RTT isteği olup olmadığını kontrol et
        # Replay saldırısı koruması için POST isteklerini reddet
        if ($ssl_early_data) {
            # Early data header'ı ekle, uygulama katmanı kontrol edebilir
            add_header X-Early-Data $ssl_early_data;
        }

        # POST isteklerinde 0-RTT'yi reddet
        if ($request_method = POST) {
            return 425;  # Too Early
        }

        proxy_pass http://backend;
        proxy_set_header Early-Data $ssl_early_data;
    }
}

Genel tavsiyem: Yüksek trafik alan statik içerik sunucularında 0-RTT kullanabilirsiniz, ancak finansal işlemler veya kullanıcı verileri içeren endpoint’lerde kesinlikle etkinleştirmeyin.

Sistem Genelinde TLS Politikası (Linux)

Modern Linux sistemlerinde sistem genelinde bir TLS politikası tanımlayabilirsiniz. Bu özellikle çok sayıda uygulama çalıştıran sunucularda yönetimi kolaylaştırıyor.

RHEL/CentOS/Rocky Linux için:

# Mevcut politikayı görüntüle
update-crypto-policies --show

# TLS 1.3'ü zorunlu kılan politikayı uygula
update-crypto-policies --set FUTURE

# Özel politika oluştur
cat > /etc/crypto-policies/policies/modules/TLS13-ONLY.pmod << 'EOF'
# TLS 1.0 ve 1.1'i devre dışı bırak
protocol@TLS = TLS1.2 TLS1.3
min_tls_version = TLS1.2
EOF

# Özel modülü uygula
update-crypto-policies --set DEFAULT:TLS13-ONLY

# Servisleri yeniden başlat
systemctl restart nginx apache2 haproxy

# Uygulandığını doğrula
update-crypto-policies --show

Ubuntu/Debian’da bu kadar merkezi bir yönetim mekanizması yok, ancak OpenSSL config dosyasını düzenleyebilirsiniz:

# /etc/ssl/openssl.cnf dosyasını düzenle
grep -n "MinProtocol|CipherString" /etc/ssl/openssl.cnf

# Değerleri güncelle
sudo sed -i 's/MinProtocol = None/MinProtocol = TLSv1.2/' /etc/ssl/openssl.cnf
sudo sed -i 's/CipherString = DEFAULT/CipherString = DEFAULT@SECLEVEL=2/' /etc/ssl/openssl.cnf

Sertifika Yönetimi ve OCSP Stapling

TLS 1.3 güvenliğinin tam olarak sağlanması için sertifika yönetimi de kritik. OCSP Stapling, sertifika geçerlilik kontrolünü hızlandırıyor ve kullanıcı gizliliğini koruyor.

Certbot ile Let’s Encrypt sertifikası alın ve OCSP Stapling’i test edin:

# Certbot ile sertifika al
certbot --nginx -d example.com -d www.example.com

# OCSP Stapling'i test et
openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 10 "OCSP Response"

# Sertifika son kullanma tarihini kontrol et
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

# Tüm sertifika detaylarını göster
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | grep -E "Subject Alternative|DNS:"

# Sertifika zincirini doğrula
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/ssl/certs/example.com.crt

Monitoring ve Alerting

TLS yapılandırması bir kez yapılıp bırakılacak bir şey değil. Sertifika son kullanma tarihleri, zayıf cipher kullanımı ve protokol downgrade girişimlerini izlemeniz gerekiyor.

Basit bir monitoring scripti:

#!/bin/bash
# tls_monitor.sh - TLS sağlık kontrolü

DOMAIN=$1
UYARI_GUNU=30
KRITIK_GUNU=7

if [ -z "$DOMAIN" ]; then
    echo "Kullanim: $0 <domain>"
    exit 1
fi

# Sertifika son kullanma tarihini kontrol et
BITIS_TARIHI=$(echo | openssl s_client -connect ${DOMAIN}:443 2>/dev/null | openssl x509 -noout -enddate | cut -d= -f2)
BITIS_UNIX=$(date -d "${BITIS_TARIHI}" +%s)
SIMDI_UNIX=$(date +%s)
KALAN_GUN=$(( (BITIS_UNIX - SIMDI_UNIX) / 86400 ))

echo "Domain: $DOMAIN"
echo "Sertifika bitiş tarihi: $BITIS_TARIHI"
echo "Kalan gün: $KALAN_GUN"

if [ $KALAN_GUN -lt $KRITIK_GUNU ]; then
    echo "KRITIK: Sertifika $KALAN_GUN gun sonra sona eriyor!"
    # Slack/PagerDuty bildirimi gönder
elif [ $KALAN_GUN -lt $UYARI_GUNU ]; then
    echo "UYARI: Sertifika $KALAN_GUN gun sonra sona eriyor."
fi

# TLS sürümünü kontrol et
PROTOKOL=$(echo | openssl s_client -connect ${DOMAIN}:443 2>/dev/null | grep "Protocol")
echo "Kullanılan protokol: $PROTOKOL"

# TLS 1.3 kullanılıyor mu?
if echo $PROTOKOL | grep -q "TLSv1.3"; then
    echo "BASARILI: TLS 1.3 aktif"
else
    echo "UYARI: TLS 1.3 kullanilmiyor!"
fi

# Zayıf protokolleri kontrol et
for zayif_protokol in tls1 tls1_1; do
    if openssl s_client -connect ${DOMAIN}:443 -${zayif_protokol} 2>&1 | grep -q "Cipher"; then
        echo "KRITIK: Zayif protokol aktif: $zayif_protokol"
    fi
done

Bu scripti crontab’a ekleyerek düzenli çalıştırabilirsiniz:

# Her gün sabah 9'da çalıştır
echo "0 9 * * * /usr/local/bin/tls_monitor.sh example.com >> /var/log/tls_monitor.log 2>&1" | crontab -

Sorun Giderme

TLS 1.3 geçişinde karşılaşılan yaygın sorunlar:

Eski Java uygulamalarıyla uyumsuzluk: Java 8 update 261 öncesi sürümler TLS 1.3’ü desteklemiyor. Çözüm ya Java’yı güncellemek ya da bu uygulamalar için TLS 1.2’yi etkin tutmak.

Wireshark ile analiz yaparken: TLS 1.3 trafiği PFS nedeniyle session key olmadan deşifrelenemez. SSLKEYLOGFILE ortam değişkenini kullanabilirsiniz:

# Firefox veya Chrome için debug amaçlı
export SSLKEYLOGFILE=/tmp/ssl_keys.log
firefox &

# Wireshark'ta bu dosyayı yükle:
# Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename

SSL Labs testi: Yapılandırmanızı ssllabs.com/ssltest adresinden test edin. A+ almak hedefleyin. Dikkat etmeniz gereken parametreler: Protocol Support, Key Exchange, Cipher Strength skorları.

Sonuç

TLS 1.3 artık bir lüks değil, zorunluluk. RFC 8446’nın yayınlanmasının üzerinden birkaç yıl geçti ve büyük tarayıcılar, CDN’ler, cloud sağlayıcılar bu protokolü varsayılan olarak kullanıyor. Siz hâlâ TLS 1.0 veya 1.1 çalıştırıyorsanız, sadece güvenlik riski almıyorsunuz; aynı zamanda PCI DSS, HIPAA gibi uyumluluk gereksinimlerini de karşılamıyor olabilirsiniz.

Bu yazıda anlattığımız yapılandırmaları uygularken şu noktaları aklınızda tutun:

TLS 1.0 ve 1.1’i kapatmadan önce eski sistemlerle bağımlılıklarınızı belgeleyin
TLS 1.2’yi hemen kapatmayın, geçiş döneminde her ikisini de aktif tutun
0-RTT’yi dikkatli kullanın, her endpoint için uygun değil
Sertifika izlemeyi otomatize edin, süresi dolan sertifika en yaygın downtime sebebi
Düzenli SSL Labs testi yapın, yapılandırmanız zamanla eski kalabilir

Herhangi bir soruyla karşılaşırsanız veya kendi ortamınızda farklı senaryolar yaşadıysanız yorum bölümünde paylaşın. Özellikle legacy sistemlerle TLS 1.3 uyumluluk sorunları her ortamda farklı tezahür edebiliyor; deneyimlerinizi duymak isterim.

TLS 1.3 Nedir: Yeni Protokolün Avantajları ve Yapılandırması