Dedicates IP's aren't required for SSL certs anymore unless you're concerned with old IE's in Enterprise environments. Every modern piece of browser software will send the domain with the TLS handshake. Doesn't look like these guys are targeting the entrenched enterprise, though.
Windows XP is still running on about 1 in 5 computers in the US. Internet Explorer is still the first or second-most used browser depending on whose market share methodology you prefer. SNI does not work with any version of IE on WinXP. SNI also doesn't work with Safari on XP, Android 2.x browser, BlackBerry browser, Opera Mobile, etc. No major sites use SNI and it's not because they have enterprise audiences. The compatibility isn't there yet -- if you're using SNI, you're throwing up errors on the screens of 10% or more of your visitors -- desktop, laptop, home, "enterprise", and mobile alike.
Giving error messages to people using IE on XP is probably a good thing. Web browsers need security updates, and they're about to be left out, in addition to facing rendering problems.
But even when you want to let people connect without SNI, there is no reason to skimp on security. How about sending people with bad browsers to a different port per site?
> How about sending people with bad browsers to a different port per site?
You can't do that for the very reason SNI exists. All you've got is the beginning of an SSL handshake on your single IP; you don't know what host they want yet, so you neither know what port to redirect to nor what certificate to serve.
The topic here is how the signup form is submitted. We're talking about starting with an http connection, so the server very much knows what port to redirect to.
And even if they bookmark the https, it keeps working.
And if they have something like 'https everywhere', then they're not using an obsolete version of IE.
The only failure point is if they click an https link by a third party.
The topic here is how the signup form is submitted.
Which protocol the form is submitted via is only half the security issue. The form itself needs to be served over https also to avoid a MITM attack on the destination of the form submission.
In theory if you're browsing a site over HTTP, the initial request to the form will be HTTP, and then you'll be 301'd to the secure signup form. A check could happen before the 301 is issued (instead displaying a warning message). That may not be how it is done on any given site, but my point is that it is possible to handle gracefully.
But yes, clicking an https link directly would cause issues.
