TLS razmjena ključa nasuprot klijentskom certifikatu: šta se prijavljuje?

Nošenje javne vrijednosti razmjene ključa u rukovanju nije isti događaj kao prijava klijenta. Jedno uspostavlja kriptografsko stanje za vezu; drugo kaže ko je klijent i događa se samo kada server to zatraži i razmjena 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 primijetili.

Dva objekta koja u snimku izgledaju isto

TLS 1.3 klijent može dati materijal za razmjenu ključa u svom prvom letu bez predstavljanja ikakvog certifikata. Taj je doprinos javan po dizajnu, jer ga server treba da bi izveo zajedničku tajnu. Klijentski certifikat je druga poruka, šalje se tek nakon što ga server zatraži. On nosi identitet koji server zatim provjerava, 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 promjenu 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, serverov certifikat i javne vrijednosti razmjene 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šifriranje veze; njegova tajnost počiva na efemernoj razmjeni, a ne na javnom dijelu. Ne daje ni identitet računa, kojeg od početka nije bilo u rukovanju.

Zato je iskren zaključak uzak: u ovoj razmjeni nije predstavljen nijedan klijentski certifikat. Nije riječ 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, umjesto da zaključujete iz paketa šifri. Rukovanje TLS 1.3 sa zahtjevom za certifikat 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 s konfiguriranim klijentskim certifikatom i uporedite. Drugi prolaz treba pokazati da se certifikat šalje i prihvata; prvi ne treba pokazati ništa, i to je konkretna razlika o kojoj je riječ.

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, detaljni izlaz klijenta dovoljan je da vidite verziju protokola, rezultat provjere i da li je klijentski certifikat ponuđen. Server koji nikad ne šalje zahtjev za certifikat nije ga mogao primiti.

Gdje nastavljanje mijenja odgovor

Nastavljanje TLS 1.3 koristi tikete povezane s tajnim stanjem, pa kasnija veza može završiti bez pune razmjene certifikata. To smanjuje ono što posmatrač vidi i mijenja ono što transkript dokazuje. Ono ne stvara identitet tamo gdje 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 certifikata" promašuje zanimljivi dio. 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, provjeru servera, autentifikaciju klijenta i identitet aplikacije kao četiri odvojena reda, s dokazom za svaki. Taj popis preživljava promjene verzije protokola i čini argument o privatnosti provjerljivim od strane nekog drugog. Zatim dodajte šta doprinosi mrežni put. VPN mijenja 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 zahtjeva za certifikat zajedno, jer taj par recenzentu treba da reprodukuje vaš zaključak bez vlastitog snimka.