According to the book, Data Center Fundamentals, page 369, SSLv3 support was added in Netscape 2.x and Internet Explorer 3.x, and TLS was added in Netscape 4.x and Internet Explorer 4.x.

I am listening router in my company(I have 200mb pcap file with just https connection) and these old clients does not exist in company computers but I observe some of the client hello requests are in SSLv2 format. So only reason a client send client hello in SSLv2 format seems compatibility with servers who does not support new versions of ssl . This compatibility issue stated in https://www.rfc-editor.org/rfc/rfc5246#appendix-E.2 .

I couldn't understand when client send "client hello" in v2 for compatibility . How client decides it should send v2 client hello or how it decides it should send v3.1 for example ?

1 Answer 1


A client sends a SSLv2 ClientHello when it is ready to use SSLv2, and it supposes that the server may be an SSLv2-only server. In practice, a given client will always send a SSLv2 ClientHello, or never: the client cannot know what a specific server supports until it has actually talked to it, so it is an all-or-nothing configuration option.

Modern browsers are of the "never" persuasion; some don't support SSLv2 at all (SSLv2 is officially deprecated; its support has been removed from OpenSSL, so Web server using Apache+OpenSSL will soon to support it). But older browser versions could use SSLv2, and some were sending SSLv2 ClientHello by default (I think IE 6.0 did that).

Note that a server can understand the SSLv2 ClientHello format and still not support SSLv2 (i.e. the server accepts the ClientHello only if it internally states that the client also knows SSL 3.0 or TLS).

Since the SSLv2 ClientHello format is incompatible with extensions such as Server Name Indication (there's no room for extensions in that format), and since it makes no sense for a client to send such a ClientHello unless it is ready to actually do a full connection in SSLv2, we can assume that the SSLv2 ClientHello feature will disappear in the future... but we are not there yet.

  • I think one of my confusion was if browser is added SSLv3 support it has to use it . But after reading your answer now I understand client can choose . A case can be like (please correct me if I am wrong) I try to connect a server with SSLv3 but it only supports v2 because I couldn't connect I can switch my browser configuration to sslv2 and try connecting to server again. Commented Apr 25, 2013 at 11:26
  • But I still can't understand why to send sslv2 client hello record and saying I am sslv3 to a server as stated tools.ietf.org/html/rfc5246#appendix-E.2 . Commented Apr 25, 2013 at 11:28
  • 3
    The client sends a SSLv2 ClientHello so that a server who understands only SSLv2 can process that message, and continue with a SSLv2 handshake. But the SSLv2 ClientHello also says "by the way, I know SSLv3, so if you know SSLv3 too, let's do SSLv3 instead of SSLv2", which is what usually happens (servers who know only of SSLv2 are extremely rare nowadays). Commented Apr 25, 2013 at 11:30
  • Sun/Oracle/OpenJDK Java has had support for "SSLv2Hello" for a long time (without actual support for SSLv2), and it was used by default until Java 7.
    – Bruno
    Commented Apr 25, 2013 at 16:13
  • Actually there are Clients who sent modern packets, and if they do not get proper responses re-try with a more conservative approach (like for example SSL2 record format). This Out Of Band Protocol Fallback is one of the problems in Poodle. Newer Clients are supposed to send a TLS_FALLBACK_SCSV {0x56, 0x00} virtual ciper in that case (so a server can reject those weakend attempts if he thinks he is up-to-date).
    – eckes
    Commented May 8, 2015 at 1:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .