3

I'm having error ERR_SSL_PROTOCOL_ERROR since 2 day on my website for some reason.

Browsers tested

  • Windows Chrome 117.0.5938.132 : ERR_SSL_PROTOCOL_ERROR
  • Android Chrome 117.0.5938.61 : ERR_SSL_PROTOCOL_ERROR
  • Windows Firefox 118.0.1 : Ok
  • Edge 117.0.2045.47 : Ok
  • Don't have other browsers on hand but customers only complained about Chrome yet

Web server configuration

Yes my webserver is outdated, planning to migrate but in a few months.

  • Certificate is valid (Sectigo)
  • Apache HTTPd 2.4.3
  • OpenSSL 1.0.1m

The website that doesn't work is https://specto.ca

Apache HTTPd configuration original

Configuration before my tests

[...]
<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin

    SSLStrictSNIVHostCheck off
</IfModule>
[...]
<VirtualHost 69.70.187.100:443>
    [...]
    ServerAlias specto.ca
    ServerAlias www.specto.ca
    [...]
    SSLEngine on
    SSLCertificateFile /home/.../ssl.crt
    SSLCertificateKeyFile /home/.../ssl.key
    SSLCACertificateFile /home/.../chain.crt
</VirtualHost>

Apache HTTPd configuration running

Configuration after my tests

[...]
<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin

    SSLStrictSNIVHostCheck on

    SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
    SSLCipherSuite          ECDHE-RSA-WITH-AES-128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4
    SSLHonorCipherOrder     off
</IfModule>
[...]
<VirtualHost 69.70.187.100:443>
    [...]
    ServerAlias specto.ca
    ServerAlias www.specto.ca
    [...]
    SSLEngine on
    SSLCertificateFile /home/.../ssl.crt
    SSLCertificateKeyFile /home/.../ssl.key
    SSLCACertificateFile /home/.../chain.crt
</VirtualHost>

Both configuration have the same issue, I was just assuming negociation was trying on TLS v1.1 and that was the rejection reason.

I've run a test on Qualys SSL Labs, only huge complain I see is This server supports weak Diffie-Hellman (DH) key exchange parameters. Grade capped to B. which I'm not sure what to do about, and not sure it's the culprit.

Improve this question
4
  • Where did you source Apache from? Exactly which version is it? What do your logs say?
    – symcbean
    Oct 1 at 23:46
  • @symcbean Apache is comming from original package of Slackware64 14.0, there are no error in the log files.
    – Alexandre Lavoie
    Oct 2 at 0:24
  • 1
    I just want to add my contribution to this thread, f**k you Google.
    – Lawrence
    Oct 3 at 18:46
  • 1
    google managed it terribly, they could have added a soft warning before blocking entirely all the servers that run openSSL with that old version
    – Andrea Mauro
    Oct 5 at 8:58

6 Answers 6

Reset to default
6

If you just started seeing this, this may be due to SHA-1 server signatures no longer being supported. This isn't the signature in the certificate, generated by the CA, but a signature that is made during the TLS 1.2 handshake, generated by your server software. (See Chrome Status and RFC 9155 for details.)

If toggling chrome://flags/#use-sha1-server-handshakes to "Enabled" (instead of "Default" or "Disabled") makes the issue go away, that is likely the cause.

Usually this is a bug with the TLS server software rather than a configuration issue, as TLS 1.2 has supported SHA-2 from day one and very few people change their signature algorithm preferences from the default.

The most common issue we've seen is that very old versions of OpenSSL had some bugs which causes it to mess up its internal state as part of the SNI negotiation and forget which signature algorithm it was signing. It then ends up picking SHA-1 even though both client and server would prefer SHA-2. Although all versions of OpenSSL with the bug have long been end-of-life, a few servers are still running it.

In that case, the fix is you should update your OpenSSL to a more recent version. I believe 1.0.2m is the minimum version with the bug fixed but, of course, updating to a supported version is recommended. (The 1.0.2 series went end-of-life in 2019.) If you get your OpenSSL from your Linux distribution, updating that is probably the easiest option.

Hope that helps!

Improve this answer
1
3

My Chrome/Windows is (now!) the same version and reproduces; the only thing that looks likely to me in wireshark is that after correctly negotiating 1.2 (Chrome offers 1.3 but accepts 1.2) the server signs ServerKX with (RSAv1.5+)SHA1, and Chrome sends alert47 illegal_parameter. SHA1 protocol signatures are prohibited in 1.3, but only deprecated in 1.2 the last I heard (rfc9155).

And sure enough, in chrome://flags is a top-of-list (recent) entry for #use-sha1-server-handshakes; if I Enable that and relaunch your site now works. (Of course the fact this is now a flag means it likely will be removed entirely before very long.)

You're right that old-style DHE aka FFDHE parameters are not the problem here, because Chrome prefers, and thus the server selects, (a suite containing) ECDHE (with P-256) and not FFDHE. It would probably be good to fix them if you think it is likely anyone will be accessing your website with a browser or other client that doesn't support (and prefer) ECDHE. If not, you could make SSLLabs happier by removing all (FF)DHE suites by adding !DH to your SSLCipherSuite. OTOH you could remove !eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4 -- except for PSK, which can never be selected in Apache, none of them were added so there is no need to remove them. (To make SSLLabs fully happy you must drop all non-AEAD suites, which in practice means non-GCM, but that blocks a rather larger subset of potential clients; whether to make that tradeoff is up to you.)

Improve this answer
1
  • Looks like your #use-sha1-server-handshakes is correcting temporary the issue, same for other websites on my web server (all in SNI). For some reason, I've been able to make specto.ca work again just by pulling it in top of all VirtualServers in httpd.conf. About the SSLCipherSuite, I'm not sure I understand correcly which combination you want me to try, can you put example of the full line please?
    – Alexandre Lavoie
    Oct 2 at 0:37
3

Google has started to roll out an update that rejects SHA1 server signatures in the negotiation process, even if your certificate uses a SHA256 signature.

See https://groups.google.com/a/chromium.org/g/blink-dev/c/ZdpqIOKTHeM

Indeed the temporary solution is to set the flag #use-sha1-server-handshakes at the client side to Enabled to get it working. But the final solution is to make sure the server you are having the problem with is using an upgraded version of the OpenSSL library that use SHA256 signatures instead of SHA1 ones.

Improve this answer
1

dave_thompson_085 put me on the right track. Knowing it was a negociation issue, it looked more like a limitation of my software versions.

Fortunatly, I've been able to upgrade to Apache HTTPd 2.4.57 and OpenSSL 1.0.1u. Now all websites are loading properly.

Improve this answer
2
  • What was your previous OpenSSL version?
    – Lawrence
    Oct 3 at 18:47
  • 1
    @Lawrence it is in the original question : 1.0.1m.
    – Alexandre Lavoie
    Oct 3 at 19:06
1

(Solved) I had the same issue. I upgraded the openssl from 1.0.1 to 1.1.1w.

Then restarted nginx (maybe not necessary).

It fixed the issue

Upgrading guide

Improve this answer
0

Google has started to roll out an update that rejects SHA1 server signatures in the negotiation process, even if your certificate uses a SHA256 signature.

Improve this answer

You must log in to answer this question.

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