Re: [TLS] Server Name Indication (SNI) in an IPv6 world?

[[e-mail]]

On Wed, Oct 27, 2010 at 10:22 AM, Steingruebl, Andy <[e-mail]> wrote:
> Sorry, my point is that preventing DNS rebinding relies on client security in many 
> ways, but to make it happen a server also has to serve content for hostnames it 
> doesn't really serve content for.  With TLS this is hard(er) to make happen 
> because of certificate warnings.  For non-TLS, there aren't any indicators. 
> Servers should be configured to only serve data for their hostnames.  Or, so I'd 
> argue.

In my opinion, all servers should serve https, and any connections to http should be redirected to https on the same hostname and URI.  (Then again, that's what I do on my server.)

Apache can do <NameVirtualHost *:443> with a wildcard certificate.  This allows a wildcard or multi-SAN cert to be used, but it also has a different way it can be applied:

On my server, on the default :443, I put a "You're not supposed to be here" page, and then I do VirtualHosts for the names I want.

This allows me to handle the error at the application level, rather than at the server level (since my server hosts 6 sites across 3 IPs, and the look and feel of error handling is different between the applications).  This application-level verification works well for a certificate-requirement site, so that instead of a generic "handshake failure" message with no troubleshooting information, I can direct users to where they can get a cert.

It is worth noting that my site accepts any name in Host and doesn't use SNI.  It will not give useful access to any application unless the Host matches what it's supposed to, though.

-Kyle H