One of the areas in which tls improves on ssl is in its procedures for notification of potential and actual security alerts. In particular, tls defines almost twice as many alert descriptions. Table 5-3 pro-
vides the complete list of tls alerts. It also marks which of those are new to tls (with a bullet in the leftmost column), and it emphasizes the fact that alert description 41 (NoCertificate) was deleted in tls. The tls specification removed this alert because, in practice, it was difficult to implement. Successfully interpreting the NoCertificate alert requires a high level of synchronization between the Alert and
Handshake protocols, a synchronization that is otherwise not needed. To eliminate the requirement for this synchronization, tls has clients that do not have appropriate certificates simply return an empty Certificate message.
Table 5-3 TLS Alert Descriptions
Value Name Meaning
0 CloseNotify The sending party indicates explicitly that it is closing the connection; closure alerts have a warning severity level.
10 Unexpect- edMessage
The sending party indicates that it re- ceived an improper message; this alert is always fatal.
20 BadRecord-
MAC
The sending party indicates that it re- ceived a message with a bad message au- thentication code; this alert is always fatal.
• 21 Decryption-
Failed
The sending party indicates that a mes- sage it decrypted was invalid (e.g., it was not a multiple of the block size or had invalid padding); this alert is always fatal.
• 22 RecordOver-
flow
The sending party indicates that a mes- sage it received was, after decryption or decompression, more than 214
+2048 bytes; this message is always fatal.
30 Decompres- sionFailure
The sending party indicates that it re- ceived data that it could not decompress; this alert is always fatal.
40 Hand- ShakeFailure
The sending party indicates that it was not able to negotiate an acceptable set of se- curity services for the session; this alert is always fatal.
41 NoCertificate The sending party (which is always a cli- ent) indicates that it has no certificate that can satisfy the server’s CertificateRequest. 42 BadCertifi-
cate
The sending party received a certificate that was corrupt (e.g., its signature could not be verified).
43 Unsupport- edCertificate
The sending party received a certificate of a type that it could not support.
Value Name Meaning 44 Certificate-
Revoked
The sending party received a certificate that has been revoked by the certificate authority.
45 Certificate- Expired
The sending party received a certificate that has expired.
46 Certificate- Unknown
The sending party indicates an unspecified problem with a received certificate. 47 IllegalParam-
eter
The sending party indicates that it re- ceived a handshake message with a pa- rameter value that was illegal or inconsistent with other parameters.
• 48 UnknownCA The sending party indicates that it could not identify or does not trust the certifi- cate authority of a received certificate chain; this message is always fatal.
• 49 Access-
Denied
The sending party indicates that the party identified in the peer’s certificate does not have access rights to continue negotiation; this error is always fatal.
• 50 DecodeError The sending party indicates that a re- ceived message could not be decoded be- cause a field value was out of the
permitted range or the message length was invalid; this message is always fatal.
• 51 DecryptError The sending party indicates that a crypto- graphic operation essential to the hand- shake negotiation failed.
• 60 ExportRe-
striction
The sending party indicates that it de- tected a negotiation parameter not in compliance with applicable U.S. export re- strictions; this message is always fatal.
• 70 Protocol-
Version
The sending party indicates that it cannot support the requested TLS protocol ver- sion; this message is always fatal.
• 71 Insufficient- Security
The sending party (always a server) indi- cates that it requires cipher suites more secure than those supported by the client; this message is always fatal.
Value Name Meaning
• 80 InternalError The sending party indicates that an error local to its operation and independent of the TLS protocol (such as a memory alloca- tion failure) makes it impossible to con- tinue; this message is always fatal.
• 90 UserCan-
celed
The sending party indicates that it wishes to cancel the handshake negotiation for reasons other than a protocol failure; this message is typically a warning and should be followed by a CloseNotify.
• 100 NoRenego-
tiation
The sender indicates that it cannot comply with the peer’s request to renegotiate the
TLS handshake; this message is always a
warning.
5.4.3 Message Authentication
Another area in which tls improves on ssl is in the algorithms for message authentication. The way ssl message authentication com- bines key information and application data is rather ad hoc, created just for the ssl protocol. The tls protocol, on the other hand, relies on a standard message authentication code known as h-mac (for Hashed Message Authentication Code). The h-mac algorithm is a defined standard, and has been subjected to rigorous cryptographic analysis. The h-mac specification (see the References section) in- cludes a precise description of the approach, as well as sample source code, but figure 5-7 illustrates h-mac in a format that can be com- pared with other figures in this text. Note that h-mac does not spec- ify a particular hash algorithm (such as md5 or sha); rather, it works effectively with any competent hash algorithm.
The tls message authentication code is a straightforward application of the h-mac standard. The mac is the result of the h-mac ap- proach, using whatever hash algorithm the negotiated cipher suite requires. The h-mac secret is the mac write secret derived from the master secret. Table 5-4 lists the information that is protected.
Table 5-4 Data Protected by TLS Message Authentication Code Data Protected by H-MAC
• Sequence number
• TLS protocol message type
• TLS version (e.g., 3.1) • Message length • Message contents secret 0, 0, 0, ..., 0 64 bytes of 0x36 64 bytes 64 bytes exclusive-OR output Exclusive-OR data to protect H( ) 64 bytes of 0x5C exclusive-OR output H( ) hash MAC Exclusive-OR