Bağlantı Güvenliği: TLS 1.3, HSTS ve Sertifika Yönetimi

Gece yarısı trafik artar. Sunucu nefes alır. Bir kullanıcı sayfayı açar, ama tarayıcı bir an durur. “Güvenli değil” uyarısı geçmişte kalmış olmalıydı. El sıkışma sayısı, yönlendirme döngüsü, karışık içerik... Hepsi toplam gecikmeye eklenir. Sorun tek bir ayar değildir. Sorun, zincirin en zayıf halkasıdır. Bu yazı o halkaları bulup güçlendirmek için net bir yol haritası verir.

Hedef basit: daha hızlı ilk bayt, daha az risk, daha temiz sinyal. Araçlarımız: TLS 1.3, HSTS ve sağlam bir sertifika yönetimi. Kod çok değil; kararlar net. Hadi başlayalım.

Tehditleri Adlandıralım: Neyi Kime Karşı Koruyoruz?

Tehdit net olunca çözüm basitleşir. Ortada adam (MITM) saldırısı, sürüm düşürme (downgrade), çerez çalma ve yönlendirme zaafları var. Zayıf şifre kümeleri ve eksik stapling de tabloya eklenir. Bir de yanlış yapılandırma var: yanlış yönlendirme, kısmi HTTPS, kısa olmayan max-age, eksik zincir.

Temel ilkeler ve en iyi uygulamalar için OWASP Transport Layer Protection Cheat Sheet iyi bir başlangıçtır. Tehdit modelinizi buna göre yazın: hangi veriler taşınır, hangi istemciler gelir, hangi ağdan erişilir, hangi risk kabul edilir.

İpucu: Tehdit listesine “yanlış alarm” da ekleyin. Yanlış HSTS kuralı üretim trafiğini kesebilir.

Kontrol: Son 30 günde gördüğünüz tarayıcı güvenlik uyarılarını toplayın. Her uyarı için bir kök neden yazın.

TLS 1.3’e Geçişin Asıl Nedeni: Hız mı, Güvenlik mi?

Cevap: ikisi de. TLS 1.3 el sıkışması kısadır. Genelde tek tur (1-RTT) ile biter. Eski ve zayıf şifre kümeleri kalkar. PFS (Perfect Forward Secrecy) standart olur. Resmi tanım ve ayrıntı için RFC 8446 dokümanına bakın.

TLS 1.3 nasıl çalışır sorusuna sade bir anlatım isterseniz, TLS 1.3 nasıl çalışır? makalesi akıcıdır. Buradaki kazanım sadece hız değil; saldırı yüzeyi de küçülür. Sunucu tarafında gereksiz sürümler kapanır, sade bir şifre listesi kalır.

0-RTT konusu ayrı. İlk istekler daha hızlı gelir. Ama tekrar oynatma (replay) riski doğar. Bunu idempotent GET gibi güvenli işlemlerle sınırlayın. Ayrıntılı riskler ve önlemler için 0-RTT riskleri ve en iyi uygulamalar yazısını okuyun.

İpucu: TLS 1.3 açın; TLS 1.2’yi bir süre tutun. Eski istemciler için kontrollü geçiş yapın.

Kontrol: Trafikte TLS sürüm dağılımını ölçün. TLS 1.2 oranı %5’in altına indiğinde 1.2 için zayıf şifreleri kapatın.

Hızlı Durum Kontrolü: Alan Adınız İçin 7 Maddelik Mini-Checklist

  1. Tüm yönlendirmeler 301 ile HTTPS’e gider mi? www/non-www tutarlı mı?
  2. Sunucuda TLS 1.3 açık mı, 1.0–1.1 kapalı mı?
  3. HSTS var mı? max-age ≥ 31536000, includeSubDomains ve mümkünse preload var mı? Başvuru için HSTS preload listesi.
  4. Sertifika zinciri tam mı? Ara sertifika eksik mi?
  5. OCSP stapling açık mı? Yanıt güncel mi?
  6. DNS CAA kaydı var mı? Yetkili CA doğru mu?
  7. SSL Labs ve Security Headers notlarınız A/A+ mu?

İpucu: Her maddeyi CI/CD’de otomatik test olarak koşun.

Kontrol: Prod öncesi pipeline’da SSL Labs API ve header testi zorunlu adım olsun.

HSTS: Tarayıcıyla Yapılan Bağlayıcı Anlaşma

HSTS, tarayıcıya “bu alan adı sadece HTTPS ile açılır” der. Temel başlık: Strict-Transport-Security. Açıklama ve örnekler için Strict-Transport-Security başlığı sayfasına bakın.

Preload, daha sıkıdır. Kural, tarayıcı listesine girer. Şartlar nettir: HTTPS zorunlu, geçerli sertifika, includeSubDomains, en az bir yıl max-age, preload bayrağı. Başvuru adresi: hstspreload.org. Yanlış kural, alt alanları da kilitler. Geri dönüş uzun sürebilir.

Yaygın hata: önce HTTP ile HSTS yollamak, ya da kısa max-age kullanmak. Doğrusu: 301 ile HTTPS’e al, sonra HSTS ekle, sonra preload düşün.

İpucu: Preload’a girmeden önce 2–4 hafta staging’te includeSubDomains ile test edin.

Kontrol: Tarayıcı konsolunda “HSTS” loglarını kontrol edin. Yanlış alt alan var mı?

Sertifika Yönetimi 2026: Otomasyon, Görünürlük, Kısa Ömür

Elle yenileme bitti. ACME ile otomasyon standart oldu. İstemci seçenekleri için ACME ile otomasyon sayfasını inceleyin. Kısa ömürlü sertifikalar (ör. 90 gün) çalınsa bile risk penceresi küçülür.

Yenileme işi cron değil, bir süreçtir. Certbot ile otomatik yenileme en yaygın yoldur. Ama servis yeniden yükleme (reload) ve sağlık kontrolü (health check) de otomatik olmalı. Başarısız yenilemede alarm üretin.

Görünürlük için Certificate Transparency (CT) şart. Yeni bir sertifika sizin adınıza basıldı mı hemen görün. Detay için Certificate Transparency kaynağını okuyun. CT log izleme, oltalama (phishing) alanlarını da yakalar.

Politika tarafında rehberler var. Sunucu konfigleri için NIST SP 800-52r2 tavsiyeleri iş görür. Ayrıca PCI DSS gibi standartlar, TLS 1.2+ zorunluluğunu ve güçlü şifreleri ister.

mTLS ne zaman? Servis–servis trafiğinde, iç ağda yüksek güven istediğinizde. Kimlik karşılıklı olur. Dış uçtaki son kullanıcı için mTLS şart değildir.

DNS CAA kaydı ile hangi CA’ların size sertifika basabileceğini sınırlayın. OCSP stapling ile iptal bilgisini hızlı verin. Envanter tutun: hangi alan adı, hangi sertifika, hangi son tarih.

Mini vaka: Bir SaaS ekibi TLS 1.3’e geçti, HSTS açtı, ACME’ye bağladı. İlk bayt 110 ms’den 72 ms’ye düştü. SSL Labs notu B’den A+’a çıktı. Sorun biletleri %18 azaldı.

İpucu: Kısa ömürlü sertifika + otomatik yenileme + CT izleme üçlüsünü birlikte kurun.

Kontrol: Her gün CT’de adınız geçen yeni kayıt var mı? Slack uyarısı geliyor mu?

Uygulama Laboratuvarı: Nginx/Apache Örnekleri ve CDN Notları

Örnekler basit tutulmuştur. Üretimde kendi bağlamınıza göre uyarlayın.

Nginx: belgeler için NGINX’te TLS ayarları.

Apache: yönergeler için Apache’de SSL/TLS yönergeleri.

Şifre kümesi seçimi için pratik bir rehber: güvenli şifre kümesi örnekleri. HTTP/3, QUIC üstünde TLS 1.3 kullanır; not için HTTP/3 ve TLS 1.3 ilişkisine bakın. CDN kullanıyorsanız, kenar (edge) ve kaynak (origin) politikalarını ayrı yönetin. Kenar TLS 1.3 olsa da origin 1.2’de kalabilir; bu bir köprü olur.

İpucu: 0-RTT gerekiyorsa sadece GET ve idempotent endpoint’lerde açın. POST için kapalı kalsın.

Kontrol: OCSP stapling gerçekten çalışıyor mu? openssl s_client -connect site:443 -status ile kontrol edin.

Karar Matrisi: TLS 1.3, HSTS ve Sertifika Yönetimi Yan Yana

Amaç Daha hızlı ve güvenli el sıkışma Yalnızca HTTPS’e zorlama Geçerli, görünür, zamanında sertifikalar
Performans etkisi Pozitif (1-RTT), 0-RTT opsiyonel Nötr (yönlendirme sadeleşir) Nötr (otomasyon yükü azalır)
Güvenlik kazanımı PFS, modern şifre kümeleri HTTP açıklığını kapatır Sahte/bitişik sertifika riskini düşürür
Risk/yanlış yapılandırma 0-RTT replay riski Yanlış preload alt alanları kilitler Yenileme başarısızsa kesinti
KPI/metrik El sıkışma süresi, sürüm oranı HSTS etkin alan oranı Yenileme hatası, CT uyarısı
Zorunlu mu? Fiilen evet (modern web) Önerilir; preload bağlama bağlı Evet (süreklilik için)
Tipik kurulum süresi Saatler Saatler (preload haftalar) Gün (envanter+ACME)
Geri alma/roll-back Kolay (sürüm aç/kapa) Zor (preload listesi yavaş güncellenir) Kolay (eski sertifikaya dön)
İzleme/raporlama SSL Labs, loglar Security Headers skoru CT log, ACME olayları
En iyi uygulama notu 0-RTT sadece idempotent includeSubDomains üretimde testlenmiş olmalı Kısa ömür + otomasyon
İlgili standart/doküman RFC 8446 MDN HSTS NIST SP 800-52r2, ACME
Sık hata Eski şifreleri açık bırakmak HTTP’te HSTS göndermek Yenilemeyi test etmemek

Ölç, Sonra İyileştir: Dış Testler ve KPI’lar

Ne ölçerseniz onu iyileştirirsiniz. Önce dış göz. SSL Labs sunucu testi ile notunuzu alın. Zayıf şifre, eksik zincir, OCSP uyarıları çıkar. Ardından başlıkları ölçün: Security Headers analizi hızlı geri bildirim verir.

Dahili metrikleri de toplayın: el sıkışma süresi (p50/p90), sürüm oranı (1.3/1.2), hatadan toparlanma süresi (MTTR), sertifika yenileme hataları, CT uyarı sayısı.

İpucu: A notu hedefleyin. A+ için HSTS ve ek başlıkları da tam yapın.

Kontrol: Her dağıtımdan sonra otomatik SSL Labs taraması koşturun. Not düşerse dağıtımı geri alın.

Sektör Notu: Fintech’ten Oyun/Gambling’e

Yüksek riskli dikeylerde güven daha kırılgandır. Fintech, sağlık, oyun gibi alanlarda küçük bir uyarı bile dönüşümü düşürür. Düzenleyici beklentiler de serttir. Bu yüzden TLS 1.3, HSTS ve otomasyon üçlüsü marka güveni için çıtayı belirler.

Kullanıcı bakışında üçüncü taraf rehberler de rol oynar. Örneğin, platformlar çoğu zaman ödeme ve çekim süreçlerini, TLS ve başlık sinyalleri ile birlikte değerlendirir. Bu bağlamda casino para çekme yöntemleri gibi kaynaklar, kullanıcıya şeffaflık sağlar; siz de sitenizin güven sinyallerini görünür kıldığınızda, tercih edilme şansınız artar.

İpucu: Güven sayfasında TLS sürümü, HSTS durumu ve sertifika bilgisine yer verin.

Kontrol: Ödeme/çekim akışında karışık içerik var mı? Tüm alt alanlar HSTS altında mı?

Sık Hatalar ve Efsaneler

“HPKP kuralı kuraldır” efsanedir. HPKP artık önerilmez. HSTS + CT daha güvenli ve yönetimi daha kolaydır. Bir diğer hata: “TLS 1.2’yi hemen kapatayım.” Eski istemciler kırılabilir. Önce ölçün, sonra kademeli kapatın.

“Wildcard her derde deva” değildir. Bazen SAN (SubjectAltName) ile daha net kontrol kurarsınız. “0-RTT her yerde hız” da değil; sadece güvenli işlemlerde açın.

İpucu: Değişiklikleri önce canary trafik ile deneyin.

Kontrol: Her büyük değişim için geri dönüş planı (rollback) hazır mı?

SSS: Kısa ve Net Yanıtlar

TLS 1.3’e geçince TLS 1.2’yi tamamen kapatmalı mıyım?

Hemen değil. Trafik verisini ölçün. Eski istemci oranı düşükse kapatın. Zayıf şifreleri zaten kapalı tutun.

HSTS preload nedir, geri dönüşü var mı?

Alan adınız tarayıcıya gömülür. Yalnızca HTTPS’e açılır. Geri dönüş yavaştır; listeler tarayıcı sürümüyle güncellenir. Dikkatli planlayın.

0-RTT güvenli mi ve hangi istekler için açılmalı?

Replay riski vardır. Sadece idempotent GET gibi isteklerde açın. Duruma bağlı olarak kapalı tutmak daha güvenlidir.

Wildcard mı SAN sertifikası mı?

Wildcard hızlıdır ama geniş yetki verir. SAN daha hedeflidir. Envanter ve risk modeline göre seçin.

OCSP stapling neden önemlidir?

İptal bilgisini hızlı ve güvenilir verir. Tarayıcı beklemez, ilk bayt hızlanır.

Kapanış: 10 Dakikalık Eylem Planı ve Karar Ağacı

  1. TLS 1.3’ü açın; 1.0–1.1’i kapatın. 1.2’yi ölçerek tutun.
  2. HSTS başlığını ekleyin: 31536000 + includeSubDomains. Preload’ı sonra düşünün.
  3. OCSP stapling’i açın. Zinciri doğrulayın.
  4. DNS CAA kaydını ekleyin.
  5. ACME istemcisi kurun. Otomatik yenileme + reload ayarlayın.
  6. CT izleme alarmı kurun.
  7. SSL Labs ve Security Headers testlerini pipeline’a alın.
  8. 0-RTT gerekiyorsa sadece GET için açın.
  9. CDN–origin TLS politikalarını hizalayın.
  10. Bir hafta sonra metriklere bakın; karar ağacıyla sıkılaştırın.

Karar ağacı: Eski istemci oranı yüksekse → 1.2 açık, sıkı şifrelerle; oran düşükse → 1.2 kapat. HSTS test başarılıysa → preload düşün; değilse → önce alt alanları düzelt. Otomasyon hatası artıyorsa → yenileme akışını gözden geçir, rollback ekle.

Görsel Ekler

Yazar ve Güncelleme

Yazar: Mert Yalın, Sec/DevOps Mühendisi. 10+ yıldır büyük trafik sitelerinde TLS geçişleri, HSTS projeleri ve ACME otomasyonu yaptı. Finans ve oyun dikeylerinde üretim geçişleri yönetti.

İlk yayın: 2025-11-05 — Son güncelleme: 2026-08-17

Kaynakça

  • OWASP Transport Layer Protection Cheat Sheet
  • RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
  • Cloudflare: Introducing TLS 1.3
  • Akamai: Understanding 0-RTT in TLS 1.3
  • HSTS Preload List
  • MDN: Strict-Transport-Security
  • Let’s Encrypt: ACME Client Options
  • EFF: Certbot
  • Certificate Transparency
  • NIST SP 800-52r2
  • NGINX Docs: HTTPS Sunucuları
  • Apache Docs: mod_ssl
  • Cipherli.st
  • Qualys SSL Labs
  • Security Headers
  • QUIC Working Group