Cryptography Reference
In-Depth Information
The next byte is the certificate_type . This was added to support other
certifi cates besides x.509, although no other certifi cate types were ever defi ned.
This is followed by the version of SSL that the server understands. The speci-
fi cation isn't clear on what should be done if, in theory, the server understands
a higher version of the protocol than the client, or if it doesn't understand the
version that the client sent. However, this turned out to be a moot point. The
next version of SSL was defi ned completely incompatibly with SSLv2, so ver-
sion interoperability never came up. If the client sends an SSLv3+ handshake
message to an SSLv2-only server, the server doesn't understand the message to
begin with and immediately errors out. Likewise, if the client requests SSLv2,
but the server would rather negotiate SSLv3 (which would be good advice), its
only option is to reject the client hello with an error and hope the client retries
with SSLv3 semantics. To complicate matters even further, there's no standard
SSLv2 error message indicating that the protocol version requested isn't sup-
ported. As such, the only thing you ever see in these two bytes is 0, 2.
Finally, the server sends its variable length parameters — its certifi cate, its
supported cipher specs, and its connection ID.
The certifi cate is in the format described in Chapter 5. Actually, the SSLv2
specifi cation wasn't entirely clear on how the certifi cate should be encoded,
but all implementations present the certifi cate in ANS.1 DER encoding. Notice
that the defi nition only leaves room for one certifi cate — there's no concept
of “certifi cate chaining” here. SSLv3/TLS 1.0 introduced certifi cate chaining,
although without x.509v3 certifi cate extensions, this turned out to be a mistake.
The certifi cate is followed by a variable-length list of the cipher specs that the
server supports. It's not clear whether this should be all of the ciphers that
the server supports, or just the union of those that it supports with those that it
knows the client supports. Remember, the client has already sent an exhaustive
list of which ciphers it supports in its own hello message. However, it's unclear
what use a client might make of the knowledge that the server supports a cipher
that the client doesn't, so OpenSSL 0.9.8 returns the union of the two lists. Notice that
SSLv2 lets the client fi nally select the cipher suite; SSLv3+ has the server do
this — which actually makes more sense.
Finally, the server sends back a connection_id that serves the same purpose
to the server that the challenge token served the client — to prevent replay
attacks by forcing the client to encrypt a random value on each connection
attempt. Note that the connection ID is not the session ID — that will be sent at
the very end, in the server fi nished message.
After ssl_connect sends its ClientHello message, it waits until the server
responds with a ServerHello :
while ( !parameters->got_server_hello )
{
// set proposed_cipher_spec from server hello
Search WWH ::




Custom Search