TLS-Schlüsselaustausch gegenüber Clientzertifikat: Was meldet sich an?

Einen öffentlichen Schlüsselaustauschwert in einem Handshake zu übertragen ist nicht dasselbe Ereignis wie die Anmeldung eines Clients. Das eine stellt kryptografischen Zustand für die Verbindung her; das andere sagt, wer der Client ist, und es geschieht nur, wenn der Server es verlangt und der Austausch es unterstützt. Das erste für das zweite zu halten führt zu falschen Schlüssen darüber, was ein VPN verbirgt und was nicht. Lesen Sie die Nachrichten und entscheiden Sie dann, welche von vier Eigenschaften Sie tatsächlich beobachtet haben.

Zwei Objekte, die in einem Mitschnitt gleich aussehen

Ein TLS-1.3-Client kann in seinem ersten Flug Schlüsselaustauschmaterial beitragen, ohne ein Zertifikat vorzulegen. Dieser Beitrag ist konstruktionsbedingt öffentlich, weil der Server ihn braucht, um das gemeinsame Geheimnis abzuleiten. Ein Clientzertifikat ist eine andere Nachricht und wird erst gesendet, nachdem der Server eines angefordert hat. Es trägt eine Identität, die der Server anschließend prüft, und gegenseitige Authentifizierung ist eine Entscheidung des Servers, keine Eigenschaft, die die Cipher Suite impliziert. Anwendungsidentität ist etwas völlig Drittes: ein Anmeldeformular, ein Bearer-Token, ein Cookie. Nichts davon erscheint im Handshake, und alles davon übersteht einen Wechsel des Netzwerkpfads.

Die vier Zeilen sind unabhängig. Eine Verbindung kann Zeile eins und zwei haben, Zeile drei überspringen und Zeile vier trotzdem in einem Cookie-Header tragen.

Entscheiden Sie, was ein mitgeschnittener Handshake beweisen kann

Allein aus dem Handshake erfährt ein Beobachter die ausgehandelte Version, die Cipher Suite, das Serverzertifikat und die öffentlichen Schlüsselaustauschwerte. Das genügt, um eine Clientimplementierung zu fingerprinten und zu sehen, welcher Server kontaktiert wurde. Was es nicht liefert, ist der private Zustand, der zum Entschlüsseln der Verbindung nötig ist; dessen Geheimhaltung beruht auf dem ephemeren Austausch und nicht auf dem öffentlichen Anteil. Es liefert auch keine Kontoidentität, die von Anfang an nie im Handshake war.

Die ehrliche Schlussfolgerung ist also eng: In diesem Austausch wurde kein Clientzertifikat vorgelegt. Es ist nicht so, dass der Client nichts Verknüpfbares gesendet hätte, und gewiss nicht so, dass die Sitzung keine Kennung trug.

Lesen Sie die Nachrichten statt des Cipher-Namens

Fragen Sie den Server, was er anfordert, statt aus der Cipher Suite zu schließen. Ein TLS-1.3-Handshake mit einer Zertifikatsanforderung ist im Transkript sichtbar, und seine Abwesenheit ist ebenso sichtbar.

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

Wiederholen Sie es dann mit konfiguriertem Clientzertifikat und vergleichen Sie. Der zweite Lauf sollte zeigen, dass das Zertifikat gesendet und akzeptiert wird; der erste sollte keines zeigen, und genau das ist der konkrete Unterschied, um den es geht.

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

Wenn Sie nur den gewöhnlichen Browserfall brauchen, genügt die ausführliche Client-Ausgabe, um die Protokollversion, das Prüfergebnis und die Frage zu sehen, ob ein Clientzertifikat angeboten wurde. Ein Server, der nie eine Zertifikatsanforderung sendet, kann keine empfangen haben.

Wo Wiederaufnahme die Antwort ändert

Die Wiederaufnahme in TLS 1.3 verwendet Tickets, die an geheimen Zustand gebunden sind, sodass eine spätere Verbindung ohne vollständigen Zertifikatsaustausch abgeschlossen werden kann. Das verringert, was ein Beobachter sieht, und ändert, was das Transkript beweist. Es erzeugt keine Identität, wo keine war. Eine wiederaufgenommene Sitzung gehört weiterhin zur selben Anwendungssitzung, und jedes Cookie oder Token in dieser Sitzung bleibt die Kennung, auf die es ankommt.

Deshalb verpasst eine Datenschutzprüfung, die bei "kein Clientzertifikat" stehen bleibt, den interessanten Teil. Die Frage ist, welche Partei eine stabile Kennung hält, nicht welche Nachricht in einem Handshake fehlte.

Halten Sie vier Eigenschaften fest, nicht ein Urteil

Schreiben Sie Schlüsselvereinbarung, Serverprüfung, Client-Authentifizierung und Anwendungsidentität als vier getrennte Zeilen auf, jeweils mit dem Beleg. Dieses Inventar übersteht Wechsel der Protokollversion, und es macht ein Datenschutzargument für andere nachprüfbar. Fügen Sie dann hinzu, was der Netzwerkpfad beiträgt. Ein VPN ändert die Quelladresse, die ein Dienst sieht; es entfernt weder eine Anmeldung noch ein Cookie oder einen Gerätefingerabdruck, die die Anwendung bereits hat.

Halten Sie die ausgehandelte Version der Verbindung und das Ergebnis der Zertifikatsanforderung zusammen fest, denn genau dieses Paar braucht ein Prüfer, um Ihre Schlussfolgerung ohne eigenen Mitschnitt zu reproduzieren.