TLS-nøkkelutveksling mot klientcertifikat: hvilken logger inn?

Å bære en offentlig nøkkelutvekslingsverdi i et håndtrykk er ikke samme hendelse som en klient som logger inn. Det ene etablerer kryptografisk tilstand for tilkoblingen; det andre sier hvem klienten er, og det skjer bare når serveren ber om det og utvekslingen støtter det. Å behandle det første som det andre fører til gale konklusjoner om hva en VPN skjuler og ikke skjuler. Les meldingene, og avgjør deretter hvilken av fire egenskaper du faktisk observerte.

To objekter som ser like ut i en opptak

En TLS 1.3-klient kan bidra med nøkkelutvekslingsmateriale i sin første flyging uten å legge fram noe sertifikat. Det bidraget er offentlig av design, fordi serveren trenger det for å utlede den delte hemmeligheten. Et klientcertifikat er en annen melding og sendes bare etter at serveren har bedt om ett. Det bærer en identitet som serveren deretter verifiserer, og gjensidig autentisering er en beslutning serveren tar, ikke en egenskap ciphersuiten innebærer. Applikasjonsidentitet er noe helt tredje: et innloggingsskjema, et bearer-token, en cookie. Ingen av dem vises i håndtrykket, og alle overlever en endring av nettverksvei.

De fire radene er uavhengige. En tilkobling kan ha rad én og to, hoppe over rad tre og likevel bære rad fire i en cookie-header.

Avgjør hva et fanget håndtrykk kan bevise

Bare fra håndtrykket lærer en observatør den forhandlede versjonen, ciphersuiten, serverens sertifikat og de offentlige nøkkelutvekslingsverdiene. Det er nok til å ta et fingeravtrykk av en klientimplementasjon og til å se hvilken server som ble kontaktet. Det det ikke gir, er den private tilstanden som trengs for å dekryptere tilkoblingen; hemmeligholdet hviler på den efemere utvekslingen og ikke på den offentlige delen. Det gir heller ikke en kontoidentitet, som aldri var i håndtrykket til å begynne med.

Så den ærlige konklusjonen er smal: det ble ikke lagt fram noe klientcertifikat i denne utvekslingen. Det er ikke slik at klienten ikke sendte noe som kan kobles, og slett ikke at økten ikke bar noen identifikator.

Les meldingene i stedet for chiffre-navnet

Spør serveren hva den ber om, i stedet for å utlede det fra ciphersuiten. Et TLS 1.3-håndtrykk med en sertifikatforespørsel er synlig i transkriptet, og fraværet er like synlig.

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

Gjenta deretter med et konfigurert klientcertifikat, og sammenlign. Den andre kjøringen skal vise at sertifikatet sendes og godtas; den første skal ikke vise noe, og det er den konkrete forskjellen argumentet handler om.

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

Hvis du bare trenger den vanlige nettlesersaken, er klientens detaljerte utdata nok til å se protokollversjonen, verifiseringsresultatet og om det ble tilbudt et klientcertifikat. En server som aldri sender en sertifikatforespørsel, kan ikke ha mottatt en.

Der gjenopptakelse endrer svaret

Gjenopptakelse i TLS 1.3 bruker billetter knyttet til hemmelig tilstand, slik at en senere tilkobling kan fullføres uten full sertifikatutveksling. Det reduserer hva en observatør ser og endrer hva transkriptet beviser. Det skaper ikke en identitet der det ikke var noen. En gjenopptatt økt tilhører fortsatt samme applikasjonsøkt, og enhver cookie eller token i den økten forblir identifikatoren som betyr noe.

Derfor går en personvernvurdering som stopper ved "ingen klientcertifikat" glipp av den interessante delen. Spørsmålet er hvilken part som holder en stabil identifikator, ikke hvilken melding som manglet i ett håndtrykk.

Noter fire egenskaper, ikke én dom

Skriv nøkkelavtale, serververifisering, klientautentisering og applikasjonsidentitet som fire separate linjer, med belegget for hver. Den oversikten overlever endringer i protokollversjon, og den gjør et personvernargument etterprøvbart av andre. Legg deretter til hva nettverksveien bidrar med. En VPN endrer kildeadressen en tjeneste ser; den fjerner ikke en innlogging, en cookie eller et enhetsfingeravtrykk som applikasjonen allerede har.

Noter tilkoblingens forhandlede versjon og resultatet av sertifikatforespørselen sammen, fordi nettopp det paret trenger en vurderer for å gjenskape konklusjonen din uten eget opptak.