0

For one particular web site, which we really need to be able to communicate with, we are starting to get the usual SSL handshake error:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

I've already confirmed, however, that this is not an SSLv3 problem. The site is PCI-compliant, so it's using very up-to-date SSL settings. openssl reports the following:

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-SHA256

The only change that has been made recently is to remove a couple of ciphers from their cipher suite; they specifically disabled TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA on the server side.

What I can't figure out, is why Chrome is complaining about this particular protocol version and cipher suite; it seems perfectly fine to me. The site opens with no issues in recent IE (and the IE page info matches what openssl ios reporting) but fails in Chrome and Firefox.

Is there a way to find out what protocol/cipher settings Chrome thinks it got from the server, or why it decided they were invalid?

1 Answer 1

1

Is there a way to find out what protocol/cipher settings Chrome thinks it got from the server

TLS does not work like this. In TLS the client starts the handshake and includes all the ciphers it is willing to accept from the server. If the server does not find any overlap with its own ciphers then it will in the best case notify the client of this particular problem and in the worst case simply close the connection.

In your case you get ERR_SSL_VERSION_OR_CIPHER_MISMATCH, which means that the server does not support any of the ciphers offered by the client. I don't know which ciphers you have configured at the server but SSLLabs shows you which ciphers are offered by Chrome. And ECDHE-RSA-AES128-SHA256 (TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) is not one of these.

It might work with other browsers because these offer different ciphers to the server, i.e IE 11 on Windows 10 supports this specific cipher while Firefox does not support it. Both Chrome and Firefox do offer TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA which were removed from the cipher set of the server and therefore it worked before.

To fix the problem you should configure your server to accept as much as possible secure ciphers. See Recommended configurations at the Mozilla Wiki.

3
  • Thanks! Our real problem is that we need to use .NET to talk to this server, so I guess I need to figure out what ciphers WebClient supports.
    – KutuluMike
    Dec 11, 2015 at 18:56
  • @MikeEdenfield: don't restrict yourself to a single client but use a broad cipher set on the server side. There is no problem (performance, bandwidth...) to allow more ciphers on the server side as long as they are secure. Dec 11, 2015 at 19:17
  • Actually, I probably wasn't clear in the question -- it's not my server, I'm just trying to help them troubleshoot why we suddenly can't connect :) But I did send them the Mozilla Wiki link, hopefully that will help.
    – KutuluMike
    Dec 11, 2015 at 21:43

You must log in to answer this question.

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