TLS-nyckelutbyte kontra klientcertifikat: vilken loggar in?

Att bära ett offentligt nyckelutbytesvärde i en handskakning är inte samma händelse som att en klient loggar in. Det ena upprättar kryptografiskt tillstånd för anslutningen; det andra säger vem klienten är, och det sker bara när servern begär det och utbytet stöder det. Att behandla det första som det andra leder till felaktiga slutsatser om vad en VPN döljer och inte döljer. Läs meddelandena och avgör sedan vilken av fyra egenskaper du faktiskt observerade.

Två objekt som ser likadana ut i en inspelning

En TLS 1.3-klient kan bidra med nyckelutbytesmaterial i sin första flygning utan att visa upp något certifikat. Det bidraget är offentligt av design, eftersom servern behöver det för att härleda den delade hemligheten. Ett klientcertifikat är ett annat meddelande och skickas först efter att servern har begärt ett. Det bär en identitet som servern sedan verifierar, och ömsesidig autentisering är ett beslut som servern fattar, inte en egenskap som ciphersviten innebär. Applikationsidentitet är något helt tredje: ett inloggningsformulär, en bearer-token, en cookie. Inget av det visas i handskakningen, och allt överlever en ändring av nätverksvägen.

De fyra raderna är oberoende. En anslutning kan ha rad ett och två, hoppa över rad tre och ändå bära rad fyra i en cookie-rubrik.

Avgör vad en fångad handskakning kan bevisa

Bara från handskakningen lär sig en observatör den förhandlade versionen, ciphersviten, serverns certifikat och de offentliga nyckelutbytesvärdena. Det räcker för att ta ett fingeravtryck av en klientimplementation och för att se vilken server som kontaktades. Det den inte ger är det privata tillstånd som behövs för att dekryptera anslutningen; dess hemlighållande vilar på det efemära utbytet och inte på den offentliga delen. Den ger inte heller någon kontoidentitet, som aldrig fanns i handskakningen från början.

Så den ärliga slutsatsen är snäv: inget klientcertifikat presenterades i detta utbyte. Det är inte så att klienten inte skickade något som går att koppla, och absolut inte så att sessionen inte bar någon identifierare.

Läs meddelandena i stället för chiffrets namn

Fråga servern vad den begär, i stället för att sluta dig till det från ciphersviten. En TLS 1.3-handskakning med en certifikatbegäran syns i transkriptet, och dess frånvaro är lika synlig.

openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'

Upprepa sedan med ett konfigurerat klientcertifikat och jämför. Den andra körningen bör visa att certifikatet skickas och accepteras; den första bör inte visa något, och det är den konkreta skillnad saken gäller.

openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet

Om du bara behöver det vanliga webbläsarärendet räcker klientens utförliga utdata för att se protokollversionen, verifieringsresultatet och om ett klientcertifikat erbjöds. En server som aldrig skickar en certifikatbegäran kan inte ha tagit emot en.

Där återupptagning ändrar svaret

Återupptagning i TLS 1.3 använder biljetter knutna till hemligt tillstånd, så en senare anslutning kan slutföras utan ett fullt certifikatutbyte. Det minskar vad en observatör ser och ändrar vad transkriptet bevisar. Det skapar ingen identitet där ingen fanns. En återupptagen session tillhör fortfarande samma applikationssession, och varje cookie eller token i den sessionen förblir den identifierare som spelar roll.

Därför missar en integritetsgranskning som stannar vid "inget klientcertifikat" det intressanta. Frågan är vilken part som har en stabil identifierare, inte vilket meddelande som saknades i en handskakning.

Anteckna fyra egenskaper, inte en enda dom

Skriv ned nyckelavtal, serververifiering, klientautentisering och applikationsidentitet som fyra separata rader, med beviset för varje. Den förteckningen överlever ändringar av protokollversion, och den gör ett integritetsargument kontrollerbart av någon annan. Lägg sedan till vad nätverksvägen bidrar med. En VPN ändrar källadressen som en tjänst ser; den tar inte bort en inloggning, en cookie eller ett enhetsfingeravtryck som applikationen redan har.

Anteckna anslutningens förhandlade version och resultatet av certifikatbegäran tillsammans, eftersom just det paret behöver en granskare för att återskapa din slutsats utan egen inspelning.