TLS-i võtmejagamine versus kliendisertifikaat: kumb sisse logib?
Eraldage võtme kokkuleppimine kliendi autentimisest ja rakenduse identiteedist ning lugege käepigistuse sõnumeid, mis näitavad, millist ühendus tegelikult kasutas.
Avaliku võtmevahetuse väärtuse kandmine käepigistuses ei ole sama sündmus kui kliendi sisselogimine. Üks loob ühenduse jaoks krüptograafilise oleku; teine ütleb, kes klient on, ja see juhtub ainult siis, kui server seda küsib ja vahetus seda toetab. Esimese pidamine teiseks viib valede järeldusteni sellest, mida VPN varjab ja mida mitte. Lugege sõnumeid ja otsustage seejärel, millist neljast omadusest te tegelikult vaatlesite.
Kaks objekti, mis jäädvustuses ühesugused paistavad
TLS 1.3 klient võib oma esimeses lennus anda võtmevahetuse materjali, esitamata ühtegi sertifikaati. See panus on kavatsuslikult avalik, sest server vajab seda ühise saladuse tuletamiseks. Kliendisertifikaat on teine sõnum ja saadetakse alles pärast seda, kui server seda küsib. See kannab identiteeti, mille server seejärel kontrollib, ja vastastikune autentimine on serveri otsus, mitte šifrikomplekti poolt eeldatav omadus. Rakenduse identiteet on hoopis kolmas asi: sisselogimisvorm, bearer-luba, küpsis. Ükski neist ei ilmu käepigistuses ja kõik need püsivad võrgutee muutumisel.
| 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 |
Neli rida on sõltumatud. Ühendusel võib olla esimene ja teine rida, kolmas vahele jääda ning neljas ikkagi küpsisepäises edasi kanduda.
Otsustage, mida jäädvustatud käepigistus tõestada saab
Ainuüksi käepigistusest õpib vaatleja kokkulepitud versiooni, šifrikomplekti, serveri sertifikaadi ja avalikud võtmevahetuse väärtused. Sellest piisab kliendi teostuse sõrmejälje võtmiseks ja selle nägemiseks, millise serveriga ühendust võeti. Mida see ei anna, on ühenduse dekrüpteerimiseks vajalik privaatne olek, mille salastatus põhineb efemeersel vahetusel, mitte avalikul osal. See ei anna ka konto identiteeti, mida käepigistuses algusest peale polnud.
Nii et aus järeldus on kitsas: selles vahetuses ei esitatud ühtegi kliendisertifikaati. Asi ei ole selles, et klient ei saatnud midagi seostatavat, ja kindlasti mitte selles, et sessioon ei kandnud ühtegi identifikaatorit.
Lugege sõnumeid, mitte šifri nime
Küsige serverilt, mida see nõuab, selle asemel et šifrikomplektist järeldada. Sertifikaaditaotlust sisaldav TLS 1.3 käepigistus on transkriptsioonis nähtav ja selle puudumine on sama nähtav.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'
Seejärel korrake kliendisertifikaadiga ja võrrelge. Teine käivitus peaks näitama, et sertifikaat saadetakse ja võetakse vastu; esimene ei peaks näitama ühtegi, ja see on konkreetne erinevus, millest jutt käib.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quiet
Kui vajate ainult tavalist sirvimisjuhtu, piisab kliendi üksikasjalikust väljundist, et näha protokolli versiooni, kontrollitulemust ja seda, kas kliendisertifikaati pakuti. Server, mis ei saada kunagi sertifikaaditaotlust, ei saa olla seda saanud.
Kus jätkamine vastust muudab
TLS 1.3 jätkamine kasutab salajase olekuga seotud pileteid, nii et hilisem ühendus saab lõpule jõuda ilma täieliku sertifikaadivahetuseta. See vähendab seda, mida vaatleja näeb, ja muudab seda, mida transkriptsioon tõestab. See ei loo identiteeti sinna, kus seda polnud. Jätkatud sessioon kuulub endiselt sama rakenduse sessiooni juurde ja mis tahes küpsis või luba selles sessioonis jääb identifikaatoriks, millel on tähtsust.
Seepärast jätab privaatsusülevaade, mis peatub "kliendisertifikaati pole", huvitava osa vahele. Küsimus on, millise osapoole käes on püsiv identifikaator, mitte see, milline sõnum ühest käepigistusest puudus.
Kirjutage üles neli omadust, mitte üks otsus
Kirjutage võtme kokkuleppimine, serveri kontroll, kliendi autentimine ja rakenduse identiteet nelja eraldi reana, igaühe tõendiga. See loend püsib protokolli versiooni muutumisel ja teeb privaatsusargumendi teistele kontrollitavaks. Seejärel lisage, mida annab võrgutee. VPN muudab algusaadressi, mida teenus näeb; see ei eemalda sisselogimist, küpsist ega seadme sõrmejälge, mis rakendusel juba on.
Kirjutage ühenduse kokkulepitud versioon ja sertifikaaditaotluse tulemus koos üles, sest just seda paari vajab retsensent, et teie järeldust ilma oma jäädvustuseta korrata.