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.
It's always been there AFAIK. This is from their current policy document which you must agree to when you start applying for a free certificate:
> Class 1 certificates are limited to client and server
certificates, whereas the later is restricted in its usage for non-commercial purpose only. Subscribers MUST upgrade to Class 2 or higher level for any domain and site of commercial nature
Class 1 is "StartSSL Free", and Class 2 is "StartSSL Verified" which costs $59.90.
You can tie private information, such as your telephone number (for SMS) and various emails to your account that you can associate with alerts on various reminders you set up.
It's bad practice to not use a secure login, because anyone who is sniffing HTTP traffic can see your Uptime Robot username and password in plaintext.
This might not be that bad for this website, but keep in mind how many people use the same email/password for other services, or their email.
