Výmena kľúča TLS verzus klientsky certifikát: čo sa prihlasuje?

Prenášanie verejnej hodnoty výmeny kľúčov v handshake nie je ten istý dej ako prihlásenie klienta. Jedno vytvára kryptografický stav spojenia; druhé hovorí, kto je klient, a nastane len vtedy, keď o to server požiada a výmena to podporuje. Ak prvé považujete za druhé, dôjdete k nesprávnym záverom o tom, čo VPN skrýva a čo nie. Prečítajte si správy a potom rozhodnite, ktorú zo štyroch vlastností ste skutočne pozorovali.

Dva objekty, ktoré v zázname vyzerajú rovnako

Klient TLS 1.3 môže vo svojom prvom lete prispieť materiálom na výmenu kľúčov bez toho, aby predložil akýkoľvek certifikát. Tento príspevok je zámerne verejný, pretože ho server potrebuje na odvodenie spoločného tajomstva. Klientsky certifikát je iná správa a odosiela sa až po tom, ako oň server požiada. Nesie identitu, ktorú server následne overí, a vzájomná autentifikácia je rozhodnutie servera, nie vlastnosť, ktorú by implikoval šifrový súbor. Identita aplikácie je úplne tretia vec: prihlasovací formulár, bearer token, cookie. Nič z toho sa v handshake neobjavuje a všetko to prežije zmenu sieťovej cesty.

Štyri riadky sú nezávislé. Spojenie môže mať prvý a druhý riadok, preskočiť tretí a napriek tomu niesť štvrtý v hlavičke cookie.

Rozhodnite, čo môže zachytený handshake dokázať

Len z handshake sa pozorovateľ dozvie vyjednanú verziu, šifrový súbor, certifikát servera a verejné hodnoty výmeny kľúčov. To stačí na odtlačok implementácie klienta a na to, aby videl, ktorý server bol kontaktovaný. Čo nedáva, je súkromný stav potrebný na dešifrovanie spojenia, ktorého tajnosť stojí na efemérnej výmene, nie na verejnom podiele. Nedáva ani identitu účtu, ktorá v handshake od začiatku nebola.

Poctivý záver je teda úzky: v tejto výmene nebol predložený žiadny klientsky certifikát. Nejde o to, že klient neposlal nič prepojiteľné, a rozhodne nie o to, že relácia nenesla žiadny identifikátor.

Čítajte správy, nie názov šifry

Pýtajte sa servera, čo požaduje, namiesto toho, aby ste usudzovali zo šifrového súboru. Handshake TLS 1.3, ktorý obsahuje žiadosť o certifikát, je v prepise viditeľný, a jeho neprítomnosť je rovnako viditeľná.

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

Potom to zopakujte s nakonfigurovaným klientskym certifikátom a porovnajte. Druhý beh by mal ukázať, že certifikát sa odosiela a prijíma; prvý by nemal ukázať žiadny, a to je konkrétny rozdiel, o ktorý ide.

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

Ak potrebujete len bežný prípad prehliadania, podrobný výstup klienta stačí na to, aby ste videli verziu protokolu, výsledok overenia a či bol ponúknutý klientsky certifikát. Server, ktorý nikdy nepošle žiadosť o certifikát, nemohol žiadny prijať.

Kde obnovenie mení odpoveď

Obnovenie v TLS 1.3 používa lístky spojené s tajným stavom, takže neskoršie spojenie sa môže dokončiť bez úplnej výmeny certifikátov. To znižuje, čo pozorovateľ vidí, a mení, čo prepis dokazuje. Nevytvára identitu tam, kde žiadna nebola. Obnovená relácia stále patrí tej istej relácii aplikácie a akýkoľvek cookie alebo token v nej zostáva identifikátorom, na ktorom záleží.

Preto kontrola súkromia, ktorá sa zastaví pri "žiadny klientsky certifikát", míňa to zaujímavé. Otázka je, ktorá strana drží stabilný identifikátor, nie ktorá správa v jednom handshake chýbala.

Zapíšte štyri vlastnosti, nie jeden verdikt

Zapíšte dohodu o kľúči, overenie servera, autentifikáciu klienta a identitu aplikácie ako štyri samostatné riadky s dôkazom pre každý z nich. Tento súpis prežije zmeny verzie protokolu a robí argument o súkromí overiteľným niekým iným. Potom pridajte, čo prináša sieťová cesta. VPN mení zdrojovú adresu, ktorú služba vidí; neodstraňuje prihlásenie, cookie ani odtlačok zariadenia, ktoré aplikácia už má.

Zapíšte vyjednanú verziu spojenia a výsledok žiadosti o certifikát spoločne, pretože práve túto dvojicu recenzent potrebuje na reprodukciu vášho záveru bez vlastného zachytenia.