Alert Protocol

In short: The TLS sub-protocol through which client and server notify each other of errors or status changes — e.g. an invalid certificate or the orderly ending of a connection.

In more detail: Alert messages have a severity level (warning or fatal) and a description code (e.g. certificate_expired, handshake_failure, close_notify). A “fatal” alert ends the connection immediately; a “warning” can be tolerated depending on the type. close_notify is the regular way to end a TLS connection cleanly — it prevents so-called truncation attacks, in which an attacker simply breaks off a connection to cut off data.

In Depth

Structure and important codes

Every alert message consists of two bytes: a level (warning = 1 or fatal = 2) and a description code that names the exact reason. Some of the most important codes:

close_notify (0)          - regular, orderly end of the connection
unexpected_message (10)   - a message arrived in the wrong order
bad_record_mac (20)       - integrity check of a data packet failed
decryption_failed (21)    - decryption of a record failed (outdated, no longer used)
handshake_failure (40)    - no common encryption algorithm found
bad_certificate (42)      - certificate is corrupt or invalidly signed
certificate_expired (45)  - server certificate has expired
certificate_unknown (46)  - certificate couldn't be matched to a known certificate authority
access_denied (49)        - handshake was technically valid, but access was denied
protocol_version (70)     - incompatible TLS version
insufficient_security (71)- server requires a stronger cipher suite than offered
no_renegotiation (100)    - refusal of a renewed handshake negotiation

Warning vs. fatal — and why the distinction has eroded

The difference between warning and fatal is smaller in practice than the names suggest: modern TLS implementations (from TLS 1.3) treat practically every alert except close_notify and user_canceled as fatal and end the connection immediately — earlier, more tolerant handling of “warning” alerts had proven to be a security risk in practice, because it gave attackers room for downgrade attacks. The historical reason: with older TLS/SSL implementations, an attacker on the network could deliberately manipulate certain handshake messages and provoke only a “warning” alert that didn’t break the connection — in this way they could gradually negotiate the connection down to a weaker, attackable protocol (downgrade attack) without the connection failing completely.

close_notify and truncation attacks

close_notify deserves special mention: without this signal, an attacker can simply cut a TCP connection (e.g. with a forged TCP RST packet) without sender or recipient noticing that data is missing at the end — a so-called truncation attack. A classic example: an attacker on the network cuts an HTTPS connection exactly after the line “the amount will be debited”, before the confirmation “…but only if you click ‘Yes’” arrives — the user sees what appears to be a complete but manipulated page. If, on the other hand, the other side sends an authenticated close_notify, the recipient knows beyond doubt that the message is complete and wasn’t cut off prematurely; if it’s missing, the client has to treat the connection as potentially incomplete.

Comparison with other TLS sub-protocols

The alert protocol works independently alongside the other TLS sub-protocols: while the handshake protocol establishes the connection and the application data protocol transfers the actual payload, an alert message can be sent at ANY time during the connection — even in the middle of the handshake or during data transfer. The change cipher spec protocol, on the other hand, (in TLS 1.2) only occurs at a fixed point in the handshake.

See also: Handshake Protocol, TLS