Kindly Subverting POODLE

Wed 15 October 2014 by feld

Let's pretend for a moment you live in a world where you need to protect your customers from POODLE without completely breaking access for IE6 users. Scary errors or a complete failure to connect to the server are not options. Well then, this blog post is for you!

This solution varies based on where SSL is being terminated. If it's on Apache or Nginx this is easy. If you have a different webserver or hardware load balancers you might have to investigate on your own. You should be able to apply these same techniques. If not, I suggest upgrading your infrastructure to something more modern. :-)

Keep in mind this will likely cause you to fail some audits. However, with proof of your configuration you could contest the failure and (hopefully) win. I wouldn't run this permanently either. Maybe a month or two until your customers get a clue.

Note: In these examples I redirect the end user to Microsoft's Windows XP End of Support page which has a lot of good information, but you might want to redirect the user to a company-branded page with your own message.

Apache:

RewriteCond %{SSL_PROTOCOL} = SSLv3
RewriteRule .* http://windows.microsoft.com/en-us/windows/end-support-help [R=302,L]

Nginx:

if ($ssl_protocol = SSLv3) 
{
  return 302 http://windows.microsoft.com/en-us/windows/end-support-help ;
}

Cisco ACE:

You can't actually do this on the Cisco ACE, but it appears you could tell it to add a header and then you could watch for this header on the backend webservers and do a redirect similar to what we're doing above. I don't know the full syntax for the ACE but digging through the manual I found this gem:

ssl header-insert session Protocol-Version

The Cisco ACE only has the values TLSv1 and SSLv3 for Protocol-Version, so the following should work for Apache:

RewriteCond %{HTTP:Protocol-Version} = SSLv3
RewriteRule .* http://windows.microsoft.com/en-us/windows/end-support-help [R=302,L]

And there you have it. You can inform your customers without sacrificing their security. The worst case scenario is a bad guy sniffs the traffic and captures a redirect. On a side note, this would also be a clever way to detect and inform of an SSL Downgrade attack...

Have fun!

Edit: Make sure you use 302 redirects so they aren't permanently cached by clients...