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
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
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
The following people have reported errors in "SSL and TLS".
If you reported an error and you're not credited here, please let me