TLS-sleuteluitwisseling versus cliëntcertificaat: welke logt in?

Een openbare sleuteluitwisselingswaarde in een handshake meedragen is niet hetzelfde gebeuren als een cliënt die inlogt. Het ene legt cryptografische toestand voor de verbinding vast; het andere zegt wie de cliënt is, en dat gebeurt alleen wanneer de server erom vraagt en de uitwisseling het ondersteunt. Het eerste voor het tweede aanzien leidt tot verkeerde conclusies over wat een VPN verbergt en wat niet. Lees de berichten en beslis daarna welke van vier eigenschappen u werkelijk hebt waargenomen.

Twee objecten die in een opname op elkaar lijken

Een TLS 1.3-cliënt kan in zijn eerste vlucht sleuteluitwisselingsmateriaal aanleveren zonder enig certificaat te overleggen. Die bijdrage is ontwerpmatig openbaar, omdat de server hem nodig heeft om het gedeelde geheim af te leiden. Een cliëntcertificaat is een ander bericht en wordt pas verzonden nadat de server erom heeft gevraagd. Het draagt een identiteit die de server daarna verifieert, en wederzijdse authenticatie is een beslissing van de server, geen eigenschap die de ciphersuite impliceert. Applicatie-identiteit is iets heel anders: een inlogformulier, een bearer-token, een cookie. Niets daarvan verschijnt in de handshake, en alles ervan overleeft een wijziging van het netwerkpad.

De vier rijen zijn onafhankelijk. Een verbinding kan rij een en twee hebben, rij drie overslaan en toch rij vier in een cookie-header dragen.

Bepaal wat een opgenomen handshake kan bewijzen

Alleen uit de handshake leert een waarnemer de onderhandelde versie, de ciphersuite, het servercertificaat en de openbare sleuteluitwisselingswaarden. Dat is genoeg om een cliëntimplementatie te fingerprinten en om te zien welke server is benaderd. Wat het niet oplevert, is de privétoestand die nodig is om de verbinding te ontsleutelen; de geheimhouding daarvan berust op de efemere uitwisseling en niet op het openbare deel. Het levert ook geen accountidentiteit op, die vanaf het begin nooit in de handshake zat.

De eerlijke conclusie is dus smal: in deze uitwisseling is geen cliëntcertificaat overlegd. Het is niet zo dat de cliënt niets koppelbaars stuurde, en zeker niet dat de sessie geen enkele identificatie droeg.

Lees de berichten in plaats van de cipher-naam

Vraag de server wat hij aanvraagt, in plaats van uit de ciphersuite af te leiden. Een TLS 1.3-handshake met een certificaataanvraag is zichtbaar in het transcript, en het ontbreken ervan is even zichtbaar.

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

Herhaal daarna met een geconfigureerd cliëntcertificaat en vergelijk. De tweede run zou moeten laten zien dat het certificaat wordt verzonden en geaccepteerd; de eerste zou niets moeten laten zien, en dat is het concrete verschil waar het over gaat.

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

Hebt u alleen het gewone browserval nodig, dan volstaat de uitvoerige cliëntuitvoer om de protocolversie, het verificatieresultaat en of een cliëntcertificaat werd aangeboden te zien. Een server die nooit een certificaataanvraag stuurt, kan er geen hebben ontvangen.

Waar hervatten het antwoord verandert

Hervatten in TLS 1.3 gebruikt tickets die aan geheime toestand zijn gebonden, zodat een latere verbinding kan slagen zonder volledige certificaatuitwisseling. Dat vermindert wat een waarnemer ziet en verandert wat het transcript bewijst. Het schept geen identiteit waar er geen was. Een hervatte sessie hoort nog steeds bij dezelfde applicatiesessie, en elke cookie of token in die sessie blijft de identificatie die ertoe doet.

Daarom mist een privacybeoordeling die stopt bij "geen cliëntcertificaat" het interessante deel. De vraag is welke partij een stabiele identificatie heeft, niet welk bericht in één handshake ontbrak.

Noteer vier eigenschappen, niet één oordeel

Schrijf sleutelovereenkomst, serververificatie, cliëntauthenticatie en applicatie-identiteit als vier afzonderlijke regels op, met het bewijs voor elk. Dat overzicht overleeft wijzigingen van protocolversie, en het maakt een privacyargument door iemand anders na te gaan. Voeg dan toe wat het netwerkpad bijdraagt. Een VPN verandert het bronadres dat een dienst ziet; hij verwijdert geen login, cookie of apparaatvingerafdruk die de applicatie al heeft.

Noteer de onderhandelde versie van de verbinding en de uitkomst van de certificaataanvraag samen, want juist dat paar heeft een beoordelaar nodig om uw conclusie zonder eigen opname te reproduceren.