4

I am trying to understand the handshake protocol, when we had our ssl debug mode on we saw that the handshake is SSLv3, but the Client Hello as TLSv1.

http-8443-14, READ: SSLv3 Handshake, length = 87 *** ClientHello, TLSv1

What does that mean?

The client sends a SSLv3 ClientHello so that a server who understands only SSLv3 can process that message, and continue with a SSLv3 handshake. But the SSLv3 ClientHello also says "by the way, I know TLSv1, so if you know TLSv1 too, let's do TLSv1 instead of SSLv3.

Please correct if this doesn't make any sense, I am not a networking/IS guy.

7

Your last paragraph is correct: indeed, in the ClientHello message, the client announces its "maximum supported version". So a client that supports both SSL 3.0 and TLS 1.0 will say "I know up to TLS 1.0" (internally, "TLS 1.0" is encoded as "SSL 3.1"), but will still accept to use SSL 3.0. The protocol version which will be used is chosen by the server (in its ServerHello message).

What you observe, though, is an artefact from another peculiarity of SSL, which is that the version is indicated twice. Namely, all traffic in SSL is sent as records, and all records have a five-byte header that indicates:

  • The type of data in the record (type being "handshake message", "alert", "change cipher spec" or "application data")(one byte).
  • The record protocol version (two bytes).
  • The record length (two bytes).

So the report line you observe:

http-8443-14, READ: SSLv3 Handshake, length = 87 *** ClientHello, TLSv1

probably means: "A record of type 'handshake message', version SSL 3.0 and length 87 bytes, has been observed. Its contents turned out to be a ClientHello message that internally says 'I, the client, support protocol versions up to TLS 1.0'."

It is customary for SSL clients to use a "low" version (3.0) on the first record because there are old and broken SSL servers that not only do not support TLS, but also panic and die when faced with a record tagged "TLS 1.0", even though the format of an unencrypted TLS 1.0 record is absolutely identical to that of an unencrypted SSL 3.0 record (except for the version in the record header).

For more information on such details about SSL, read this.

1

While you omit any information about the software stack you are using I assume that this is just another case of using SSLv3 handling routines for parsing TLSv1 data. This is possible because both protocols are very similar. With OpenSSL stacks you will find lots of routines talking about SSLv3 or haven something with sslv3 in the function name, even if they process TLSv1.0+ data.

  • One of our vendors are disabling their sslv3 and enabling their tlsv1, as of now they have both ssl and tls enabled, when we had the ssl debug mode on, the client hello, server hello and everything was tlsv1, except for the initial handshake as sslv3, so I am trying to understand if they completly disable the ssl, will the handshake be successful or not. – Neetha Mar 6 '15 at 14:24
  • Most clients do a so called SSLv23 handshake instead of a TLSv1 handshake to be as compatible as possible to older servers. Within this handshake they announce the best version they support, i.e. today often TLSv12. The server then replies with the best version both sides support. – Steffen Ullrich Mar 6 '15 at 15:01
1

This is pretty much correct. The details are laid out in the TLS RFCs, but here's the short version:

TLS messages are sent with several layers; a ClientHello message is sent within a TLSPlaintext Record, which is transported over (usually) TCP. The TLSPlaintext record has a "version" field, which is where the SSLv3 you are seeing comes from. The ClientHello message has a "client_version" field, which is the TLSv1 value reported.

A TLS implementation is supposed to accept any version that starts with "3" (TLSv1 is 3.1, TLSv1.1 is 3.2, etc). In practice, some servers will fail silently (instead of giving a useful alert) if this version is higher than they can support. So clients usually send either "3.0" (SSLv3) or the minimum version that they can support.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.