TLS-nøgleandel kontra klientcertifikat: hvilken en logger ind?

At bære en offentlig nøgleudvekslingsværdi i et håndtryk er ikke den samme begivenhed som en klient, der logger ind. Det ene etablerer kryptografisk tilstand for forbindelsen; det andet angiver, hvem klienten er, og det sker kun, når serveren beder om det, og udvekslingen understøtter det. Behandler man det første som det andet, fører det til forkerte konklusioner om, hvad en VPN skjuler, og hvad den ikke skjuler. Læs beskederne, og afgør derefter, hvilken af fire egenskaber du faktisk observerede.

To objekter, der ligner hinanden i en optagelse

En TLS 1.3-klient kan bidrage med nøgleudvekslingsmateriale i sin første flyvning uden at fremvise noget certifikat. Det bidrag er offentligt af design, fordi serveren har brug for det til at udlede den fælles hemmelighed. Et klientcertifikat er en anden besked og sendes først, når serveren anmoder om et. Det bærer en identitet, som serveren derefter verificerer, og gensidig godkendelse er en beslutning, serveren træffer, ikke en egenskab, som cipher suite indebærer. Applikationsidentitet er noget helt tredje: en loginformular, et bearer-token, en cookie. Ingen af dem optræder i håndtrykket, og alle overlever et skift af netværkssti.

De fire rækker er uafhængige. En forbindelse kan have række et og to, springe række tre over og stadig bære række fire i en cookie-header.

Afgør, hvad et optaget håndtryk kan bevise

Alene ud fra håndtrykket lærer en observatør den forhandlede version, cipher suite, serverens certifikat og de offentlige nøgleudvekslingsværdier. Det er nok til at tage et fingeraftryk af en klientimplementering og til at se, hvilken server der blev kontaktet. Det, den ikke giver, er den private tilstand, der er nødvendig for at dekryptere forbindelsen; dens hemmeligholdelse hviler på den efemere udveksling snarere end på den offentlige andel. Den giver heller ikke en kontoidentitet, som aldrig var i håndtrykket til at begynde med.

Så den ærlige konklusion er snæver: der blev ikke fremvist noget klientcertifikat i denne udveksling. Det er ikke, fordi klienten ikke sendte noget, der kan linkes, og det er bestemt ikke, fordi sessionen ikke bar nogen identifikator.

Læs beskederne i stedet for ciffernavnet

Spørg serveren, hvad den anmoder om, i stedet for at udlede det af cipher suite. Et TLS 1.3-håndtryk med en certifikatanmodning er synligt i transskriptet, og dets fravær er lige så synligt.

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

Gentag derefter med et konfigureret klientcertifikat, og sammenlign. Den anden kørsel bør vise, at certifikatet sendes og accepteres; den første bør ikke vise noget, og det er den konkrete forskel, som argumentet handler om.

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

Hvis du kun har brug for det almindelige browsingtilfælde, er klientens verbose output nok til at se protokolversionen, verifikationsresultatet og om der blev tilbudt et klientcertifikat. En server, der aldrig sender en certifikatanmodning, kan ikke have modtaget en.

Hvor genoptagelse ændrer svaret

TLS 1.3-genoptagelse bruger billetter knyttet til hemmelig tilstand, så en senere forbindelse kan fuldføres uden en fuld certifikatudveksling. Det reducerer, hvad en observatør ser, og ændrer, hvad transskriptet beviser. Det skaber ikke en identitet, hvor der ikke var nogen. En genoptaget session hører stadig til den samme applikationssession, og enhver cookie eller token i den session forbliver den identifikator, der betyder noget.

Det er derfor, en privatlivsgennemgang, der stopper ved "intet klientcertifikat", går glip af det interessante. Spørgsmålet er, hvilken part der har en stabil identifikator, ikke hvilken besked der manglede i et håndtryk.

Notér fire egenskaber, ikke én dom

Skriv nøgleaftale, serververifikation, klientgodkendelse og applikationsidentitet ned som fire separate linjer med dokumentationen for hver. Den fortegnelse overlever skift af protokolversion, og den gør et argument om privatliv efterprøvbart for en anden. Tilføj derefter, hvad netværksstien bidrager med. En VPN ændrer den kildeadresse, en tjeneste ser; den fjerner ikke et login, en cookie eller et enhedsfingeraftryk, som applikationen allerede har.

Notér forbindelsens forhandlede version og resultatet af certifikatanmodningen sammen, fordi netop det par er, hvad en bedømmer har brug for at genskabe din konklusion uden sin egen optagelse.