Razmjena ključa TLS nasuprot klijentskoj potvrdi: što se prijavljuje?

Nošenje javne vrijednosti razmjene ključeva u rukovanju nije isti događaj kao prijava klijenta. Jedno uspostavlja kriptografsko stanje za vezu; drugo kaže tko je klijent i događa se samo kada to poslužitelj zatraži i razmjena to podrži. Ako prvo shvatite kao drugo, doći ćete do pogrešnih zaključaka o tome što VPN skriva, a što ne. Pročitajte poruke, pa odlučite koje ste od četiri svojstva doista primijetili.

Dva objekta koja u snimci izgledaju isto

TLS 1.3 klijent može dati materijal za razmjenu ključeva u svom prvom letu bez predstavljanja ikakve potvrde. Taj je doprinos javan po dizajnu jer ga poslužitelj treba da bi izveo zajedničku tajnu. Klijentska potvrda je druga poruka i šalje se tek nakon što je poslužitelj zatraži. Ona nosi identitet koji poslužitelj zatim provjerava, a uzajamna autentifikacija odluka je poslužitelja, a ne svojstvo koje nameće skup šifri. Identitet aplikacije posve je treća stvar: obrazac za prijavu, bearer token, kolačić. Ništa od toga ne pojavljuje se u rukovanju, i sve to preživljava promjenu mrežnog puta.

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

Odlučite što snimljeno rukovanje može dokazati

Iz samog rukovanja promatrač nauči pregovaranu verziju, skup šifri, poslužiteljevu potvrdu i javne vrijednosti razmjene ključeva. To je dovoljno za otisak klijentske implementacije i za uvid u to kojem se poslužitelju pristupilo. Ono što ne daje jest privatno stanje potrebno za dešifriranje veze; njegova tajnovitost počiva na efemernoj razmjeni, a ne na javnom dijelu. Ne daje ni identitet računa, kojeg od početka nije bilo u rukovanju.

Stoga je iskren zaključak uzak: u ovoj razmjeni nije predstavljena nijedna klijentska potvrda. 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 poslužitelj što traži, umjesto da zaključujete iz skupa šifri. Rukovanje TLS 1.3 sa zahtjevom za potvrdu vidljivo je u transkriptu, a njegova odsutnost jednako vidljiva.

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

Zatim ponovite s konfiguriranom klijentskom potvrdom i usporedite. Drugi prolaz treba pokazati da se potvrda šalje i prihvaća; prvi ne treba pokazati nijednu, 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 pregledavanja, detaljan izlaz klijenta dovoljan je da vidite verziju protokola, rezultat provjere i je li klijentska potvrda ponuđena. Poslužitelj koji nikad ne šalje zahtjev za potvrdu nije ju mogao primiti.

Gdje nastavljanje mijenja odgovor

Nastavljanje u TLS 1.3 rabi tikete povezane s tajnim stanjem, pa kasnija veza može završiti bez pune razmjene potvrda. To smanjuje ono što promatrač 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 klijentske potvrde" promašuje zanimljivi dio. Pitanje je koja strana drži stabilan identifikator, a ne koja je poruka izostala iz jednog rukovanja.

Zapišite četiri svojstva, a ne jednu presudu

Zapišite dogovor o ključu, provjeru poslužitelja, autentifikaciju klijenta i identitet aplikacije kao četiri odvojena retka, s dokazom za svaki. Taj popis preživljava promjene verzije protokola i čini argument o privatnosti provjerljivim nekome drugome. Zatim dodajte što doprinosi mrežni put. VPN mijenja izvornu adresu koju usluga vidi; on ne uklanja prijavu, kolačić ni otisak uređaja koje aplikacija već ima.

Zapišite pregovaranu verziju veze i ishod zahtjeva za potvrdu zajedno, jer taj par recenzentu treba da bi reproducirao vaš zaključak bez vlastite snimke.