TLS 1.3 ve HTTPS Güvenliği: HSTS, Sertifika, OCSP Stapling ve mTLS Rehberi

TLS 1.3 ve HTTPS güvenliği, web sunucusuna bir sertifika yükleyip 443 numaralı portu açmaktan ibaret değildir. Protokol sürümü, sertifika zinciri, alan adı doğrulaması, HSTS, oturum devamı, 0-RTT, OCSP Stapling, mTLS, anahtar saklama ve izleme birlikte tasarlanmadığında tarayıcıda kilit simgesi görünse bile sistem downgrade, yanlış sertifika, replay veya operasyonel kesinti riski taşıyabilir.

TLS 1.3, RFC 8446 ile eski şifreleme seçeneklerini azaltır, ileri gizliliği temel hâle getirir ve handshake mesajlarının daha büyük bölümünü şifreler. Buna rağmen güvenli sonuç otomatik değildir. RFC 9325'in güncel iyi uygulamaları doğrultusunda TLS 1.2 yalnızca uyumluluk gerektiğinde güçlü AEAD kümeleriyle tutulmalı; TLS 1.0 ve 1.1 devre dışı bırakılmalıdır.

Bu rehber, internet sitesi, API, reverse proxy ve servisler arası trafik için üretime dönük bir HTTPS sertleştirme modeli sunar. Örnekler başlangıç noktasıdır; kullandığınız Nginx, Apache, HAProxy, Envoy, CDN, WAF ve OpenSSL sürümünün belgeleriyle doğrulanmalıdır.

TLS hangi güvenlik özelliklerini sağlar?

TLS, istemci ile sunucu arasında üç temel özellik kurar:

Kimlik doğrulama: Sunucu sertifikası, istemcinin doğru alan adı ve güven zinciriyle konuştuğunu doğrulamasına yardım eder. mTLS kullanılırsa istemci de sertifikayla doğrulanabilir.
Gizlilik: Uygulama verisi ağ üzerinde okunamaz hâle gelir. TLS trafik hacmini, hedef IP'yi ve tüm meta verileri gizlemez.
Bütünlük: Aktarım sırasında değiştirilen kayıtlar doğrulama hatası üretir.

TLS uygulama yetkilendirmesinin yerine geçmez. Geçerli bir istemci sertifikası kullanıcının her kaynağa erişebileceği anlamına gelmez; API yine tenant, rol, nesne ve işlem düzeyinde yetki kontrolü yapmalıdır. Benzer şekilde HTTPS, uygulamadaki XSS, SQL injection veya güvensiz dosya yükleme açıklarını düzeltmez.

TLS 1.3 neden farklıdır?

TLS 1.3, TLS 1.2'ye göre daha dar ve modern bir kriptografik yüzey sunar:

Alan	TLS 1.2	TLS 1.3
Şifre kümeleri	Anahtar değişimi, imza, şifre ve hash tek ad içinde birleşebilir	Kümeler yalnızca AEAD şifre ve hash seçimini ifade eder
Anahtar değişimi	Statik RSA ve çeşitli eski seçenekler bulunabilir	(EC)DHE veya PSK temelli modern akış; statik RSA kaldırılmıştır
İleri gizlilik	Seçilen kümeye bağlıdır	Public-key handshake için varsayılan tasarım özelliğidir
Handshake gizliliği	Daha fazla mesaj açık görülebilir	ServerHello sonrasındaki handshake mesajları şifrelenir
Eski algoritmalar	CBC, RC4 veya özel DHE yapılandırmalarıyla karşılaşılabilir	Yalnızca AEAD; eski seçenekler kaldırılmıştır
0-RTT	Yok	Oturum devamında mümkün, fakat replay riski taşır

TLS 1.3'te yaygın AEAD seçenekleri AES-128-GCM, AES-256-GCM ve ChaCha20-Poly1305'tir. Sunucu yöneticisi bunlardan birini evrensel olarak “tek doğru” ilan etmek yerine istemci donanımı, uyumluluk ve kripto kitaplığının güvenli varsayımlarını değerlendirmelidir. TLS 1.3 şifre kümeleri çoğu yazılımda TLS 1.2 için kullanılan ssl_ciphers ayarından ayrı yönetilir.

Önerilen protokol politikası

Genel internet servisleri için pratik taban çizgisi:

TLS 1.3'ü etkinleştirin.
Eski istemci zorunluluğu varsa TLS 1.2'yi güçlü AEAD + ECDHE kümeleriyle koruyun.
TLS 1.0 ve TLS 1.1'i devre dışı bırakın.
SSLv2, SSLv3, RC4, 3DES, statik RSA anahtar değişimi, anonim DH ve export kümelerini kabul etmeyin.
TLS 1.2 için sunucu tercih sırasını ve eğri/grup seçimini güncel kitaplık varsayımlarıyla test edin.
İstemci kitlenizi gerçek telemetry ile ölçmeden TLS 1.2'yi kaldırmayın.

Nginx için sürüm taban çizgisi aşağıdaki kadar sade olabilir:

CODE TERMINAL

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

    ssl_certificate     /etc/nginx/tls/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
}

Bu örnek tek başına tam sertleştirme değildir. TLS 1.2 cipher politikası, sertifika zinciri, anahtar izinleri, HSTS, OCSP, loglama ve otomatik yenileme ayrıca yapılandırılmalıdır. İnternetten kopyalanmış uzun cipher listeleri zamanla eskir; Mozilla SSL Configuration Generator gibi güncel bir üretici ve kullandığınız yazılımın resmî belgeleriyle karşılaştırma yapın.

Sertifika zinciri doğru nasıl sunulur?

Sunucu genellikle leaf sertifika ile gerekli intermediate CA sertifikalarını sunmalıdır. Root CA çoğu durumda gönderilmez; istemci onu kendi güven deposundan bulur. Eksik intermediate zinciri bazı tarayıcılarda önbellek nedeniyle çalışıyor gibi görünürken temiz cihaz, mobil uygulama veya API istemcisinde doğrulama hatası üretebilir.

Sertifikanın Subject Alternative Name alanında kullanılan bütün DNS adlarının bulunduğunu doğrulayın.
CN alanına tek başına güvenmeyin; modern istemciler SAN eşleşmesini kullanır.
Leaf sertifika ile private key'in eşleştiğini dağıtımdan önce kontrol edin.
Full chain dosyasındaki sırayı leaf → intermediate biçiminde doğrulayın.
Süresi dolmuş veya gereksiz cross-signed zincirleri kaldırın.
Wildcard sertifikanın yalnızca tek etiket seviyesini kapsadığını ve kök alanı otomatik kapsamadığını unutmayın.

CODE TERMINAL

# Sunucunun sunduğu zinciri ve SAN alanını inceleme
openssl s_client -connect example.com:443 -servername example.com -showcerts

Son iki özet eşleşmelidir. Private key'i komut çıktısına, CI günlüklerine veya ticket sistemine yazmayın.

Private key nasıl korunmalı?

TLS private key, sunucu kimliğinin en hassas varlıklarından biridir. Dosya tabanlı anahtar kullanılıyorsa yalnızca servis hesabının okuyabileceği izinler verin; yedek, container image ve configuration repository içine kopyalamayın.

Yüksek değerli sistemlerde HSM, bulut KMS/HSM entegrasyonu veya managed certificate hizmeti değerlendirin. Anahtar üretimi, sertifika isteği, dağıtım, yenileme, iptal ve olay anı rotasyonu tek bir yaşam döngüsü olarak otomatikleştirilmelidir.

Risk	Kontrol
Kaynak kodda anahtar	Secret taraması, repository geçmişi temizliği ve derhal rotasyon
Container image içinde anahtar	Runtime secret mount, kısa ömürlü dosya veya proxy termination
Birden çok sunucuya elle kopyalama	Merkezi secret dağıtımı, sürümleme ve erişim kaydı
Çok geniş dosya izni	Ayrı servis hesabı, 0600 benzeri en az yetki
Yedekte düz metin	Şifreli yedek, ayrı anahtar yönetimi ve geri yükleme testi
Anahtar sızıntısı	Sertifika iptali, yeni anahtar üretimi ve uçtan uca yeniden dağıtım

ACME ile otomatik yenileme

RFC 8555 ile tanımlanan ACME, sertifika alma ve yenilemeyi otomatikleştirir. Ancak otomasyon yalnızca sertifikayı üretmek değil, yeni sertifikayı doğru servise dağıtmak, yapılandırmayı doğrulamak, servisi güvenli biçimde reload etmek ve dışarıdan test etmek anlamına gelir.

Yenilemeyi son güne bırakmayın; sertifika ömrünün erken bölümünde otomatik deneyin.
DNS-01 kullanıyorsanız DNS API anahtarını yalnızca gerekli zone ve kayıt işlemiyle sınırlayın.
HTTP-01 challenge yolunun WAF, redirect ve reverse proxy kurallarıyla bozulmadığını test edin.
Staging CA ile rate-limit ve otomasyon testi yapın.
Başarılı yenilemeden sonra gerçek endpointte seri numarası ve bitiş tarihini doğrulayın.
Yenileme hatası için sertifika süresinden çok önce alarm üretin.

Sertifika dosyasının diskte yenilenmiş olması, çalışan proxy'nin yeni sertifikayı yüklediğini kanıtlamaz. Dış izleme doğrudan TLS handshake yaparak sunulan sertifikanın fingerprint, seri numarası ve notAfter değerini ölçmelidir.

HSTS nedir ve neden dikkatli açılmalı?

HTTP Strict Transport Security, RFC 6797 ile tanımlanan bir yanıt başlığıdır. Tarayıcı, daha sonra aynı hosta yapılacak HTTP isteklerini ağ üzerinden göndermeden HTTPS'e yükseltir. Böylece kullanıcı http:// bağlantısı açsa bile sslstrip benzeri ilk yönlendirme saldırılarına karşı koruma güçlenir.

CODE TERMINAL

Strict-Transport-Security: max-age=31536000; includeSubDomains

Nginx örneği:

CODE TERMINAL

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

HSTS başlığı yalnızca HTTPS yanıtında anlamlıdır. İlk dağıtımda kısa max-age ile başlayın, bütün alt alanların HTTPS uyumluluğunu test edin ve sonra süreyi kademeli artırın. includeSubDomains, unutulmuş geliştirme veya üçüncü taraf alt alanlarını da etkiler.

preload kalıcıya yakın bir operasyondur: alan adı tarayıcıların gömülü listesine girer ve geri alma işlemi sürüm döngüleri nedeniyle uzun sürebilir. Tüm alt alanlar kalıcı HTTPS'e hazır olmadan preload talep etmeyin. HSTS, süresi dolmuş sertifikayı düzeltmez; aksine kullanıcıya HTTP geri dönüşü bırakmadığı için sertifika yenileme disiplinini daha önemli hâle getirir.

OCSP Stapling ne sağlar?

OCSP, istemcinin sertifikanın iptal durumunu CA'dan sorgulamasına yardım eder. OCSP Stapling'de sunucu, CA'dan aldığı imzalı ve süreli yanıtı TLS handshake sırasında istemciye ekler. Bu, istemcinin CA'ya ayrı istek yapma ihtiyacını azaltabilir; gecikme ve gizlilik açısından yarar sağlar.

Nginx için tipik yapı:

CODE TERMINAL

ssl_stapling on;
ssl_stapling_verify on;

# Kurumun güvenilir recursive resolver adreslerini kullanın.
resolver 192.0.2.53 192.0.2.54 valid=300s;
resolver_timeout 5s;

Stapling'in çalışması için sunucunun doğru issuer zincirine ve OCSP responder'a ağ erişimine ihtiyacı vardır. Yanıtın thisUpdate/nextUpdate sürelerini izleyin. Her CA ve istemci aynı davranışı göstermediği için OCSP Stapling'i tek iptal kontrolü olarak görmeyin.

Must-Staple, sertifikanın TLS Feature uzantısıyla geçerli staple beklentisini ifade edebilir; ancak operasyonel hata durumunda sertifikanın tüm istemcilerde kullanılamamasına yol açabilir. Responder erişimi, cache yenileme ve failover ölçülmeden etkinleştirilmemelidir.

CODE TERMINAL

openssl s_client -connect example.com:443 -servername example.com -status

Çıktıda OCSP response durumu, üretim zamanı ve nextUpdate alanları kontrol edilmelidir.

mTLS ne zaman kullanılmalı?

Normal HTTPS'te istemci sunucuyu sertifikayla doğrular. Mutual TLS kullanımında sunucu da istemciden sertifika ister ve güvenilir bir client CA zinciriyle doğrular. Servisler arası iletişim, yönetim API'leri, B2B entegrasyonları ve cihaz kimliği için güçlü bir seçenek olabilir.

CODE TERMINAL

ssl_client_certificate /etc/nginx/pki/client-ca.pem;
ssl_verify_client on;
ssl_verify_depth 2;

mTLS tasarımında yalnızca “sertifika geçerli mi?” kontrolü yeterli değildir:

Hangi CA'nın hangi istemci grubuna sertifika verebildiğini sınırlandırın.
Subject veya SAN alanını uygulama kimliğine güvenli biçimde eşleyin.
Sertifika kimliği ile uygulama rol/yetkisini ayrı tutun.
Kısa ömür, otomatik yenileme ve iptal stratejisi belirleyin.
Proxy'nin doğruladığı kimliği backend'e yalnızca güvenilir iç header veya imzalı bağlamla aktarın.
İstemciden gelen aynı adlı header'ı proxy girişinde silin.
Private key'i cihaz veya workload üzerinde dışa aktarılamaz saklamayı değerlendirin.

Servis mesh kullanmak bu sorumlulukları ortadan kaldırmaz; yalnızca sertifika dağıtımı ve proxy entegrasyonunu otomatikleştirir. Trust domain, workload identity, CA rotasyonu ve yetkilendirme politikası hâlâ tasarlanmalıdır.

TLS 1.3 0-RTT neden replay riski taşır?

TLS 1.3, daha önce iletişim kurmuş istemcinin oturum bilgisiyle bazı uygulama verilerini handshake tamamlanmadan gönderebildiği 0-RTT modunu destekler. Gecikme azalır; fakat RFC 8446, early data'nın normal TLS kayıtlarıyla aynı replay garantisine sahip olmadığını açıkça belirtir.

Saldırgan geçerli bir 0-RTT isteğini yeniden oynatabilir. Bu nedenle aşağıdaki işlemler early data ile kabul edilmemelidir:

Para transferi ve ödeme onayı
Parola veya e-posta değiştirme
Sipariş oluşturma, rezervasyon ve tek kullanımlık kupon
Kullanıcı veya API anahtarı oluşturma
Dosya silme ve kalıcı durum değiştiren yönetim çağrıları

0-RTT yalnızca idempotent ve replay'e dayanıklı okumalar için, uygulama ve proxy birlikte tasarlandığında değerlendirilmelidir. En güvenli varsayılan, ihtiyaç ve ölçüm yoksa 0-RTT'yi kapalı tutmaktır.

SNI, ALPN ve sertifika seçimi

Bir IP üzerinde birden çok HTTPS sitesi barındırıldığında istemci ClientHello içindeki SNI ile hedef alan adını belirtir. Proxy doğru sanal hostu ve sertifikayı seçmelidir. Varsayılan vhost'un yanlış sertifikayı sunması bilgi sızıntısı, tarama kolaylığı ve istemci hatası oluşturabilir.

ALPN, HTTP/2 için h2 ve HTTP/1.1 gibi uygulama protokolünü müzakere eder. HTTP/3 QUIC üzerinde TLS 1.3 kullanır; TCP 443 yapılandırmasının güvenli olması UDP 443 yolunun otomatik olarak aynı proxy, sertifika ve WAF politikasından geçtiği anlamına gelmez.

Envanterde her endpoint için TCP/UDP listener, SNI adı, sertifika kaynağı, TLS termination noktası ve backend şifreleme durumu birlikte tutulmalıdır.

Reverse proxy arkasında uçtan uca TLS

CDN, load balancer veya WAF üzerinde TLS sonlandırıldığında istemci ile edge arasındaki kanal korunur; edge ile origin arasındaki trafik ayrıca değerlendirilmelidir.

Origin bağlantısında da TLS kullanın.
Origin sertifikasının hostname ve zincir doğrulamasını kapatmayın.
Mümkünse edge → origin mTLS veya özel trust anchor uygulayın.
Origin'i yalnızca edge ağından erişilebilir kılın.
X-Forwarded-Proto ve istemci IP header'larını yalnızca güvenilir proxy'den kabul edin.
HTTP redirect döngüsü ve yanlış secure-cookie kararını entegrasyon testine ekleyin.

“Full” veya “Flexible SSL” gibi ürün etiketleri sağlayıcıya göre farklı davranabilir. Origin doğrulamasının gerçekten hostname kontrolü yaptığını ve geçersiz sertifikada bağlantıyı kestiğini test edin.

Cookie ve uygulama katmanı ayarları

HTTPS etkin olsa bile oturum cookie'si doğru işaretlenmezse tarayıcı onu HTTP veya çapraz bağlamda gönderebilir.

CODE TERMINAL

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/

Secure: Cookie yalnızca güvenli bağlantıda gönderilir.
HttpOnly: JavaScript erişimini sınırlar; XSS'in tüm etkisini ortadan kaldırmaz.
SameSite: Cross-site istek davranışını sınırlar; uygulama akışına göre Lax veya Strict seçilir.
__Host- öneki: Secure, Path=/ ve Domain olmaması koşullarıyla hosta sıkı bağ sağlar.

Mixed content'i kaldırın; HTTPS sayfasından HTTP script, iframe veya form hedefi çağırmayın. Content Security Policy içindeki upgrade-insecure-requests geçişte yardımcı olabilir fakat kaynak URL'lerini düzeltmenin yerine geçmez.

Doğrulama ve dış test

Üretime geçmeden önce farklı katmanlardan test yapın:

CODE TERMINAL

# TLS 1.3 handshake
openssl s_client -connect example.com:443 -servername example.com -tls1_3

OpenSSL çıktısında protocol, cipher, certificate chain, verify return code, ALPN ve OCSP alanlarını inceleyin. Testi yalnızca proxy'nin iç IP'sinde değil, kullanıcıların eriştiği gerçek alan adı ve CDN/WAF yolu üzerinden çalıştırın.

Farklı SNI adları, IPv4/IPv6 adresleri, HTTP/2 ve HTTP/3 yolları ayrı sertifika veya edge düğümüne gidebilir. DNS load balancing kullanan yapılarda her IP'yi örnekleyin.

İzleme ve alarm üretimi

Sertifika bitiş tarihini 30, 14 ve 7 gün gibi kademeli eşiklerle izleyin.
Sunulan sertifikanın fingerprint veya seri numarası beklenmedik değiştiğinde alarm üretin.
Zincir, hostname ve trust doğrulamasını dışarıdan yapın.
TLS sürümü ve zayıf cipher kabulünü düzenli tarayın.
OCSP staple yaşını ve nextUpdate değerini izleyin.
ACME yenileme işinin sonucu ile gerçek endpoint sertifikasını karşılaştırın.
Handshake hata oranı, unknown CA, bad certificate ve protocol version hatalarını ölçün.
mTLS client sertifika süresi, issuer ve kimlik eşleme hatalarını ayrı loglayın.

Private key, session ticket anahtarı, tam client sertifika kimliği veya hassas DN alanlarını merkezi loglara gereksiz yere taşımayın. Olay korelasyonu için minimum kimlik ve geri döndürülemez özet kullanın.

Sık yapılan TLS hataları

TLS 1.3 açık olduğu için TLS 1.0/1.1'in de otomatik kapandığını sanmak
TLS 1.3 cipher ayarını TLS 1.2 ssl_ciphers listesiyle yönetmeye çalışmak
Intermediate sertifikayı sunmamak veya yanlış zincir sırası kullanmak
HSTS includeSubDomains/preload'u envanter çıkarmadan açmak
Sertifika yenilenmiş olsa da proxy reload edilmediği için eski sertifikayı sunmak
OCSP Stapling'i etkinleştirip responder erişimi ve yanıt tazeliğini izlememek
0-RTT ile durum değiştiren istekleri kabul etmek
mTLS sertifikasını uygulama yetkisiyle eş anlamlı saymak
Reverse proxy ile origin arasındaki sertifika doğrulamasını kapatmak
IPv6 ve HTTP/3 endpointlerini TLS taramasının dışında bırakmak
Private key'i repository, image, yedek veya CI loguna sızdırmak

Üretim kontrol listesi

TLS 1.3'ü etkinleştirin; gerekiyorsa TLS 1.2'yi güçlü ve ölçülmüş uyumluluk için tutun.
TLS 1.0/1.1, SSL ve eski cipher/key-exchange seçeneklerini kapatın.
SAN, hostname, full chain, süre ve private key eşleşmesini doğrulayın.
Private key'i en az yetkiyle veya yönetilen HSM/KMS üzerinde saklayın.
ACME yenileme, dağıtım, reload ve dış doğrulamayı otomatikleştirin.
HSTS'i kısa süreden başlayarak kademeli açın; alt alanlar hazır olmadan preload kullanmayın.
OCSP Stapling kullanıyorsanız issuer zinciri, responder erişimi ve yanıt tazeliğini izleyin.
mTLS kimliğini uygulama yetkisinden ayırın; CA ve header güven sınırını tasarlayın.
Durum değiştiren isteklerde 0-RTT'yi kabul etmeyin.
CDN/WAF ile origin arasında hostname doğrulamalı TLS ve mümkünse mTLS kullanın.
IPv4, IPv6, HTTP/2 ve HTTP/3 yollarını gerçek alan adı üzerinden test edin.
Sertifika süresi, zincir, protokol, cipher ve handshake hataları için dış izleme kurun.

Sonuç

Güvenli HTTPS, yalnızca TLS 1.3 seçmekten daha geniş bir yaşam döngüsüdür. Protokol politikası, doğru sertifika zinciri, korunmuş private key, otomatik yenileme, dikkatli HSTS, izlenen OCSP Stapling ve doğru tasarlanmış mTLS birlikte çalışmalıdır.

TLS 1.3 eski kriptografik seçenekleri azaltır ve ileri gizliliği güçlendirir; ancak 0-RTT replay, yanlış origin doğrulaması, sertifika yenileme hatası ve aşırı geniş trust gibi operasyonel riskler uygulama mimarisinde çözülmelidir. En iyi sonuç, güvenli varsayımları düzenli dış test ve ölçülebilir alarm kurallarıyla birleştirmektir.

Kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön