no-default to protect ssl 443

[ctessmer]

First. Thank you to all the contributors. My config is better (and existent!) because of you.

Question. Would the no-default config be better if it also protected against header attacks for port 443 as well? I remember seeing a way to listen to both 80 and 443 in one statement, but can't remember the syntax.

[jamesonjlee]

not a bad idea?

[StephenBrown2]

It's possible, using multiple 'listen' statements in the server block, as described here: http://nginx.org/en/docs/http/configuring_https_servers.html#single_http_https_server

However, one would need a legitimate SSL cert, I would think, to be able to serve the error? The SSL handshake comes first, so I don't think it would even be possible to redirect to port 80 and then show an error. However, my knowledge in this are is probably lacking. The idea itself is a good one, though, I'll certainly vote for that.

[AD7six]

@ctessmer You're welcome =).

However until SNI support can be taken for granted, that's not a good idea. Any client without SNI would always hit the no-default server that way. See #33 for some further background.

I'm not sure of the best practice to defend against header attacks over https whilst accounting for no-SNI - You might need to account for that at the application level (host name not example.com? redirect to example.com/$request_uri).

@StephenBrown2 if there was not a legitimate ssl certificate, nginx wouldn't allow any connections over https, it would just flat out fail; more importantly though, there would be nothing to exploit making the point/purpose of this issue moot. You are right that you can't redirect from https to http without there being a server listening on https.

[ctessmer]

You guys rule. Great insights. Thanks for jumping in on this.

@AD7six I thought SNI was a server thing and not a client thing? So it sounds like perhaps older browsers won't be able to hang with my SNI enabled nginx box? I might start ending all my questions with a question mark? :)

[AD7six]

@ctessmer just as a browser can't connect to a server if there is no webserver (nginx) running on it, clients can't use SNI if it's not implemented on the server. Nginx has has SNI support for a long time.

However the point is that there are still some "common" clients that don't support SNI such as android 2.x, and unlike browser-compatibility issues where using an old browser might deteriorate the interface, relying on SNI when it's not possible simply cuts the user off with no means to access the website.

[ctessmer]

@AD7six Ahh. Ok. Thx for that. And my apologies in advanced ~12% of Android users.

[StephenBrown2]

@AD7six I meant as opposed to a self-signed cert, which would cause a browser error regardless. Still, SNI is definitely awesome, and the way of the future.