Schimb de chei TLS versus certificat de client: care se autentifică?

A transporta o valoare publică de schimb de chei într-un handshake nu este același eveniment cu autentificarea unui client. Una stabilește starea criptografică a conexiunii; cealaltă spune cine este clientul, și se întâmplă doar când serverul o cere și schimbul o susține. A trata primul drept al doilea duce la concluzii greșite despre ce ascunde un VPN și ce nu. Citiți mesajele și apoi decideți care dintre cele patru proprietăți ați observat-o cu adevărat.

Două obiecte care arată la fel într-o captură

Un client TLS 1.3 poate contribui cu material de schimb de chei în primul său zbor fără a prezenta vreun certificat. Această contribuție este publică prin proiectare, pentru că serverul are nevoie de ea pentru a deriva secretul comun. Certificatul de client este un alt mesaj și este trimis doar după ce serverul cere unul. El poartă o identitate pe care serverul o verifică apoi, iar autentificarea reciprocă este o decizie a serverului, nu o proprietate implicată de suita de cifrare. Identitatea aplicației este cu totul al treilea lucru: un formular de autentificare, un token bearer, un cookie. Nimic din toate acestea nu apare în handshake, și toate supraviețuiesc unei schimbări a căii de rețea.

Cele patru rânduri sunt independente. O conexiune poate avea rândul unu și doi, poate sări rândul trei și poate transporta totuși rândul patru într-un antet de cookie.

Decideți ce poate dovedi un handshake capturat

Doar din handshake, un observator află versiunea negociată, suita de cifrare, certificatul serverului și valorile publice de schimb de chei. Este suficient pentru a lua o amprentă a unei implementări de client și pentru a vedea ce server a fost contactat. Ce nu oferă este starea privată necesară pentru a decripta conexiunea, a cărei secretizare se sprijină pe schimbul efemer și nu pe partea publică. Nu oferă nici o identitate de cont, care nu a fost niciodată în handshake de la început.

Prin urmare concluzia onestă este îngustă: în acest schimb nu a fost prezentat niciun certificat de client. Nu este vorba că clientul nu a trimis nimic care să poată fi corelat, și cu siguranță nu că sesiunea nu purta niciun identificator.

Citiți mesajele, nu numele cifrului

Întrebați serverul ce solicită, în loc să deduceți din suita de cifrare. Un handshake TLS 1.3 care include o cerere de certificat este vizibil în transcriere, iar absența lui este la fel de vizibilă.

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

Apoi repetați cu un certificat de client configurat și comparați. A doua execuție ar trebui să arate certificatul trimis și acceptat; prima nu ar trebui să arate niciunul, și aceasta este diferența concretă despre care este vorba.

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

Dacă aveți nevoie doar de cazul obișnuit de navigare, ieșirea detaliată a clientului este suficientă pentru a vedea versiunea protocolului, rezultatul verificării și dacă a fost oferit un certificat de client. Un server care nu trimite niciodată o cerere de certificat nu a putut primi unul.

Unde reluarea schimbă răspunsul

Reluarea în TLS 1.3 folosește bilete asociate stării secrete, astfel încât o conexiune ulterioară se poate încheia fără un schimb complet de certificate. Aceasta reduce ce vede un observator și schimbă ce dovedește transcrierea. Nu creează o identitate unde nu exista. O sesiune reluată aparține în continuare aceleiași sesiuni a aplicației, iar orice cookie sau token din acea sesiune rămâne identificatorul care contează.

De aceea o analiză de confidențialitate care se oprește la "niciun certificat de client" ratează partea interesantă. Întrebarea este care parte deține un identificator stabil, nu care mesaj a lipsit dintr-un handshake.

Notați patru proprietăți, nu un verdict

Notați acordul asupra cheii, verificarea serverului, autentificarea clientului și identitatea aplicației ca patru rânduri separate, cu dovada pentru fiecare. Acest inventar supraviețuiește schimbărilor de versiune a protocolului și face un argument despre confidențialitate verificabil de altcineva. Apoi adăugați ce contribuie calea de rețea. Un VPN schimbă adresa sursă pe care o vede un serviciu; nu elimină o autentificare, un cookie sau o amprentă de dispozitiv pe care aplicația le are deja.

Notați împreună versiunea negociată a conexiunii și rezultatul cererii de certificat, pentru că exact acea pereche este necesară unui recenzent ca să reproducă concluzia dumneavoastră fără o captură proprie.