Welcome to End Point’s blog

Ongoing observations by End Point people

Rejecting SSLv2 politely or brusquely

Once upon a time there were still people using browsers that only supported SSLv2. It's been a long time since those browsers were current, but when running an ecommerce site you typically want to support as many users as you possibly can, so you support old stuff much longer than most people still need it.

At least 4 years ago, people began to discuss disabling SSLv2 entirely due to fundamental security flaws. See the Debian and GnuTLS discussions, and this blog post about PCI's stance on SSLv2, for example.

To politely alert people using those older browsers, yet still refusing to transport confidential information over the insecure SSLv2 and with ciphers weaker than 128 bits, we used an Apache configuration such as this:

# Require SSLv3 or TLSv1 with at least 128-bit cipher
<Directory "/">
    # Make an exception for the error document itself
    SSLRequire (%{SSL_PROTOCOL} != "SSLv2" and %{SSL_CIPHER_USEKEYSIZE} >= 128) or %{REQUEST_URI} =~ m:^/errors/:
    ErrorDocument 403 /errors/403-weak-ssl.html

That accepts their SSLv2 connection, but displays an error page explaining the problem and suggesting some links to free modern browsers they can upgrade to in order to use the secure part of the website in question.

Recently we've decided to drop that extra fuss and block SSLv2 entirely with Apache configuration such as this:

SSLProtocol all -SSLv2

The downside of that is that the SSL connection won't be allowed at all, and the browser doesn't give any indication of why or what the user should do. They would simply stare at a blank screen and presumably go away frustrated. Because of that we long considered the more polite handling shown above to be superior.

But recently, after having completely disabled SSLv2 on several sites we manage, we have gotten zero complaints from customers. Doing this also makes PCI and other security audits much simpler because SSLv2 and weak ciphers are simply not allowed at all and don't raise audit warnings.

So at long last I think we can consider SSLv2 dead, at least in our corner of the Internet!


Anonymous said...

Hi Jon,

This pots is great I was looking for something like that for sometime.
I am trying to implement this solution, but I get an error:
You don't have permission to access / on this server.

Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.


Apache/2.2.3 (CentOS) Server at Port 443

Jon Jensen said...

Did you create the /errors/403-weak-ssl.html file? That's what page the Apache recipe above is trying to serve, so if it doesn't exist or isn't readable, you'll get an error.

You should be able to fetch the page directly to check.

Anonymous said...

Hi Jon,

Thank you for your reply.
I did create the /error/ folder I even chanbed ownership to apache but for some reason it redirects to the built in error message on /var/www/error/noindex.html.

This is how I have my virtual host, it should work:

DocumentRoot "/var/www/secure/"
ErrorLog logs/secure01-error_log
CustomLog logs/ common
SSLEngine on

# Make an exception for the error document itself
SSLRequire (%{SSL_PROTOCOL} != "SSLv2" and %{SSL_CIPHER_USEKEYSIZE} >= 128) or %{REQUEST_URI} =~ m:^/errors/:
ErrorDocument 403 /errors/403-weak-ssl.html

SSLCertificateFile /etc/httpd/conf/certs/server.crt
SSLCertificateKeyFile /etc/httpd/conf/certs/server.key

For some reason Apache thinks there is no Index file when I use an older browser and redirects me for the noindex page.

What Apache version and OS are you using?

Thank you very much

Jon Jensen said...

I was using RHEL 5 with Red Hat's Apache httpd-2.2.3-31.el5_4.2.