4

I was looking to drop all support for the SSLv3 due to POODLE, but found that there are still some people coming from old browsers for the likes of IE on Windows XP.

How do I detect these SSLv3-only users from within nginx, and redirect them to some helper page with further instructions?

I definitely need no workarounds to keep these users using insecure browsers.

And I'll be especially happy if I could do the same thing to all non-SNI browsers: SSLv3 doesn't come with SNI, so if I could redirect non-SNI browsers, it'll solve SSLv3 problem too.

Community
  • 1
sanmai
  • 521
  • 5
  • 19
  • 2
    IE8 on XP is not a problem. Only IE6. Though I dropped SSLv3 six months ago and have yet to hear a complaint; a newly installed XP system automatically upgrades to IE8 within minutes of being connected to the network, even if it's not genuine. – Michael Hampton Oct 25 '14 at 02:55
  • @MichaelHampton I have practically tried to disable SSLv3, and got an angry report from a user using IE7. AFAIK it has TLS disabled by default, that's the problem. – sanmai Oct 25 '14 at 02:59
  • 2
    On Vista? Tell your angry user to install the last seven years of updates. – Michael Hampton Oct 25 '14 at 03:09
  • @MichaelHampton this is one of the things I'm going to mention on that page I want them to be redirected – sanmai Oct 25 '14 at 03:27
  • 1
    The problem with leaving SSLv3 enabled on the server side is that doing so exposes your TLS users to risk (if they still have SSLv3 available and the other criteria are met), that's what POODLE is all about. – Håkan Lindqvist Oct 25 '14 at 12:08
  • @HåkanLindqvist good point: I still could get cookies stolen even if I redirect; yet apparently [there is a way to eat the cake](http://serverfault.com/questions/637848/how-to-mitigate-poodle-but-keep-sslv3-support-for-old-clients) – sanmai Oct 25 '14 at 15:09
  • @sanmai Yes, you can avoid POODLE that way but then you get the problems of RC4 instead. If you desperately want to accept SSLv3 you end up choosing between bad and worse. – Håkan Lindqvist Oct 25 '14 at 15:18

2 Answers2

4

Putting aside the issue of leaving SSLv3 enabled, you can simply instruct nginx to redirect based on whether the SSLv3 protocol is being used:

if ($ssl_protocol = SSLv3) {
  rewrite ^ /poodle-doodle.html;
}

You can test this from a shell:

$ wget --secure-protocol=SSLv3 -O - $SERVER_URL
# or
$ curl -v -3 $SERVER_URL
plasmid87
  • 1,888
  • 15
  • 17
  • Hum, better make a temporary redirect rather than changing site's content. – Xavier Lucas Oct 25 '14 at 13:01
  • @XavierLucas You could do, but it may introduce an infinite redirect loop without further handling (accessing `/poodle-doodle.html` with SSLv3 may end up redirecting to itself forever). – plasmid87 Oct 25 '14 at 16:28
  • Sure you need to handle it... Changing your site's content based on client connection metadata is bad practice for SEO. – Xavier Lucas Oct 25 '14 at 17:59
  • I seriously doubt any major search engine crawlers are still using SSLv3, especially after the disclosure of POODLE. This is a quick fix to help prevent users on extremely outdated (and fringe) clients. It does not affect non-SSLv3 clients or SEO. – plasmid87 Oct 25 '14 at 21:26
  • SEO in the general term is not only the most famous SEs :), because depending on your business other thirdparty engines can be key points to visibility. You would be surprised of what you find in these thirdparty HTTPS crawlers sometimes... – Xavier Lucas Oct 25 '14 at 22:46
0

I'm no expert with nginx config, but it should be possible to have a setup for a specific host name and additionally a default setup for all other requests. The setup for the name based host will automatically be used with https if the client uses SNI and the hostname given in SNI matches the configuration. In all other cases, that is different hostname, TLS clients without SNI and clients with SSL 3.0 (which does not support SNI) the default setup gets used so that you can serve different information there. This default setup then can do all the warnings you want to issue to older clients.

This way you could also use different certificates, like give all SNI clients a certificate signed with SHA-256 but the others only one signed with SHA-1, because these older clients might not support SHA-256 yet.

Edit: according to the comments from Xavier Lucas it will only use the certificate settings from the default (non-SNI) configuration, but the other settings depend on the Host header. This means no different document root for non-SNI clients.

Steffen Ullrich
  • 12,227
  • 24
  • 37
  • SNI is used at the handshake phasis, not after. So after the handshake is negociated with the server's certificate, the web server will wait for an HTTP request to come in order to choose which server name is addressed and so which server block to choose. – Xavier Lucas Oct 25 '14 at 13:22
  • With SNI the server name is send in the ClientHello, that is the first message inside the SSL handshake. The decision, which configuration section will be used gets done based on the name send here. That's the main idea on why you can have different certificates on the same IP with SNI. Only if no SNI is used or if the name does not match any of the configured names the default configuration will be used. – Steffen Ullrich Oct 25 '14 at 13:24
  • Hum ok after the edit I see what you mean. The sentence *you can serve different information there* was letting me think you would want to redirect visitors from the default vhost (which is impossible in nginx), and it seems you only meant serving different certificates. – Xavier Lucas Oct 25 '14 at 13:41
  • I meant serving different content because you can use a completely different setup, including the document root. And you can also use a different certificate, but don't need to. – Steffen Ullrich Oct 25 '14 at 13:44
  • Then you are mistaken, you can't do that as nginx don't force clients to use the vhost the handshake took place in, nor it will serve different content unless the Host header passed in the HTTP request is different. – Xavier Lucas Oct 25 '14 at 13:58
  • 1
    OK, that's what I did not expect. – Steffen Ullrich Oct 25 '14 at 14:13