Alert Protocol

Kurz: Das TLS-Teilprotokoll, über das Client und Server sich gegenseitig Fehler oder Statusänderungen mitteilen — z. B. ein ungültiges Zertifikat oder das geordnete Beenden einer Verbindung.

Genauer: Alert-Nachrichten haben eine Schweregrad-Stufe (warning oder fatal) und einen Beschreibungscode (z. B. certificate_expired, handshake_failure, close_notify). Ein “fatal”-Alert beendet die Verbindung sofort, ein “warning” kann je nach Typ toleriert werden. close_notify ist der reguläre Weg, eine TLS-Verbindung sauber zu beenden — verhindert sogenannte Truncation-Angriffe, bei denen ein Angreifer eine Verbindung einfach abbricht, um Daten abzuschneiden.

Im Detail

Aufbau und wichtige Codes

Jede Alert-Nachricht besteht aus zwei Bytes: einem Level (warning = 1 oder fatal = 2) und einem Description-Code, der den genauen Grund benennt. Einige der wichtigsten Codes:

close_notify (0)          - reguläres, geordnetes Verbindungsende
unexpected_message (10)   - Nachricht kam in falscher Reihenfolge
bad_record_mac (20)       - Integritätsprüfung eines Datenpakets fehlgeschlagen
decryption_failed (21)    - Entschlüsselung eines Records fehlgeschlagen (veraltet, nicht mehr genutzt)
handshake_failure (40)    - kein gemeinsamer Verschlüsselungsalgorithmus gefunden
bad_certificate (42)      - Zertifikat ist beschädigt oder ungültig signiert
certificate_expired (45)  - Server-Zertifikat ist abgelaufen
certificate_unknown (46)  - Zertifikat konnte keiner bekannten Zertifizierungsstelle zugeordnet werden
access_denied (49)        - Handshake war technisch gültig, aber Zugriff verweigert
protocol_version (70)     - inkompatible TLS-Version
insufficient_security (71)- Server verlangt eine stärkere Cipher Suite als angeboten
no_renegotiation (100)    - Ablehnung einer erneuten Handshake-Aushandlung

Warning vs. Fatal — und warum die Unterscheidung erodiert ist

Der Unterschied zwischen warning und fatal ist in der Praxis kleiner als der Name vermuten lässt: Moderne TLS-Implementierungen (ab TLS 1.3) behandeln praktisch jeden Alert außer close_notify und user_canceled als fatal und beenden die Verbindung sofort — frühere, tolerantere Handhabung von “warning”-Alerts hatte sich in der Praxis als Sicherheitsrisiko erwiesen, weil sie Angreifern Spielraum für Downgrade-Angriffe gab. Der historische Grund: Bei älteren TLS/SSL-Implementierungen konnte ein Angreifer im Netzwerk gezielt bestimmte Handshake-Nachrichten manipulieren und dabei nur ein “warning”-Alert provozieren, das die Verbindung nicht abbrach — er konnte so schrittweise die Verbindung auf ein schwächeres, angreifbares Protokoll herunterhandeln (Downgrade-Angriff), ohne dass die Verbindung komplett fehlschlug.

close_notify und Truncation-Angriffe

close_notify verdient besondere Erwähnung: Ohne dieses Signal kann ein Angreifer eine TCP-Verbindung einfach kappen (z. B. durch ein gefälschtes TCP-RST-Paket), ohne dass Sender oder Empfänger merken, dass Daten am Ende fehlen — ein sogenannter Truncation-Angriff. Ein klassisches Beispiel: Ein Angreifer im Netzwerk kappt eine HTTPS-Verbindung genau nach der Zeile “Betrag wird abgebucht”, bevor die Bestätigung “…aber nur, wenn Sie auf ‘Ja’ klicken” ankommt — der Nutzer sieht scheinbar eine vollständige, aber inhaltlich manipulierte Seite. Sendet die Gegenseite dagegen ein authentifiziertes close_notify, weiß der Empfänger zweifelsfrei, dass die Nachricht vollständig und nicht vorzeitig abgeschnitten ist; fehlt es, muss der Client die Verbindung als potenziell unvollständig behandeln.

Vergleich zu anderen TLS-Teilprotokollen

Das Alert Protocol arbeitet unabhängig neben den anderen TLS-Teilprotokollen: Während das Handshake Protocol die Verbindung aufbaut und das Application Data Protocol die eigentlichen Nutzdaten überträgt, kann eine Alert-Nachricht zu JEDEM Zeitpunkt der Verbindung gesendet werden — auch mitten im Handshake oder während der Datenübertragung. Das Change Cipher Spec Protocol dagegen kommt (in TLS 1.2) nur an einer festen Stelle im Handshake vor.

Siehe auch: Handshake Protocol, TLS