Izmenjava ključa TLS proti odjemalskemu potrdilu: kaj se prijavi?
Ločite dogovor o ključu od preverjanja pristnosti odjemalca in identitete aplikacije ter preberite sporočila rokovanja, ki kažejo, kaj je povezava dejansko uporabila.
Prenašanje javne vrednosti izmenjave ključa v rokovanju ni isti dogodek kot prijava odjemalca. Eno vzpostavi kriptografsko stanje za povezavo; drugo pove, kdo je odjemalec, in se zgodi le, ko strežnik to zahteva in izmenjava to podpira. Če prvo štejete za drugo, pridete do napačnih sklepov o tem, kaj VPN skriva in česa ne. Preberite sporočila in se nato odločite, katero od štirih lastnosti ste dejansko opazili.
Dva objekta, ki v posnetku izgledata enako
Odjemalec TLS 1.3 lahko v svojem prvem poletu prispeva gradivo za izmenjavo ključa, ne da bi predložil kakršno koli potrdilo. Ta prispevek je po zasnovi javen, ker ga strežnik potrebuje za izpeljavo skupne skrivnosti. Odjemalsko potrdilo je drugo sporočilo in se pošlje šele potem, ko strežnik zanj zaprosi. Nosi identiteto, ki jo strežnik nato preveri, medsebojno preverjanje pristnosti pa je odločitev strežnika, ne lastnost, ki bi jo narekoval nabor šifer. Identiteta aplikacije je povsem tretja stvar: obrazec za prijavo, nosilni žeton, piškotek. Nič od tega se ne pojavi v rokovanju in vse to preživi spremembo omrežne poti.
| 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 |
Štiri vrstice so neodvisne. Povezava ima lahko prvo in drugo vrstico, tretjo preskoči in vseeno nosi četrto v glavi piškotka.
Odločite, kaj lahko posneto rokovanje dokaže
Samo iz rokovanja se opazovalec nauči dogovorjeno različico, nabor šifer, strežnikovo potrdilo in javne vrednosti izmenjave ključa. To zadostuje za odtis odjemalske izvedbe in za vpogled, kateri strežnik je bil kontaktiran. Česar pa ne da, je zasebno stanje, potrebno za dešifriranje povezave; njegova tajnost temelji na efemerni izmenjavi in ne na javnem deležu. Prav tako ne da identitete računa, ki je od začetka ni bilo v rokovanju.
Zato je pošten sklep ozek: v tej izmenjavi ni bilo predloženo nobeno odjemalsko potrdilo. Ne gre za to, da odjemalec ni poslal ničesar povezljivega, in zagotovo ne za to, da seja ni nosila nobenega identifikatorja.
Berite sporočila, ne imena šifre
Vprašajte strežnik, kaj zahteva, namesto da sklepate iz nabora šifer. Rokovanje TLS 1.3 z zahtevo za potrdilo je vidno v prepisu, njegova odsotnost pa je enako vidna.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Nato ponovite z nastavljenim odjemalskim potrdilom in primerjajte. Drugi zagon bi moral pokazati, da se potrdilo pošlje in sprejme; prvi ne bi smel pokazati nobenega, in to je konkretna razlika, za katero gre.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Če potrebujete le običajen primer brskanja, podroben izhod odjemalca zadostuje za pogled na različico protokola, izid preverjanja in ali je bilo ponujeno odjemalsko potrdilo. Strežnik, ki nikoli ne pošlje zahteve za potrdilo, ga ni mogel prejeti.
Kje nadaljevanje spremeni odgovor
Nadaljevanje v TLS 1.3 uporablja vozovnice, povezane s tajnim stanjem, zato se poznejša povezava lahko zaključi brez popolne izmenjave potrdil. To zmanjša, kar opazovalec vidi, in spremeni, kar prepis dokazuje. Ne ustvari identitete tam, kjer je ni bilo. Nadaljevana seja še vedno pripada isti seji aplikacije, in vsak piškotek ali žeton v tej seji ostane identifikator, ki je pomemben.
Zato pregled zasebnosti, ki se ustavi pri "ni odjemalskega potrdila", zgreši zanimivi del. Vprašanje je, katera stran ima stabilen identifikator, ne katero sporočilo je v enem rokovanju manjkalo.
Zapišite štiri lastnosti, ne eno sodbo
Zapišite dogovor o ključu, preverjanje strežnika, preverjanje pristnosti odjemalca in identiteto aplikacije kot štiri ločene vrstice, z dokazom za vsako. Ta seznam preživi spremembe različice protokola in naredi argument o zasebnosti preverljiv za nekoga drugega. Nato dodajte, kaj prispeva omrežna pot. VPN spremeni izvorni naslov, ki ga storitev vidi; ne odstrani prijave, piškotka ali prstnega odtisa naprave, ki jih aplikacija že ima.
Zapišite dogovorjeno različico povezave in izid zahteve za potrdilo skupaj, ker ravno ta par recenzent potrebuje za ponovitev vašega sklepa brez lastnega posnetka.