4

My Server is configured to accept both SSLv3 and TLS1.0 protocols. But a few clients are sending below handshake parameters and after the server hello, the client drops the connection and sends 'handshare failure(40) alert, not sure if it's the client fault or server.

Here's the initial client hello packet: 

Secure Socket Layer
  SSLv3 Record Layer: Client Hello
  Content Type: Handshake (22)
    Version: SSL 3.0 (0x0300) <-----------------
    Length: 103
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
        Length: 78
        Version: TLS 1.0 (0x0301) <-------------
        Random
        Session ID Length: 0
        Cipher Suites Length: 18
        Cipher Suites (9 suites)

The Record layer is SSL 3.0 but the inside handshake protocol is TLS 1.0. My question is, is this the right way of doing it i.e. using different versions for each layer? if it is what method is it? I can't find it anywhere, I looked through the RFC but can't find any reference. Also, how can I produce such requests?

EDIT: I'm not interested in troubleshooting and fixing the issue, I just want to know how can I send such packets? Any command? And what should I name this method? i.e. I can use curl or openssl to either use ssl3 or tls1 but that would send same version in both record layer and handshake layer:

curl -v -ssl3 https://www.mywebserver.com

Above curl command would look on wireshark:

Wireshark

EDIT2: Is this even legal? I have been googling around and can't find any example. Is it violating any rfc standards?

Thanks

Mardanian
  • 191
  • 2
  • 11
  • There's nothing wrong with the trace you've posted so far. This is a normal way of negotiating to TLS. You need to provide more data around the alert. Most probably the client doesn't trust the server certificate. – user207421 Mar 10 '12 at 08:53
  • @Mardanian: use a SSL proxy or something like WireShark to take a deeper look into the SSL protocol. Most of the time you can see what's going wrong there, although the tools are not the easiest to use. Verifying that the server certificate is trusted should be doable however, as EJP suggests. – Maarten Bodewes Mar 10 '12 at 13:38

2 Answers2

4

Yes, this is legal (at least it was clarified in recent TLS specifications).

You can look this up in rfc5246 (TLS 1.2) or in rfc6101 (SSL 3.0) or other rfc's concerning the SSL/TLS. The problem is with the initial version of the record protocol and with the handshake protocol:

rfc5246:

   Earlier versions of the TLS specification were not fully clear on
   what the record layer version number (TLSPlaintext.version) should
   contain when sending ClientHello (i.e., before it is known which
   version of the protocol will be employed).  Thus, TLS servers
   compliant with this specification MUST accept any value {03,XX} as
   the record layer version number for ClientHello.

   TLS clients that wish to negotiate with older servers MAY send any
   value {03,XX} as the record layer version number.  Typical values
   would be {03,00}, the lowest version number supported by the client,
   and the value of ClientHello.client_version.

Regarding the handshake protocol, the client will negotiate the highest version that it has implemented:

client_version: The version of the TLS protocol by which the client wishes to
      communicate during this session.  This SHOULD be the latest
      (highest valued) version supported by the client
Community
  • 1
  • 1
1

I just want to know how can I send such packets? Any command?

openssl s_client -connect www.myserver.com:443 -no_ssl2

should produce something similar to the trace you provided.

Jumbogram
  • 2,249
  • 1
  • 20
  • 24