Sdílení klíče v TLS versus klientský certifikát: co z toho přihlašuje?

Nesení veřejné hodnoty výměny klíčů v handshake není stejná událost jako přihlášení klienta. Jedno vytváří kryptografický stav spojení; druhé říká, kdo je klient, a nastane jen tehdy, když o to server požádá a výměna to podporuje. Když první považujete za druhé, dojdete ke špatným závěrům o tom, co VPN skrývá a co ne. Přečtěte si zprávy a pak rozhodněte, kterou ze čtyř vlastností jste skutečně pozorovali.

Dva objekty, které v zachyceném provozu vypadají stejně

Klient TLS 1.3 může ve svém prvním letu přispět materiálem pro výměnu klíčů, aniž by předložil jakýkoli certifikát. Tento příspěvek je záměrně veřejný, protože jej server potřebuje k odvození sdíleného tajemství. Klientský certifikát je jiná zpráva a odesílá se až poté, co o něj server požádá. Nese identitu, kterou server následně ověří, a vzájemná autentizace je rozhodnutí serveru, ne vlastnost, kterou by implikoval šifrový soubor. Identita aplikace je úplně třetí věc: přihlašovací formulář, bearer token, cookie. Nic z toho se v handshake neobjevuje a všechno to přežije změnu síťové cesty.

Čtyři řádky jsou nezávislé. Spojení může mít první a druhý řádek, třetí přeskočit a přesto nést čtvrtý v hlavičce cookie.

Rozhodněte, co může zachycený handshake prokázat

Jen z handshake se pozorovatel dozví vyjednanou verzi, šifrový soubor, certifikát serveru a veřejné hodnoty výměny klíčů. To stačí k otisku implementace klienta a k tomu, aby viděl, který server byl kontaktován. Co nedává, je soukromý stav potřebný k dešifrování spojení, jehož tajnost stojí na efemérní výměně, nikoli na veřejném podílu. Nedává ani identitu účtu, která v handshake od začátku nebyla.

Poctivý závěr je tedy úzký: v této výměně nebyl předložen žádný klientský certifikát. Nejde o to, že klient neposlal nic propojitelného, a rozhodně ne o to, že relace nenesla žádný identifikátor.

Čtěte zprávy, ne název šifry

Ptejte se serveru, co požaduje, místo abyste usuzovali ze šifrového souboru. Handshake TLS 1.3, který obsahuje žádost o certifikát, je v přepisu vidět, a jeho nepřítomnost je stejně viditelná.

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

Poté to zopakujte s nakonfigurovaným klientským certifikátem a porovnejte. Druhý běh by měl ukázat, že certifikát je odeslán a přijat; první by neměl ukázat žádný, a to je konkrétní rozdíl, o který jde.

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

Pokud potřebujete jen běžný případ prohlížení, podrobný výstup klienta stačí k tomu, abyste viděli verzi protokolu, výsledek ověření a zda byl nabídnut klientský certifikát. Server, který nikdy nepošle žádost o certifikát, žádný nemohl přijmout.

Kde obnovení mění odpověď

Obnovení v TLS 1.3 používá lístky spojené s tajným stavem, takže pozdější spojení může skončit bez plné výměny certifikátů. To snižuje, co pozorovatel vidí, a mění, co přepis prokazuje. Nevytváří identitu tam, kde žádná nebyla. Obnovená relace stále patří ke stejné relaci aplikace a jakákoli cookie nebo token v ní zůstává identifikátorem, na kterém záleží.

Proto kontrola soukromí, která se zastaví u "žádný klientský certifikát", míjí to zajímavé. Otázka zní, která strana drží stabilní identifikátor, ne která zpráva v jednom handshake chyběla.

Zapište čtyři vlastnosti, ne jeden verdikt

Zapište dohodu o klíči, ověření serveru, autentizaci klienta a identitu aplikace jako čtyři samostatné řádky s důkazem pro každý z nich. Tento soupis přežije změny verze protokolu a dělá argument o soukromí ověřitelným někým jiným. Pak přidejte, co přináší síťová cesta. VPN mění zdrojovou adresu, kterou služba vidí; neodstraňuje přihlášení, cookie ani otisk zařízení, které aplikace už má.

Zapište vyjednanou verzi spojení a výsledek žádosti o certifikát společně, protože právě tuto dvojici recenzent potřebuje k reprodukci vašeho závěru bez vlastního zachycení.