TLS razmena ključa nasuprot klijentskom sertifikatu: šta se prijavljuje?

Nošenje javne vrednosti razmene ključa u rukovanju nije isti događaj kao prijava klijenta. Jedno uspostavlja kriptografsko stanje za vezu; drugo kaže ko je klijent i dešava se samo kada server to zatraži i razmena to podrži. Ako prvo shvatite kao drugo, doći ćete do pogrešnih zaključaka o tome šta VPN skriva, a šta ne. Pročitajte poruke, pa odlučite koje ste od četiri osobine zaista primetili.

Dva objekta koja u snimku izgledaju isto

TLS 1.3 klijent može dati materijal za razmenu ključa u svom prvom letu bez predstavljanja ikakvog sertifikata. Taj je doprinos javan po dizajnu, jer ga server treba da bi izveo zajedničku tajnu. Klijentski sertifikat je druga poruka i šalje se tek nakon što ga server zatraži. On nosi identitet koji server zatim proverava, a uzajamna autentifikacija je odluka servera, a ne osobina koju nameće paket šifri. Identitet aplikacije je sasvim treća stvar: obrazac za prijavu, bearer token, kolačić. Ništa od toga se ne pojavljuje u rukovanju, i sve to preživljava promenu mrežnog puta.

Četiri reda su nezavisna. Veza može imati prvi i drugi red, preskočiti treći i ipak nositi četvrti u zaglavlju kolačića.

Odlučite šta snimljeno rukovanje može dokazati

Iz samog rukovanja posmatrač nauči pregovaranu verziju, paket šifri, serverski sertifikat i javne vrednosti razmene ključa. To je dovoljno da se uzme otisak klijentske implementacije i vidi kojem je serveru pristupljeno. Ono što ne daje jest privatno stanje potrebno za dešifrovanje veze; njegova tajnost počiva na efemernoj razmeni, a ne na javnom delu. Ne daje ni identitet naloga, kojeg od početka nije bilo u rukovanju.

Zato je iskren zaključak uzak: u ovoj razmeni nije predstavljen nijedan klijentski sertifikat. Nije reč o tome da klijent nije poslao ništa što se može povezati, i sigurno nije o tome da sesija nije nosila nikakav identifikator.

Čitajte poruke, a ne ime šifre

Pitajte server šta traži, umesto da zaključujete iz paketa šifri. Rukovanje TLS 1.3 sa zahtevom za sertifikat vidljivo je u transkriptu, a njegovo odsustvo jednako vidljivo.

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

Zatim ponovite sa konfigurisanim klijentskim sertifikatom i uporedite. Drugi prolaz treba da pokaže da se sertifikat šalje i prihvata; prvi ne treba da pokaže ništa, i to je konkretna razlika o kojoj je reč.

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

Ako vam treba samo uobičajen slučaj pregledanja, detaljan izlaz klijenta dovoljan je da vidite verziju protokola, rezultat provere i da li je klijentski sertifikat ponuđen. Server koji nikad ne šalje zahtev za sertifikat nije ga mogao primiti.

Gde nastavljanje menja odgovor

Nastavljanje TLS 1.3 koristi tikete povezane s tajnim stanjem, pa kasnija veza može završiti bez pune razmene sertifikata. To smanjuje ono što posmatrač vidi i menja ono što transkript dokazuje. Ono ne stvara identitet tamo gde ga nije bilo. Nastavljena sesija i dalje pripada istoj sesiji aplikacije, a svaki kolačić ili token u toj sesiji ostaje identifikator koji je važan.

Zato pregled privatnosti koji stane na "nema klijentskog sertifikata" promašuje zanimljivi deo. Pitanje je koja strana drži stabilan identifikator, a ne koja je poruka izostala iz jednog rukovanja.

Zapišite četiri osobine, a ne jednu presudu

Zapišite dogovor o ključu, proveru servera, autentifikaciju klijenta i identitet aplikacije kao četiri odvojena reda, s dokazom za svaki. Taj popis preživljava promene verzije protokola i čini argument o privatnosti proverljivim od strane nekog drugog. Zatim dodajte šta doprinosi mrežni put. VPN menja izvornu adresu koju usluga vidi; on ne uklanja prijavu, kolačić ili otisak uređaja koje aplikacija već ima.

Zapišite pregovaranu verziju veze i ishod zahteva za sertifikat zajedno, jer taj par recenzentu treba da reprodukuje vaš zaključak bez vlastitog snimka.