3

G'Day,

We're looking to use SNI to host SSL websites on a cloud based single IP solution. Can .net figure out if a client is SNI capable before the TLS handshake and over HTTP?

timmah.faase
  • 2,219
  • 1
  • 15
  • 23

2 Answers2

0

It's not clear what you mean by "before the TLS handshake".

The Server Name extension is in the Client Hello message, which is the very first TLS message sent by the client to initiate the handshake. Since HTTPS also always starts with establishing the TLS connection first, there's nothing happening before at all. Knowing whether the client is SNI capable before the handshake the way is simply impossible.

You might be able to sort something out on the client side, using JavaScript to try to detect SNI support.

This being said, it's unlikely to solve your general problem: if you have a fallback/wildcard certificate when SNI isn't supported, there's little point in having other specific certificates (besides the fact widlcard certificates are not recommended); if you expect SNI, you'll block out clients that don't support it.

Community
  • 1
  • 1
Bruno
  • 119,590
  • 31
  • 270
  • 376
  • The JavaScript solution you linked too looks kind of interesting. You could probably have a "browser capabilities" detection page that the user lands on initially, then is redirected to an appropriate domain for their browser. I am not sure how well that would work if the site had a lot of entry points, but interesting concept none-the-less. – dana Nov 26 '12 at 20:41
  • @dana - we've solved the problem by using the user-agent header in asp.net and comparing it with a list of compatible browsers. – timmah.faase Nov 26 '12 at 23:53
  • @dana, that JS trick can be useful for making browser stats or to have a nice message to the user before they go to the site. However, this is won't make the site support SNI. If your site is both accessible with and with SNI, SNI support isn't required. timmah.faase, since the user-agent header is only accessible after a successful handshake, it's not clear how that solves your own problem. – Bruno Nov 27 '12 at 10:06
  • Because the session with the client always starts over HTTP. – timmah.faase Nov 28 '12 at 08:39
  • @timmah.faase. Still, if the client doesn't support SNI, you're not going to be able to serve the site on the same IP address/port with a different cert from other sites, so you'll need a fallback solution (e.g. multi-SAN, wildcard cert or other IP address), which would make the SNI solution redundant. – Bruno Nov 28 '12 at 09:59
  • Yes we can and here is how: Step 1, connect over HTTP (customer shops on store). Step 2 (over HTTP), check the user agent and confirm if SNI is capable. Step 3, depending what capability, redirect to SNI capable or Wildcard SSL bound to the same website on the same IP. It works a charm in IIS8. – timmah.faase Nov 28 '12 at 21:01
  • @timmah.faase. Sure, but if you have a wildcard cert anyway, there's no real need for SNI. You might as well send everyone to the wildcard cert. (What really matters is that the user need to expect the address they're sent to. It's up to them to verify it's your site they're connected to: be clear on your addresses.) – Bruno Nov 28 '12 at 21:04
  • Not fair on the customer when they've purchased the certificate and we're moving their hosting, sorry if that wasn't clear in the question. Here's my question on serverfault: http://serverfault.com/questions/450732/azure-vm-with-many-ips-or-ssl-certificates – timmah.faase Nov 28 '12 at 21:24
0

If you look at wikipedia it lists the following as SNI compatible.

  • Internet Explorer 7 or later, on Windows Vista or higher. Not in any Internet Explorer version on Windows XP because SNI depends upon the SChannel system component shipped with Windows Vista.
  • Mozilla Firefox 2.0 or later
  • Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled)
  • Opera Mobile at least version 10.1 beta on Android
  • Google Chrome (Vista or higher. XP on Chrome 6 or newer.
  • OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
  • Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
  • Konqueror/KDE 4.7 or later
  • MobileSafari in Apple iOS 4.0 or later
  • Android default browser on Honeycomb (v3.x) or newer
  • BlackBerry 10 and BlackBerry Tablet OS default browser
  • Windows Phone 7 or later
  • MicroB on Maemo
  • Odyssey on MorphOS

So if you start the connection in HTTP then you can check the useragent and detect if the client supports SNI and if they do redirect them to HTTPS if not keep them on HTTP.

In our case the only web browser that we care about that ain't SNI compatible is IE on XP...

Peter
  • 37,042
  • 39
  • 142
  • 198