Handshake that only works when forcing TLS10

[madjar]

Hello

I've got some troubles connecting to a server (sadly, it's behind firewall). When trying to connect without specifying any TLS version, I get the following error:

tls-simpleclient -v -d hue-bigplay.bigdata.intraxa 443 --no-validation
sending query:
GET / HTTP/1.0



debug: >> Handshake [ClientHello TLS12 (ClientRandom {unClientRandom = "\240!\148s\180\157r\207\143\179\234\189Y\206\GS\243\GS$\141\244\164A\205\142\171.\SI\145\b\153\248\198"}) (Session Nothing) [107,103,57,51,56,50,47,53,4,5,10,158,49199,49195] [0] [(0,"\NUL\RS\NUL\NUL\ESChue-bigplay.bigdata.intraxa"),(65281,"\NUL"),(10,"\NUL\ACK\NUL\DLE\NUL\NAK\NUL\ETB"),(11,"\SOH\NUL"),(13,"\NUL\f\ACK\SOH\ENQ\SOH\EOT\SOH\ETX\SOH\STX\SOH\STX\STX")] Nothing]
debug: << Alert [(AlertLevel_Fatal,ProtocolVersion)]
debug: >> Alert [(AlertLevel_Fatal,HandshakeFailure)]
tls-simpleclient: HandshakeFailed (Error_Protocol ("expecting server hello, got alert : [(AlertLevel_Fatal,ProtocolVersion)]",True,HandshakeFailure))

However, if I force TLS 1.0, the handshake continues without troubles:

tls-simpleclient -v -d hue-bigplay.bigdata.intraxa 443 --tls10 --no-validation
sending query:
GET / HTTP/1.0



debug: >> Handshake [ClientHello TLS10 (ClientRandom {unClientRandom = "\US\DC39&Og\"\191x\224\SUB\234j\229J\251\\\238\254\217\\\241\SI2\CAN\245\173\v\ESC\232qG"}) (Session Nothing) [107,103,57,51,56,50,47,53,4,5,10,158,49199,49195] [0] [(0,"\NUL\RS\NUL\NUL\ESChue-bigplay.bigdata.intraxa"),(65281,"\NUL"),(10,"\NUL\ACK\NUL\DLE\NUL\NAK\NUL\ETB"),(11,"\SOH\NUL"),(13,"\NUL\f\ACK\SOH\ENQ\SOH\EOT\SOH\ETX\SOH\STX\SOH\STX\STX")] Nothing]
debug: << Handshake [ServerHello TLS10 ...(crashing later with "tripledes cipher iv internal error", but that's not the point here, I think)

I found how to force the TLS version on my client (wreq), but since my knowledge of TLS is limited, I wonder: is this because of a buggy server? Since other implementations of tls seems to handle this (curl uses TLS 1.0 without forcing), should this be supported? If so, can I help?

Thanks a lot!

[vincenthz]

a ProtocolVersion error means that your server doesn't understand TLS12 (and by the look of the cipher that it's trying to used, it's probably really crummy). I'm not sure if there's anything to do at this level. One could automatically retry with a downgraded version when getting a ProtocolVersion alert, but that come really close to policy around security, which I would much rather leave to the users..

[madjar]

Thanks for your answer. :)

Can you confirm that I'm reading the rfc correctly?

A TLS 1.2 client who wishes to negotiate with such older servers will
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server does not support this
version, it will respond with a ServerHello containing an older
version number. If the client agrees to use this version, the
negotiation will proceed as appropriate for the negotiated protocol.

A server that receive a TLS12 hello but doesn't support it should response with a TLS10 hello, which this server clearly doesn't. If that automatic downgrade is in the rfc, I understand why one would want to do it manually for bad servers. However, I also understand not wanting to some shady retry logic for some crummy servers.

Anyway, I've got my workaround (manually forcing TLS10), and you do have a point, so we can close this if you want.

[vincenthz]

There's a bunch of unclear stuff from the RFC; namely there's 2 differents versions send by packet, one in the Record Layer, one in the Handshake layer. Typically openssl send the Record Layer to TLS10, but the Handshake to TLS12. tls on the other hand send both to TLS12. It seems that the Record layer version trips the other side in this case, namely it assume that the Record Layer could have changed in TLS12, so it's not able to parse further. It's typically the same with the ClientHello, but most server will try to understand a TLS12 ClientHello packet as a TLS10 ClientHello.

[kazu-yamamoto]

FYI: TLS 1.3 uses the TLS 1.0 value in all record headers to cheat broken intermediate boxes.