Wymiana klucza TLS a certyfikat klienta: co się loguje?

Przenoszenie publicznej wartości wymiany klucza w uścisku dłoni nie jest tym samym zdarzeniem co logowanie klienta. Jedno ustanawia stan kryptograficzny połączenia; drugie mówi, kim jest klient, i zdarza się tylko wtedy, gdy serwer o to poprosi, a wymiana to obsłuży. Branie pierwszego za drugie prowadzi do błędnych wniosków o tym, co VPN ukrywa, a czego nie. Przeczytaj komunikaty, a potem zdecyduj, którą z czterech właściwości faktycznie zaobserwowałeś.

Dwa obiekty, które w przechwyceniu wyglądają tak samo

Klient TLS 1.3 może wnieść materiał wymiany klucza w swoim pierwszym locie, nie przedstawiając żadnego certyfikatu. Ten wkład jest jawny z założenia, bo serwer potrzebuje go do wyprowadzenia wspólnego sekretu. Certyfikat klienta to inny komunikat i jest wysyłany dopiero po tym, jak serwer o niego poprosi. Niesie tożsamość, którą serwer następnie weryfikuje, a uwierzytelnienie wzajemne jest decyzją serwera, nie właściwością wynikającą z zestawu szyfrów. Tożsamość aplikacji to rzecz całkiem trzecia: formularz logowania, token bearer, plik cookie. Nic z tego nie pojawia się w uścisku dłoni, a wszystko to przetrwa zmianę ścieżki sieciowej.

Cztery wiersze są niezależne. Połączenie może mieć wiersz pierwszy i drugi, pominąć trzeci, a i tak nieść czwarty w nagłówku cookie.

Zdecyduj, co może udowodnić przechwycony uścisk dłoni

Z samego uścisku dłoni obserwator poznaje wynegocjowaną wersję, zestaw szyfrów, certyfikat serwera i publiczne wartości wymiany klucza. To wystarcza, by pobrać odcisk implementacji klienta i zobaczyć, z którym serwerem się połączono. Czego to nie daje, to stanu prywatnego potrzebnego do odszyfrowania połączenia, którego tajność opiera się na wymianie efemerycznej, a nie na części publicznej. Nie daje też tożsamości konta, której od początku nie było w uścisku dłoni.

Uczciwy wniosek jest więc wąski: w tej wymianie nie przedstawiono żadnego certyfikatu klienta. Nie chodzi o to, że klient nie wysłał niczego, co da się powiązać, i z pewnością nie o to, że sesja nie niosła żadnego identyfikatora.

Czytaj komunikaty, nie nazwę szyfru

Zapytaj serwer, o co prosi, zamiast wnioskować z zestawu szyfrów. Uścisk dłoni TLS 1.3 z żądaniem certyfikatu jest widoczny w zapisie, a jego brak jest równie widoczny.

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

Następnie powtórz ze skonfigurowanym certyfikatem klienta i porównaj. Drugie uruchomienie powinno pokazać, że certyfikat jest wysyłany i akceptowany; pierwsze nie powinno pokazać żadnego, i to jest konkretna różnica, o którą chodzi.

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

Jeśli potrzebujesz tylko zwykłego przypadku przeglądania, szczegółowe wyjście klienta wystarczy, by zobaczyć wersję protokołu, wynik weryfikacji i to, czy zaproponowano certyfikat klienta. Serwer, który nigdy nie wysyła żądania certyfikatu, nie mógł go otrzymać.

Gdzie wznowienie zmienia odpowiedź

Wznowienie w TLS 1.3 korzysta z biletów powiązanych z tajnym stanem, więc późniejsze połączenie może zakończyć się bez pełnej wymiany certyfikatów. To zmniejsza to, co widzi obserwator, i zmienia to, co dowodzi zapis. Nie tworzy tożsamości tam, gdzie jej nie było. Wznowiona sesja nadal należy do tej samej sesji aplikacji, a każdy plik cookie lub token w tej sesji pozostaje identyfikatorem, który ma znaczenie.

Dlatego przegląd prywatności, który zatrzymuje się na „brak certyfikatu klienta”, pomija ciekawą część. Pytanie brzmi, która strona ma stabilny identyfikator, a nie którego komunikatu zabrakło w jednym uścisku dłoni.

Zapisz cztery właściwości, nie jeden wyrok

Zapisz uzgodnienie klucza, weryfikację serwera, uwierzytelnienie klienta i tożsamość aplikacji jako cztery osobne wiersze, z dowodem dla każdego. Ten spis przetrwa zmiany wersji protokołu i czyni argument o prywatności sprawdzalnym przez kogoś innego. Następnie dodaj, co wnosi ścieżka sieciowa. VPN zmienia adres źródłowy, który widzi usługa; nie usuwa logowania, pliku cookie ani odcisku urządzenia, które aplikacja już ma.

Zapisz razem wynegocjowaną wersję połączenia i wynik żądania certyfikatu, bo właśnie tej pary potrzebuje recenzent, by odtworzyć twój wniosek bez własnego przechwycenia.