TLS anahtar paylaşımı ile istemci sertifikası: hangisi oturum açar?
Anahtar anlaşmasını istemci kimlik doğrulamasından ve uygulama kimliğinden ayırın, hangisinin gerçekten kullanıldığını gösteren el sıkışma mesajlarını okuyun.
Bir el sıkışmada ortak anahtar değişimi değeri taşımak, bir istemcinin oturum açmasıyla aynı olay değildir. Biri bağlantı için kriptografik durum kurar; diğeri istemcinin kim olduğunu söyler ve yalnızca sunucu istediğinde ve değişim bunu desteklediğinde gerçekleşir. Birinciyi ikinci sanmak, bir VPN'in neyi gizleyip neyi gizlemediği konusunda yanlış sonuçlara yol açar. Mesajları okuyun, sonra dört özellikten hangisini gerçekten gözlemlediğinize karar verin.
Bir kayıtta aynı görünen iki nesne
TLS 1.3 istemcisi, herhangi bir sertifika sunmadan ilk uçuşunda anahtar değişimi malzemesi katkısı verebilir. Bu katkı tasarım gereği açıktır, çünkü sunucunun ortak sırrı türetmek için ona ihtiyacı vardır. İstemci sertifikası başka bir mesajdır ve ancak sunucu bir tane istedikten sonra gönderilir. Sunucunun sonradan doğruladığı bir kimlik taşır ve karşılıklı kimlik doğrulama, şifre takımının ima ettiği bir özellik değil, sunucunun verdiği karardır. Uygulama kimliği tamamen üçüncü bir şeydir: bir oturum açma formu, bir bearer belirteci, bir çerez. Bunların hiçbiri el sıkışmada görünmez ve hepsi ağ yolunun değişmesine dayanır.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
Dört satır bağımsızdır. Bir bağlantı birinci ve ikinci satıra sahip olabilir, üçüncüyü atlayabilir ve yine de dördüncüyü bir çerez başlığında taşıyabilir.
Yakalanan bir el sıkışmanın neyi kanıtlayabileceğine karar verin
Yalnızca el sıkışmadan bir gözlemci anlaşılan sürümü, şifre takımını, sunucunun sertifikasını ve ortak anahtar değişimi değerlerini öğrenir. Bu, bir istemci uygulamasının parmak izini almak ve hangi sunucuya bağlanıldığını görmek için yeterlidir. Vermediği şey, bağlantının şifresini çözmek için gereken özel durumdur; bunun gizliliği ortak paya değil, kısa ömürlü değişime dayanır. Ayrıca, baştan beri el sıkışmada olmayan bir hesap kimliği de vermez.
Dolayısıyla dürüst sonuç dardır: bu değişimde hiçbir istemci sertifikası sunulmadı. İstemcinin bağlanabilir hiçbir şey göndermemesi söz konusu değildir ve kesinlikle oturumun hiçbir tanımlayıcı taşımaması da değildir.
Şifrenin adını değil, mesajları okuyun
Şifre takımından çıkarım yapmak yerine sunucuya ne istediğini sorun. Sertifika isteği içeren bir TLS 1.3 el sıkışması dökümde görünür ve yokluğu da aynı ölçüde görünür.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Sonra yapılandırılmış bir istemci sertifikasıyla yineleyin ve karşılaştırın. İkinci çalıştırma sertifikanın gönderildiğini ve kabul edildiğini göstermelidir; birincisi hiçbir şey göstermemelidir ve tartışmanın asıl somut farkı budur.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Yalnızca olağan tarama durumuna ihtiyacınız varsa, istemcinin ayrıntılı çıktısı protokol sürümünü, doğrulama sonucunu ve bir istemci sertifikası sunulup sunulmadığını görmek için yeterlidir. Hiçbir zaman sertifika isteği göndermeyen bir sunucu bir tane almış olamaz.
Devam ettirmenin yanıtı değiştirdiği yer
TLS 1.3'te devam ettirme, gizli duruma bağlı biletler kullanır, böylece sonraki bir bağlantı tam sertifika değişimi olmadan tamamlanabilir. Bu, gözlemcinin gördüğünü azaltır ve dökümün kanıtladığını değiştirir. Olmayan bir kimliği yaratmaz. Devam ettirilen oturum hâlâ aynı uygulama oturumuna aittir ve o oturumdaki herhangi bir çerez veya belirteç önemli tanımlayıcı olarak kalır.
Bu yüzden "istemci sertifikası yok" noktasında duran bir gizlilik incelemesi ilginç kısmı kaçırır. Sorulması gereken soru, hangi tarafın istikrarlı bir tanımlayıcı tuttuğudur; tek bir el sıkışmadan hangi mesajın eksik olduğu değil.
Tek bir hüküm değil, dört özellik kaydedin
Anahtar anlaşmasını, sunucu doğrulamasını, istemci kimlik doğrulamasını ve uygulama kimliğini her biri için kanıtla birlikte dört ayrı satır olarak yazın. Bu envanter protokol sürümü değişikliklerine dayanır ve gizlilikle ilgili bir argümanı başkası için denetlenebilir kılar. Sonra ağ yolunun ne kattığını ekleyin. Bir VPN, bir hizmetin gördüğü kaynak adresini değiştirir; uygulamanın zaten sahip olduğu oturum açmayı, çerezi veya cihaz parmak izini kaldırmaz.
Bağlantının anlaşılan sürümünü ve sertifika isteğinin sonucunu birlikte kaydedin, çünkü bir gözden geçirenin kendi kaydı olmadan sonucunuzu yeniden üretmesi için gereken çift tam olarak budur.