TLS

TLS steht für Transport Layer Security. Es ist das Protokoll hinter HTTPS und schützt Verbindungen zwischen Client und Server.

TLS ist der Nachfolger von SSL. Moderne Systeme sollten aktuelle TLS-Versionen und sichere Cipher Suites verwenden.

Kurze Geschichte

Die Unterlagen zeigen die Entwicklung von SSL zu TLS:

• frühe SSL-Versionen hatten viele Schwachstellen
• TLS 1.0 wurde 1999 standardisiert
• TLS 1.1 und TLS 1.2 folgten später
• TLS 1.3 wurde 2018 veröffentlicht

TLS 1.3 vereinfacht und modernisiert viele Teile des Protokolls.

TLS Protocol Suite

TLS besteht aus mehreren Teilen.

TLS Record Protocol

Das Record Protocol zerlegt Daten in Blöcke, schützt sie und sendet sie weiter.

Es sorgt für:

• Verschlüsselung
• Integrität
• Authenticated Encryption
• Transport von Anwendungsdaten

Die eigentlichen Nutzdaten werden mit symmetrischen Verfahren geschützt, weil diese für große Datenmengen effizient sind.

Diffie-Hellman Key Agreement

TLS braucht gemeinsame Schlüssel, ohne sie direkt ungeschützt zu übertragen.

Diffie-Hellman ermöglicht es, über einen unsicheren Kanal ein gemeinsames Geheimnis zu vereinbaren.

Grundidee:

1. Client und Server einigen sich auf öffentliche Parameter.
2. Beide erzeugen jeweils einen privaten geheimen Wert.
3. Beide berechnen öffentliche Werte.
4. Aus dem öffentlichen Wert der Gegenseite und dem eigenen privaten Wert entsteht dasselbe gemeinsame Geheimnis.

Eine außenstehende Person sieht die öffentlichen Werte, kann daraus aber das gemeinsame Geheimnis praktisch nicht berechnen, wenn die Parameter stark genug sind.

Diskrete Logarithmen

Die Sicherheit klassischer Diffie-Hellman-Verfahren hängt damit zusammen, dass diskrete Logarithmen bei sehr großen Zahlen schwer zu berechnen sind.

Für kleine Zahlen lässt sich das nachrechnen. Für echte Parametergrößen ist es praktisch nicht machbar.

Man-in-the-Middle

Diffie-Hellman allein schützt nicht automatisch gegen einen Man-in-the-Middle-Angriff.

Ein Angreifer könnte sich zwischen Client und Server setzen und mit beiden Seiten eigene Schlüssel aushandeln.

Deshalb braucht TLS zusätzlich Authentifizierung, vor allem über Zertifikate und Signaturen.

Forward Secrecy

Forward Secrecy bedeutet:

Wenn ein langfristiger privater Schlüssel später gestohlen wird, sollen alte aufgezeichnete Sitzungen trotzdem nicht entschlüsselt werden können.

Dafür werden kurzlebige Schlüsselaustausche verwendet. Alte Session Keys sollen nicht aus einem später kompromittierten Langzeitschlüssel rekonstruierbar sein.

TLS Handshake

Der Handshake erledigt mehrere Dinge:

• Aushandeln unterstützter Verfahren
• Schlüsselaustausch
• Authentifizierung des Servers
• optional Authentifizierung des Clients
• Ableitung von Sitzungsschlüsseln
• Wechsel in verschlüsselte Kommunikation

In TLS 1.3 werden dafür moderne Key-Derivation-Funktionen wie HKDF verwendet.

Zertifikat prüfen

Beim Besuch einer HTTPS-Website kann man das Zertifikat anzeigen.

Interessante Informationen:

• für welche Domain das Zertifikat gilt
• wer es ausgestellt hat
• wann es abläuft
• welcher öffentliche Schlüssel enthalten ist
• welche Signaturkette verwendet wird

Der Browser prüft diese Informationen automatisch, aber man kann sie manuell inspizieren.

Session Tickets und 0-RTT

TLS kann Handshakes beschleunigen, indem frühere Sitzungsinformationen wiederverwendet werden.

Bei 0-RTT können Daten sehr früh gesendet werden. Das ist schnell, hat aber ein Risiko:

• Early Data kann anfälliger für Replay-Angriffe sein.
• Besonders problematisch ist das bei Aktionen, die den Serverzustand verändern.

TLS untersuchen

Die Unterlagen nennen praktische Werkzeuge:

openssl s_client -connect example.org:443

Mit solchen Befehlen kann man Zertifikate und TLS-Verbindungen untersuchen.

Auch Wireshark oder Cloudshark können verwendet werden, um Handshakes sichtbar zu machen.

Merksatz

TLS kombiniert viele kryptografische Bausteine: Zertifikate, Signaturen, Schlüsselaustausch, symmetrische Verschlüsselung und Integritätsschutz. Gerade deshalb sollte man TLS konfigurieren, nicht selbst nachbauen.