HTTPS, TLS ve sertifikalar
TLS handshake ve oturum anahtarları
Kimlik kontrolü ile şifreleme anahtarı anlaşmasını ayır.
Kavramı anlayalım
TLS handshake desteklenen sürüm ve algoritmaları anlaşır, sunucu kimliğini doğrular ve şifreli trafik için anahtarlar türetir. Modern TLS’de sertifikadaki public key, bütün uygulama verisini doğrudan şifrelemek için kullanılan tek anahtar değildir. Geçici anahtar anlaşması ve simetrik trafik anahtarları farklı rollerdir.
TLS 1.3 eski seçenekleri sadeleştirir. Forward secrecy uygun geçici anahtar anlaşmasıyla geçmiş trafiğin uzun vadeli anahtar sızıntısına karşı korunmasına yardımcı olur; ele geçirilmiş endpoint’i sihirli biçimde korumaz. Session resumption bağlantı kurulumunu azaltabilir.
0-RTT erken veri bazı yeniden bağlantılarda latency azaltırken replay riski taşır. Ödeme ve state-changing işlemler için uygulama/proxy politikası gereklidir. “TLS 1.3 açık” tek başına bütün client, certificate ve cipher uyumunu kanıtlamaz. Güncel platform varsayılanları ve düzenli test, elle rastgele cipher listesi yazmaktan daha sürdürülebilirdir.
HTTPS performansı ve replay riskini birlikte düşünmek için.
Sertifikanın private key’inin her mesajı doğrudan şifrelediğini sanmak.
Aynı konu. Üç farklı derinlik.
ClientHello → ServerHello → authentication → traffic keysBasitleştirilmiş TLS akışı; sürüme göre ayrıntılar değişir.
Bu sayfa dış sunuculara istek göndermez. HTTP mesajları temsili, HTTP/1.1 biçiminde okunabilir gösterimlerdir; HTTP/2 ve HTTP/3 wire formatı değildir. example.test ayrılmış öğretim alan adıdır. Komut ve JavaScript örneklerini yalnız kendi test ortamında uygula; gerçek token veya cookie yayımlama.
Önce kendin dene.
0-RTT ile ödeme POST’unu kontrolsüz kabul etmek doğru mu?
Çözümü ve açıklamasını göster
Early data requires replay-aware policyHayır; replay etkisi ve tekrar işlem kontrolü tasarlanmalıdır.