The following are errata to the SSL 3.0 specification, published March, 1996.

Section 7.2.3.1

The MAC algorithm should be:

hash(MAC_write_secret + pad_2 + hash(MAC_write_secret + pad_1 + seq_num + SSLCompressed.type + SSLCompressed.length + SSLCompressed.fragment))

The SSLCompressed.type field was dropped on the floor (as well as the more specific indication of the input data). The type field is needed to prevent a message from being aliased among the handshake, alert or client data streams. Two bytes of the SSLCompressed.length field are fed into the hash.

pad_2 is the same length as pad_1.

Section 7.4.1

The description of closure alerts is unclear. This may help:

Each side (client or server) sends a closure alert before actually closing its end of the connection.

Either party may initiate a close by sending a closure alert. Any data received after sending the closure alert is ignored. Once the alert is sent, the connection is closed.

It is not necessary for the first side that sends a closure alert to wait for a responding closure alert from the second side before it closes the connection. The first side may wait for the closure alert from the second but is not obligated to do so. The first does have the option of only closing its outgoing half of the connection.

The party that receives a closure alert aborts any in-progress transfers and then closes the connection. The second side is obligated to attempt to do the send of the closure alert, but must handle any errors that arise from the send due to the connection being closed.

NB: It is assumed that closing a connection reliably delivers the data before destroying the transport.

Section 7.5

The handshake diagram is missing the ServerHelloDone message. It should be the final message at the end of the first block under "SERVER". The CertificateRequest and ServerKeyExchange messages are misordered in the diagram.

Section 7.6.1.2

For forward compatibility reasons, it's legal for a client hello message to have extra data after the compression methods. This data should be included in the handshake hashes, but otherwise ignored.

Sections 7.6.8 and 7.6.9

pad1 and pad2 values are the same as the pad_1 and pad_2 values used in computing the MAC.

Section 7.6.9

In the finished messages discussion, in the third paragraph, change "the finished messages" to "this finished message." Each hash in each finished message includes all of the handshake data from both sides up to but not including the message being constructed. The input to the hash of the second side to send a finished message includes the contents of the first finished message.

Appendix C

We've added a new ciphersuite for FORTEZZA key exchange plus RC4 encryption.

SSL_FORTEZZA_DMS_WITH_RC4_128_SHA 0x001e

This ciphersuite is not exportable outside the United States.