2

We have to connect with our application (written in Java 8) to some very old server using HTTPS. Being Java 8, our client supports TLSv1.2, TLSv1.1, TLSv1 and SSLv3. Of course, it prefers to use TLSv1.2, as it's the newest protocol.

The server (Oracle-HTTP-Server 11.1.1.7), however, only supports TLSv1 and SSLx. Additionally, it has a very limited selection of supported cipher suites, but there is still one suite in common that we can use with TLSv1: SSL_RSA_WITH_3DES_EDE_CBC_SHA (a.k.a. TLS_RSA_WITH_3DES_EDE_CBC_SHA).

However, straightforward connection fails with the server terminating handshake. Debug output we get (on the client side) looks like this:

main, WRITE: TLSv1.2 Handshake, length = 265
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1.2 ALERT:  fatal, close_notify
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLException: Received fatal alert: close_notify

To me, it looks like the server doesn't even try to fall back to TLSv1: as soon as the client declares TLSv1.2 as preferred, the server bails out.

In comparison, when we explicitly disable TLSv1.2 and TLSv1.1 in our client, thus making TLSv1 the preferred option, handshake succeeds.

We also tried to connect to another legacy server that doesn't know about TLSv1.2 and TLSv1.1, but here connection works as expected: even though the client says it prefers TLSv1.2, they agree with the server to use TLSv1, as the best common protocol:

main, WRITE: TLSv1.2 Handshake, length = 269
main, READ: TLSv1 Handshake, length = 85
...

Question: is it the server's duty to choose out of the list of TLS/SSL protocols the client supports? Can I say to the server maintainers that it is the server that misbehaves, not our client?

doublep
  • 123
  • 1
  • 4
  • 3
    To confirm, the behavior you are seeing with the server forcibly closing the TLS 1.2 connection rather than offering the highest version it does support is generally referred to as TLS Intolerance and is more widespread of an issue than you would imagine. There is a great explanation of the issue [here](http://security.stackexchange.com/a/66785) along with an overview of why manual downgrade is considered dangerous [here](http://security.stackexchange.com/a/70993). – Mark Riddell Aug 30 '16 at 11:14
  • Thank you, the links explain the procedure even better and confirm what the answer says. – doublep Aug 30 '16 at 12:06

1 Answers1

4

is it the server's duty to choose out of the list of TLS/SSL protocols the client supports?

The client does not provide a list of supported versions. The client provides the best version it can offer and the server is supposed to reply with the best version supported by the server which is equal or lower to the clients version. If the client then is not willing to accept a too low version the client will throw an error and close the connection.

Can I say to the server maintainers that it is the server that misbehaves, not our client?

I think you can say that. Any server which properly implements TLS 1.0 should be able to deal with a TLS 1.2 connect from the client because the protocol is specifically designed this way. Unfortunately there are still enough broken TLS implementations out there.

Steffen Ullrich
  • 13,227
  • 27
  • 39
  • Thank you, along with the links in the comment by MarkoPolo this makes perfect sense and answers my question. – doublep Aug 30 '16 at 12:03