0

I use one of my website as a test for various TLS techniques. Recently I added OCSP Must-Staple to this domain. After a week I got a complaint from a user they were unable to visit the website. They got the error from Opera, Edge and Chrome. The Chrome error was the clearest: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

After some testing I found out their BitDefender doing SSL intercepting was the culprit. Now, I don't want a discussion about whether companies should be doing such a thing. I presume ERR_SSL_VERSION_OR_CIPHER_MISMATCH is just BitDefender saying: "I am unable to do anything with this, let's just block the user from visiting by negotiating no valid SSL version / ciphers with the browser". But I don't understand how the Must-Staple in the certificate caused this.

Maybe it wasn't actually the Must-Staple, or maybe it was in combination with some other header. I have HPKP headers which would be the next possible candidate, but I have had those for almost a year now. I am not that well versed in VM's and WireShark to do much investigating. Could someone help determine the actual cause to satisfy my curiosity?

SSL labs report

ontrack
  • 186
  • 1
  • 3

2 Answers2

1

First of all, as it is common with TLS errors, ERR_SSL_VERSION_OR_CIPHER_MISMATCH in Chrome is in no way descriptive of a particular problem.

Next, I admit that I have never in my life touched BitDefender and especially its TLS wiretapping techniques with a ten foot pole, nor that I'd ever wanted to.

Having said that, I've seen a similar bug in similar products, so I may happen to give you a clue.

See, when a TLS interceptor sees a certificate, it copies it, replaces the certificate authority data with its own and signs it, and then sends to the browser (or whatever client software is trying to make a secure request). A basic TLS interceptor doesn't do anything else to the certificate: it doesn't, say, change subject alternative name field or mangle any other X509v3 extension value. Only the CA data is changed, the rest of the certificate is left as is.

As the CA data is changed, the subsequent OCSP staple won't obviously be valid, so the interceptor strips that data as well. In fact, it's acting as a proxy, so it doesn't strip anything, it just doesn't put a staple into the browser-facing connection even when it receives a staple from the server-facing connection, and that's it.

Now, the browser receives the certificate, signed by the interceptor, with OCSP Must Staple on it, but doesn't get a valid OCSP staple because it's not sent by the interceptor. At this point, the best your browser is able to do is to halt the TLS connection and display a cryptic error message.

NB: this is one way to break OCSP with a TLS interceptor that I'm aware of. BitDefender could be actually using another method, there are surely plenty of them.

ximaera
  • 3,395
  • 8
  • 23
1

This error occurs when an unsupported SSL/TLS or an unsupported cipher suite is delivered to the browser (f.e. Google Chrome does no longer support SSLv2 and SSLv3 protocols, neither is supported the RC4 cipher)

Server certificate is independent of the cipher suites provided, so PROBABLY this issue is a compatibility problem between the browser supported cipher suites and the BitDefender provided cipher suites.

Mr. E
  • 1,954
  • 9
  • 18
  • That seems unlikely. As the available ciphers did not change between last week and earlier. The ciphers have quite a high coverage with ECDHE, DHE and plain RSA key exchange. I have included an SSL labs report for more information. – ontrack Aug 07 '18 at 07:02
  • Sorry if my answer is missleading, but I tried to point out that the problem is not your server configuration but BitDefender that is serving incompatible ciphers to the web browser. In order to actually intercept the communication between the browser and your server, the browser actually establishes a communnication channel with BitDefender and then BitDefender connects to your web server. Is the first channel that is not working – Mr. E Aug 08 '18 at 21:55