Die Transport Layer Security (Transportsicherheit, kurz TLS) ist der Nachfolger des Secure Sockets Layer (SSL). Es ist ein hybrides Verschlüsselungsprotokoll für eine sichere Kommunikation im Internet. Es wird hauptsächlich für die verschlüsselte Übertragung mit dem HTTPS Protokoll über Port 443 (anstelle der unverschlüsselten Übertragung über das HTTP Protokoll über Port 80) verwendet sowie für die E-Mail-Protokolle POP3, IMAP und SMTP:
- POP3S über Port 995 für POP3 (Port 110)
- IMAPS über Port 993 für IMAP (Port 143)
- SMTPS über Port 465 für SMTP (Port 25)
Geschichte
Die Versionen SSL 1.0 (1994), SSL 2.0 (1995) und SSL 3.0 (1996) sind seit Juni 2015 unzulässig. Für die Nachfolgeversionen TLS 1.0 (1999) und TLS 1.1 (2006) läuft die Unterstützung aus. TLS 1.2 (2008) wird noch unterstützt, TLS 1.3 (2018), definiert in RFC8446, ist die aktuelle Version.
Funktionsweise und Ablauf einer TLS-Verbindung: Übersicht
Der Client meldet dem Server den Verbindungswunsch und schickt eine Liste von Cipher Suites, die der Client kennt.
Der Server authentisiert sich gegenüber dem Client mit einem Zertifikat und einer Cipher Suite, die Server und Client kennen.
Der Client überprüft das Zertifikat und authentisiert sich ggf. selbst auch noch gegenüber dem Server mit einem eigenen Zertifikat.
Nun wird ein kryptografischer Schlüssel erstellt:
- Entweder schickt der Client dem Server eine verschlüsselte Zufallszahl, die mit dem öffentlichen Schlüssel des Servers verschlüsselt ist,
- oder beide Parteien berechnen ein gemeinsames Geheimnis mit dem Diffie-Hellman-Schlüsselaustauschverfahren.
Der erzeugte kryptographische Schlüssel wird benutzt, um mit einem symmetrischen Verschlüsselungsverfahren die Nachricht zu verschlüsseln.
Das TLS Record Protocol
Das TLS Record Protocol realisiert die TLS-Verbindung in den folgenden Teilschritten:
• Das TLS Record Protocol unterteilt die Daten in Blöcke von maximal 16384 (2¹⁴) Byte.
• Die Blöcke können bei Bedarf komprimiert werden (das Komprimierungsverfahren wird im Handshake ausgehandelt).
• Ein Message Authentication Code wird verwendet, um die Nachrichten-Integrität und -Authentizität abzusichern.
• Die Blöcke werden mit DES, Triple DES oder AES symmetrisch verschlüsselt (Stromchiffren, Blockchiffren oder kombinierte Verfahren) und das Ergebnis wird verschickt.
Auf der Gegenseite läuft es umgekehrt: Entschlüsseln, verifizieren, dekomprimieren und zusammensetzen.
Das TLS Record Protocol nutzt vier Sub-Protokolle:
- TLS Handshake Protocol
- TLS Alert Protocol
- TLS Change Cipher Spec Protocol
- TLS Application Data Protocol
TLS Handshake Protocol
Mit dem TLS Handshake Protocol vereinbaren Server und Client die Sicherheits-Parameter der Session, und zwar in folgenden Schritten:
- Aushandlung der verwendeten kryptographischen Algorithmen (für Verschlüsselung & Integrität) – aber auch unverschlüsselte Übertragung möglich
- Authentifizierung der Kommunikationspartner (Server und/oder Client – meistens aber nur Server gegenüber Client)
- Aushandlung des Schlüssels (des Master Secrets)
- Übertragung der Daten
Vom Client zum Server: „Client Hello“
Das Handshake-Protokoll beginnt mit einem ClientHello. Dabei werden übermittelt:
• eine Liste der unterstützten Cipher Suites (Verschlüsselungsalgorithmen),
• eine 32 Byte lange Nonce des Clients (einige Byte Zufallszahl + 7 Byte aktuelle Zeit des Client + eine Sitzungsnummer für eine möglicherweise notwendige Sitzungswiederaufnahme (siehe https://tools.ietf.org/html/rfc5116#section-3.2.1)).
• eine Liste von Komprimierungsalgorithmen, die der Client unterstützt.
Vom Server zum Client: „Server Hello“, „Server Certificate“, „ServerKeyExchange“, „CertificateRequest“, „Server Hello Done“
ServerHello
Der Server vergleicht die Liste der Cipher Suites, die vom Client beherrscht werden, mit seiner eigenen Liste. Unter den Cipher Suiten, die von beiden Computern beherrscht werden, sucht der Server die beste (sicherste) aus. Dann antwortet der Server mit einem ServerHello, welches enthält:
• die nun als vereinbart geltende Cipher Suite,
• eine 32 Byte lange Nonce des Servers (einige Byte Zufallszahl + 7 Byte aktuelle Zeit des Servers + Sitzungsnummer).
• eine Liste von Komprimierungsalgorithmen, die der Client unterstützt.
Server Certificate
Diese Nachricht wird gesendet, falls die ausgewählte Schlüsselaustausch-Methode ein Zertifikat vorsieht. Gesendet wird ein X509 Zertifikat, passend zur vereinbarten CipherSuite.
ServerKeyExchange
Die ServerKeyExchange-Nachricht wird nur gesendet, falls das Server-Zertifikat nicht alle Parameter zur Berechnung des Premaster Secrets enthält. Dies ist der Fall bei:
DHE_DSS
DHE_RSA
DH_anon
CertificateRequest
Auch die Nachricht Certificate-Request ist optional. Mit dieser Nachricht kann auch der Server vom Client ein Zertifikat fordern, falls dieses für die ausgewählte Cipher Suite zweckmäßig ist. Gesendet wird die Certificate Request Nachricht gleich nach der ServerKeyExchange-Nachricht, bzw. falls diese nicht gesendet wird, nach der Nachricht mit dem Zertifikat des Servers.
Server Hello Done
Die ServerHelloDone-Nachricht zeigt das Ende der mit dem ServerHello einhergehenden Kommunikation an. Der Server wartet jetzt auf die Antwort des Clients.
Vom Client zum Server: „ClientCertificate“, „Client Key Exchange“, „Certificate Verify“
Bevor der Client aber nun seinerseits mit Nachrichten beginnt, sollte er erst einmal verifizieren, ob das Zertifikat des Servers valide ist. Auch die anderen Parameter der Server Hello-Nachrichten sollten überprüft werden.
ClientCertificate
Falls es eine Aufforderung des Servers gab, sendet mit der ClientCertificate-Nachricht der Client seinerseits sein X509 Zertifikat, passend zur gewählten CipherSuite. Falls kein passendes Zertifikat vorhanden ist, muss der Client dennoch eine Certificate-Nachricht senden. Sendet er diese Nachricht nicht, kann der Server die Verbindung abbrechen oder aber auch den Handshake ohne Client-Authentifizierung weiter ausführen.
Client Key Exchange
Während die ServerKey-Exchange-Nachricht optional ist, wird die ClientKeyExchange-Nachricht immer versendet. Entweder folgt sie sofort der Zertifikats-Nachricht, oder sie ist die erste Nachricht vom Client, die auf der ServerHelloDone-Nachricht folgt. Mit dieser Nachricht wird das Premaster Secret festgelegt, entweder direkt durch das Senden eines RSA-verschlüsselten Secrets oder durch die Übermittlung der Diffie-Hellman-Parameter.
Certificate Verify
Optional ist hingegen wieder die CertificateVerify-Nachricht. Damit findet eine explizite Verifikation des Client-Zertifikats statt, d.h. der Nachweis, dass der Client auch im Besitz des privaten Schlüssels ist und damit der ist, für den er sich ausgibt. Diese Nachricht wird nur versandt, falls das Zertifikat des Clients überhaupt signierbar ist.
Berechnung des Schlüsselmaterials (des „Master Secrets“)
Sowohl der Server als auch der Client verfügen jetzt über die gleichen Daten, um das Master Secret (den Schlüssel für die symmetrische Übertragung) zu erstellen.
Das Master Secret wird aus dem Premastersecret, der Client Zufallszahl und der Server Zufallszahl berechnet. Mittels einer Pseudozufallsfunktion (PRF) wird aus diesen drei Bestandteilen nun das Master Secret generiert. Sobald das Master Secret berechnet wurde, sollte das Pre Master Secret aus dem Speicher gelöscht werden.
Berechnung des Master Secrets:
master_secret = PRF(pre_master_secret, „master secret“, ClientHello.random + ServerHello.random)
Das Master Secret ist immer genau 48 Byte lang.
Quellen: https://tools.ietf.org/html/rfc5246
Vom Server zum Client: „ChangeCipherSpec“, „Finished“
Change Cipher Spec
Die Nachricht ChangeCipherSpec zeigt an, das nunmehr gesichert kommuniziert wird. Ab diesem Moment nutzt der TLS Record Layer die ausgehandelten kryptographischen Algorithmen und Schlüssel. Die ChangeCipherSpec-Nachricht ist gleichzeitig auch die erste geschützte Nachricht.
Finished
Die Finished-Nachricht bestätigt die erfolgreiche Durchführung von Schlüsselaustausch und Authentifizierungsprozess. Der Empfänger der Finnished-Nachricht verifiziert den Inhalt der Nachricht, indem ein Hashwert über alle ausgetauschte Nachrichten berechnet und überprüft wird.
TLS-Alert Protokoll
Alerts werden unterteilt in „Warning“ und „Fatal“. Fatale Alert Messages führen zu einem sofortigen Abbruch der Verbindung. Die Alert-Nachrichten sind verschlüsselt und komprimiert.
Das TLS-Alert Protokoll kennt verschiedene Alerts. Einer der wichtigsten Alerts ist die CloseNotify-Nachricht, da bei TLS ein expliziter Verbindungsabbau notwendig ist. Sonst könnte es beispielsweise zu Truncation Angriffe kommen. Jede Partei kann den Austausch einer Closing-Nachricht initiieren und damit der Gegenstelle signalisieren, dass der Sender dem Empfänger keine Nachricht mehr über diese Verbindung schicken wird. Alle Daten, die anschließend empfangen werden, werden ignoriert. Der Empfänger muss seinerseits mit einem close_notify Alert antworten, der Initiator muss allerdings nicht auf diese Antwort warten.
Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal
alert MUST NOT be resumed.
Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing
the connection. For all errors where an alert level is not explicitly specified, the sending party MAY determine at its
discretion whether to treat this as a fatal error or not. If the implementation chooses to send an alert but intends to close the
connection immediately afterwards, it MUST send that alert at the fatal alert level.
If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides
not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD
send a fatal alert to terminate the connection. Given this, the sending party cannot, in general, know how the receiving party will
behave. Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are
sometimes omitted. For example, if a peer decides to accept an expired certificate (perhaps after confirming this with the user) and
wants to continue the connection, it would not generally send a certificate_expired alert.
TLS Change Cipher Spec Protocol
Das Change Cipher Spec Protocol besteht nur aus einer einzigen Nachricht. Diese Nachricht ist ein Byte groß und besitzt den Inhalt 1. Durch diese Nachricht teilt der Sender dem Empfänger mit, dass er in der aktiven Sitzung auf die im Handshake Protocol ausgehandelte Cipher Suite wechselt.
TLS Application Data Protocol
Die Anwendungsdaten werden über das Record Protocol transportiert, in Teile zerlegt, komprimiert und in Abhängigkeit vom aktuellen Zustand der Sitzung auch verschlüsselt. Inhaltlich werden sie von TLS nicht näher interpretiert.
Anmerkung zu E-Mail
Sollte die Browserzeile nach der Anmeldung im jeweiligen Web-Client eine gewöhnliche „http“-URL anzeigen und auch ansonsten keinerlei Hinweise auf eine verschlüsselte Übertragung melden, können Sie versuchen, die E-Mail-Verschlüsselung zu erzwingen: Fügen Sie hierfür ein „s“ nach dem „http“ ein und laden Sie die Seite anschließend erneut. Unterstützt der Provider SSL/TLS-Mails, sollte die Verbindung durch diese Eingabe automatisch umgestellt werden. Überprüfen Sie außerdem in den Kontoeinstellungen, ob Sie die verschlüsselte Verbindung für künftige Log-ins als Standardlösung einstellen können.
Auch im Mail-Client auf dem PC können Sie die Verbindungen zum Mailserver per SSL/TLS verschlüsseln. Die entscheidende Größe, die es hierfür zu definieren gilt, ist der Port, der für den Versand bzw. den Empfang verwendet wird. Die entsprechenden Einstellungsmöglichkeiten finden Sie in den Kontoeinstellungen des jeweiligen Mail-Programms. Häufig gibt es zudem eine generelle Option, um die Mail-SSL/TLS-Verschlüsselung zu aktivieren. Sobald diese eingeschaltet ist, stellt das Programm in der Regel automatisch die passenden Ports ein. Andernfalls können Sie dies manuell erledigen, wobei Sie je nach Eingangsserver-Typ (POP3 bzw. IMAP) unterschiedliche Nummern eintragen müssen:
Posteingangsserver (IMAP)
993
Posteingangsserver (POP3)
995
Als Verbindungstyp wählen Sie in beiden Fällen „SSL“ aus. Für den Ausgangsserver (SMTP) tragen Sie folgenden Port (Verbindungstyp: automatisch) ein:
Postausgangsserver (SMTP)
465
Hinweis
Ist in den Optionen die Funktion StartTLS aktiviert, fordert SMTP entweder Port 25 oder Port 587 für den mit dieser Technik herbeigeführten Aufbau verschlüsselter Verbindungen.
Parameter des Mailserver abfragen
Benutzen Sie das Kommandozeilentool mailsend.exe. Der Befehl
mailsend -info -smtp mail.your-server.de -ssl -port 465
fragt den Mailserver mail.your-server.de nach der verwendeten Cipher-Suite und dem Zertifikat.