TLS Handshake mit NetMon

Am Anfang einer Verbindung steht das "Aushandeln" der Verschlüsselung. Dieser Handshake ist natürlich erst einmal unverschlüsselt. So können Sie mit Wireshark oder NetMon 3 natürlich dem Protokoll etwas auf die Finger schauen. Der Handshake ist immer gleich:

  • Angebot des Clients
  • Angebot des Server
  • Handshake

Umfangreicher wird der Handshake, wenn zuerst eine einleitende TCP-Verbindung aufgebaut wird die dann mit STARTLS  (z.B. bei SMTP) erst auf die Verschlüsselung wechselt oder wenn im Rahmen der Verschlüsselung auch eine Identifizierung des Clients durch Zertifikate erfolgt. Auf diese Varianten möchte ich nicht weiter eingehen.

Auch der Seite "The Illustrated TLS Connection" https://tls.ulfheim.net/, gibt es eine sehr gut gemachte Beschreibung.

Übersicht

Die die ersten Pakete einer HTTPS-Verbindung.

  • Rot: 3 Pakete TCP-Verbindungsaufbau
    Drei Pakete sind erforderlich, um die TCP-Verbindung zu starten "S=Syn",  AS=SyncAck, "A=Ack", damit beide Partner entsprechende Sequenznummern haben, die für die Flusskontrolle erforderlich sind.
  • Grün: 3 Pakete für den SSL-Hello
    Der Client sendet seine Möglichkeiten, auf die der Server antwortet. Da die Daten des Servers nicht in ein Paket passen, kommt gleich ein zweites dazu.
  • 1 Paket ACK
    Der Client braucht wohl etwas länger, so dass er die empfangenen Pakete quittiert. Sonst würde der Server von einem Paketverlust ausgehen und die Pakete noch einmal senden.
  • Blau: Nun sendet der Client seinen Key und die Cipher Auswahl, die der Server bestätigt.
  • 1..n  sind dann die verschlüsselten Daten, die NetMon nur als "SSL Application Data" meldet.

Schauen wir und ein paar Pakete etwas im Detail an. Zur Vereinfachung habe ich den Ethernet(WiFi-Header und auch den TCP-Rahmen entfernt und zeige nur die Payload.

Client Hello

Zuerst der "Client Hello", bei der der Client die möglichen Cipher Suites anbietet: Hier ein Handshake eines Servers, der gemäß TLSSecurity gesichert wurde.

Am Ende sehen Sie die optionalen "Extensions". Hier ist auch das SNI-Feld zu sehen, in dem schon hier der Hostname mitgesendet wird. So kann ein Webserver das "richtige" Zertifikat anbieten, selbst wenn mehrere Webseiten auf der gleichen IP/Port-Kombination lauschen. (Siehe auch SNI-Zertifikate)

Server Hello

Der Server antwortet seinerseits mit einem Server Hello. Hier ist die TLSCipherSuite zu sehen, die der Server aus dem Angebot des Clients und seinen Möglichkeiten ausgewählt hat. Zudem sendet er sein Zertifikat und die Kette mit. In diesem Beispile ist es ein Zertifikat von AlphaSSL, welches von GlobalSign ausgestellt wurde.

Diese Daten passen nicht ein ein einziges Paket, daher sehen Sie in der Übersicht noch ein "Continuation"-Paket und dann die Empfangsquittung des Clients.

Hinweis: In dem ServerHello kann man gut sehen, ob der Server nur sein Zertifikat oder auch die Intermediate-Zertifikate mit sended. Nur das Stammzertifikat wird natürlich nicht mit übertragen. Das muss auf dem Client schon vorliegen.

Client Key Exchange

Dann setzt der Client die Kommunikation mit der Übermittlung des Client Schlüssels fort. Der Schlüssel ist nur dem Client bekannt und wird schon mit dem PublicKey des Serverzertifikats verschlüsselt, so dass nur der Server diesen Wert wieder entschlüsseln kann.

Server Key Bestätigung

Und auch diese Handshake-Meldung wird von Server entsprechend bestätigt:

SSL-Daten

Nachdem mit dem Server-Zertifikat die Identität des Servers sichergestellt und der Sessionkey sicher an den Server gesendet wurde, kann die Nutzdatenübertragung erfolgen:

Viel mehr als die "verschlüsselten" Daten können Sie hier aber nicht mehr sehen.

Fehler: SSL 1.0 trifft TLS 1.2

Im Zuge der "Sicherung" von Servern deaktivieren immer mehr Administratoren veraltete Cipher-Verfahren und Protokolle. So wird SSL 1.0, SSL2.0 und SSL 3.0, was wohl TLS 1.0 ist, als unsicher oder nicht leistungsfähig genug angesehen und gerne deaktiviert. Wenn dann aber ein alter Client kommt, der z.B.: kein TLS 1.1 oder TLS 1.2 unterstützt, dann kann die Verbind nicht zustande kommen. Das ist im Netmon/Wireshark auch gut zu sehen

Wenn Sie solche Verbindungsprobleme nachverfolgen, dann sollten Sie auch immer den richtigen Client verwenden. So unterstützt Windows 2008R2 schon TLS 1.2 aber das bedeutet nicht, dass auch alle Programm auf dem Server automatisch mit TLS 1.2 arbeiten. Exchange 2010 ist so ein Negativ-Beispiel.

Auch hier ist Wireshark sehr hilfreich, da man per Capture-Filter sich genau auf die entsprechenden Pakete beschränken kann:

# Dieser Filter zeichnet nur die initiale Anfragen der Clients auf.
ssl.handshake.type == 1

Alternativ kann man auf dem Windows Server das CAPI2-Debugging einschalten und im Eventlog die "Fails" suchen.

Fehler: MTLS Client Cert nicht trusted

Hier sehen Sie einen Verbindungsaufbau eines Lync Edge Servers mit einem anderen Server. Der Host mit der 192.168.66.22 wird durch die Firewall nach extern natürlich auf eine öffentliche IP umgesetzt. Dieser Edge steht also hinter einer NAT-Veröffentlichung. Die Verbindung startet normal, aber der Server trennt diese dann mit einem RSET.

Die Pakete sind einfach zu versehen:

  1. Der Client startet die TCP Verbindung mit einem SYN
  2. Der Server antwortet mit einen SYN ACK, d.h. Namensauflösung, IP-Routing sind OK und der Server nimmt die Verbindung an
  3. Der Client bestätigt das SYN des Servers. Die Verbindung steht
  4. Der Client startet mit einem SSL-Hello
  5. Erste Teilantwort des Servers
  6. Zweite Teilantwort des Servers
  7. Dritte Teilantwort des Servers
  8. Zwischenquittung meines Clients
  9. Der Server-Hello ist komplett
  10. Per ACK wird der Empfang vom Client bestätigt.
  11. Hier sieht man, wie der Client das angeforderte Client-Zertifikat (MTLS) sendet. Dieses Paket kann man auch im Detail anschauen

    Sie sehen hier das eigentliche Zertifikat, die Intermediate CA und auch das Stammzertifikat. Der Client sendet also ebenfalls die "Chain" mit.
  12. Der Server bestätigt das Paket auf TCP-Level, um einen Retransmit zu verhindern.
  13. Der Server sendet noch eine Meldung zurück
  14. RST durch den Server.
    Anscheinend ist das Zertifikat nicht gültig.

Leider sieht man hier nicht, warum das Zertifikat ungültig ist. Wir haben keinen direkten Hinweis auf den Fehler der Überprüfung. Hier muss man auf dem Server nachschauen oder die üblichen Verdächtigen einmal überprüfen wie:

  • CN/SAN gültig
  • Vertraut der Server der RootCA?.
    Das könnte man aber auch aus den Paketen 5-9 ermitteln, wo der Server seine StammCAs mit sendet.
  • Datum
    Zertifikate sind nur ein einem Zeitraum gültig und wenn der Server keine aktuelles Datum hat, dann kann das gerade in Testumgebungen schon mal fehlschlagen.

MTLS mit gültigem Zertifikat

Wenn ein Client auf einen Service trifft, der TLS anbietet aber seinerseits auch eine Anmeldung durch den Client mit einem Zertifikat anfordert, dann sieht ein erfolgreicher Verbindungsaufbau so aus:

Nach dem "Server Hello Done" kommt dann die Rückantwort des Clients mit seinem Client Zertifikat:

MTLS ohne Zertifikat

Wenn der Client aber kein passendes Zertifikat vorweisen kann, welches von einer vertrauenswürdigen StammCA ausgestellt wurde, dann kann der Client die Verbindung nur abbauen

Nach dem "Server Hello Done" scheint der Client ca. 34ms zu brauchen, um kein Zertifikat zu finden und mit einem "FIN, ACK" die Verbindung zu beenden.

Weitere Links