SSL and TLS Errata



See here for notes on errata in the the C sample code.
The following errors have been found in SSL and TLS. These errors are in the first printing and will be corrected if/when there is a second printing. Also see the "Comments to the Reader" section at the end of this page.


p. 2: Change "packet packet" in the second paragraph to read "packet."
p. 59: Line (3) on Figure 3.1 should read "Encrypted PreMaster Secret"
p. 58: The last sentence of step 3 should read "It sends the encrypted pre_master_secret to the server."
p. 79: replace "two version number bytes" with "two bytes containing the client's offered version number".
Remove the sentence beginning "An implementation note".
p. 87: First paragraph after "SSLv3 Key Derivation" should start with "SSLv3" not "SLv3".
p. 88: The maximum record length is actually 2^14-1 bytes, not 2^14. Note that the length includes the MAC and padding but not the header.
p. 103: First sentence. Replace "field composed of points" with "Abelian group composed of points"
p. 130: Second paragraph under the bad_record_mac head should read decryption_failed, not decryption_error.
p. 136: The last paragraph is simply wrong. There's no way for an SSLv3/TLS implementation to signal that it has chosen any cipher suite that was defined in SSLv2 but not has no corresponding suite in SSLv3/TLS. The TLS RFC includes all these cipher suites with no comment about some of them not having matches in SSLv3/TLS. When I copied the table, I noted that some didn't match but somehow managed to convince myself that they still could be negotiated. They cannot.

In point of fact, it's not clear how to handle this issue in the situation where a client presents an SSLv2 cipherspec but not its matching SSLv3 cipher suite. One approach would be to map it to the SSLv3 cipher suite and negotiate that. Another would be to ignore it entirely. I've raised this issue with the TLS mailing list and I'll update this space when it gets sorted out.


p. 137: Add the following after the first paragraph. "Note, however, that an attacker with the computational resources to exhaustively search the SSLv2 symmetric keyspace in real time can force the connection to SSLv2 and then impersonate the server by exhaustively searching his keys during connection setup. This is possible because SSLv2 uses the same keying material as the basis for its MAC as for it's encryption key (see Appendix B.4). This attack is only currently practical for 40-bit keys, but will eventually become possible with 56-bit keys. The only defense against it is to disable 40-bit keys (or SSLv2) which is a good idea in any case. By the time that 56-bit keys become vulnerable, we can only hope that SSLv2 will have been finally phased out.
p. 171: After p -1=2qj add "where j is the product of large (>q) primes."
Change "strong prime" to "safe prime".
p. 215: The part of the first paragraph starting with "This is smaller" should be rewritten as follows:
This is smaller than the Ethernet maximim segment size (MSS) and more data could be transmitted if the buffer were larger. The second segment containing the rest of the ServerKeyExchange and the ServerHelloDone is less than MSS and therefore gets held up by the Nagle algorithm. This segment can't be transmitted until the previous segment, containing the ServerHello and the Certificate message is ACKed." The rest of the paragraph is the same.
p. 216: The last sentence of the first paragraph should read: "In this case, the rest of the data would likely be held up by the Nagle algorithm, unless it happened to also be full-sized."
p. 250: "SSLeay's predecessor, OpenSSL" should read "OpenSSL's predecessor, SSLeay"
p. 308: Add the following to the end of the second paragraph. "An important exception to this rule is that the attacker must not be able to exhaustively search the weakest SSLv2 symmetric keys, as described in Chapter 4."
p. 313: This diagram should have a TCP FIN from the server to the client preceding the close_notify from the server. The FIN is what triggers the close_notify from the server. Note that the server should not allow the client to resume the session, because the client did not send a close_notify, but it does anyway, in violation of RFC 2246.
p. 467: In the reference for [Dusse1998], the name should be Hoffman, not Hossman.

Comments to the Reader

The following are not errors but merely additional comments on the text.
p. 81: The handshake_messages include the content of the SSL records only but not the record header. Thus, they include the handshake message header.
p. 135: To expand upon "SSLv2 and SSLv3 length bytes are in different locations": The first two bytes of an SSLv2 message are the length. They aren't presented in Figure 4.13 because they're not part of the SSLv3 handshake message per se (as documented in the protocol spec.) but rather part of the header. Since SSLv3/TLS has the content type first, the length of an SSLv2 handshake message appears to be greater than 0x1600, which is a totally unreasonable message length. This is how you can tell the difference between SSLv2 and SSLv3 messages. This isn't an error but it could be clearer. I'll try to update in the next printing.
p. 286: Note that because the attacker might have tampered with your DNS, the hostname->IP address mapping is untrustworthy. If the application wishes to do session resumption based on IP address, the certificate must be cached with the session and the application must check the certificate against the hostname, even when resuming.
p. 287: Although this code works correctly, it contains a misfeature that can become an error if you cut and paste it into your code. The SESSION structure obtained if you call SSL_get_session() is allocated along with the SSL structure. If the corresponding SSL structure is freed then the SESSION will be freed as well. This isn't a problem here because we don't free the SSL structure. A new API call, SSL_get1_session(), introduced in OpenSSL 0.9.5, increments the reference count for the SESSION and therefore protects it from being prematurely freed. Since this code is supposed to run with OpenSSL 0.9.4, this code can't be changed without changing a large number of pages. However, an appropriate note will be inserted.

Acknowledgements

The following people have reported errors in "SSL and TLS". If you reported an error and you're not credited here, please let me know.
Kevin Fu
John Garberson
Peter Guttman
Greg Stark