Why Doesn't Every Website Use HTTPS? 665
suraj.sun writes "HTTPS is more secure, so why isn't the Web using it? You wouldn't write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection that's essentially what you're doing. There is a better way, the secure version of HTTP — HTTPS. But if HTTPS is more secure, why doesn't the entire Web use it?"
Haven’t we been here before? (Score:4, Informative)
I’m no HTML technician, however I would assume it requires significantly more processing power. Your personal blog or website with 10 hits a day sure, run it over https and you probably wouldn’t notice much difference (aside from the cost of your own unique IP address). A large scale site however would probably have more hardware and bandwidth requirements to implement https on everything.
And I don’t think it’s laziness. A lot of sites will do the login and purchasing bits over https, and have the rest of the site regular old http. It’s probably more effort to do this kind of mixed environment than just make the whole damn thing over https. The only reason for this that I can see is if there was a significant cost associated with encrypting everything un-necessarily.
Cost (Score:2, Informative)
Certificate costs -- you need a valid signed certificate to avoid mim attacks. There's more computational overhead too, and say goodbyte to virtual hosts (ipv4 addresses don't grow on trees)
Re:Holy fuck! (Score:5, Informative)
Facebook and twitter don't have secure logins?!
That's one more reason for me to never sign up with them.
They have secure logins, just not secure sessions after you've logged in.
Re:Haven’t we been here before? (Score:2, Informative)
Most websites are virtual hosts on a single server. SSL does not support more than one certificate per IP address/port.
Re:Correct (Score:5, Informative)
Re:Correct (Score:5, Informative)
Also, HTTPS does not play well with proxy caches or load balancing.
Re:Certificate? (Score:5, Informative)
Free certs are available, and every bit as (in)secure as the paid standard ssl certs.
http://cert.startcom.org/ [startcom.org]
The "annoying users when they expire" is a symptom of the main problem.
Well, actually it's 2 problems.
For small hosters, IE(any version) on XP doesn't support SSL/TLS on virtual hosts. Everybody else does. http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
For large hosters, SSL key distribution and updates becomes a problem when using large server farms or CDNs. Doing SSL in hardware on load balancers solves this for server farms, while CDNs are a more difficult problem.
Those are the main reasons. Latency and CPU usage are not deal-breakers today, though they are a factor.
Re:Haven’t we been here before? (Score:4, Informative)
Re:Haven’t we been here before? (Score:4, Informative)
1) Isn't SSL done on a per domain name basis?
"HTTPS" is more or less setting up a SSL link and running plain ole HTTP over that secure link.
No the SSL encryption layer is done before the HTTP layer does it's thing. So if you identify your vhost as part of the HTTP header, then you're not going to know your vhost name until after the SSL is already set up and working, classic chicken and egg problem.
HTTPS/SSL a good argument for going ipv6 where there is no particular shortage of ip space.
Other than the performance thing... (Score:4, Informative)
- For HTTPS to work seamlessly it requires a certificate signed by a trusted 3rd party, which usually (but not always) costs money. This would disadvantage smaller websites/businesses.
- HTTPS also (currently) requires a separate IP address per certificate. This would mean the current practice of hosting large numbers of domains on one IP using name-based virtual hosting would not be viable, which is something the shared hosting industry really relies on. IP addresses are also a very limited resource at the moment.
- HTTPS cannot be cached between the user's browser and the server. Even the user's browser uses more conservative caching which will further reduce performance.
Re:Haven’t we been here before? (Score:5, Informative)
Isn't SSL done on a per domain name basis?
No. But yes. Well, probably not quite yet.
No: The way HTTPS works when the "recent" SNI feature is not available is that the TLS stream is created (including certificates being negotiated and verified) before any hostname information is transferred. This means that you can only have one valid certificate per publicly addressable IP address without SNI.
But yes: With SNI (see http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] for info) the hostname is sent earlier, so the server can lookup the right certificate for that name and send it instead of relying on a 1-to-1 mapping between IP addresses and service names.
Well, probably not quite yet: Unfortunately SNI is not completely supported by all common user agents, particularly any version of Internet Explorer running on Windows XP, so whether you can justify using the feature right now depends a lot on who your target audience are. If you don't have any users browsing your content/app with XP+IE or you don't mind telling such users to upgrade to FF/Chrome/other, upgrade Windows, or just put up with the certificate warnings, then using SNI will work for you. You run the risk of sending XP+IE users away though, which might not be acceptable if your bottom line relies on getting as much traffic as possible through your doors.
Re:Certificate? (Score:5, Informative)
The certs from StartCom are whatever you generate for them to sign. Last year they accepted 1024 bit RSA and 2048 bit RSA. LIke the rest of the SSL vendors, in 2011 only 2048 bit RSA certs are allowed for issuance, and full transition to 2048 only certs by 2013.
Secondly, the 128 or 256 bit symmetric crypto has nothing to do with the SSL cert or provider, that's software settings on the host. 128 bit AES is widely considered secure against attacks for the next 20 years or so, and 256 bit should be secure for the as far into the future as we can guess. http://www.keylength.com/ [keylength.com]
The (in)security I refer to has to do with the level of checking into who you are. Basically, they just send an email to administrator type address at the site you want a cert for, and if you get the email you are assumed to be the admin. This can be attacked easily through DNS flaws or just signing up for a webmail account with an address that the SSL provider thinks sounds like an admin account. This happened to many of the large webmail providers before they started blocking the common admin accounts for registration.
XKCD was right. The common attacks are against the humans who run your DNS or mail providers, not that the crypto is weak.
http://xkcd.com/538/ [xkcd.com]
Re:Haven’t we been here before? (Score:5, Informative)
You cannot depend on the user's IP address not changing. Besides offering only some additional security (most people subject to having their session sniffed are using the same public WiFi as the user - so they'll actually have the same IP address), more importantly, some users have load-balanced outbound Internet access.
On our own network, we see legitimate single sessions bridging multiple A-class networks. Page request to page request they will have an IP address from a wholly different ISP, which can even geolocate to wildly different locations. Admittedly that's the exception rather than the rule, but it's also becoming more common - especially for people on mobile networks, whose IP address is subject to whichever cell tower is giving them the strongest signal right now. Users sitting relatively equidistant from multiple towers can flip between various IP's rather frequently.
The only things you can reliably depend on not changing in the user's request (for legitimate users) are also all spoofable by illegitimate users. For example, you can depend on a cookie not changing unless you told it to change, but it can be spoofed; you can depend on the user agent not changing, but it can be spoofed, and so forth.
There is no way to make an unspoofable session cookie; you can only prevent interception by using a secure standard such as SSL.
Re:Haven’t we been here before? (Score:4, Informative)
It's called SNI (Server Name Indication), it's part of the SSL standard, and has been supported in Apache since 2.2.12. The virtual host name is submitted as part of the TLS negotiations so the server knows which certificate to use.
Re:Correct (Score:5, Informative)
Re:Haven’t we been here before? (Score:4, Informative)
Actually no version of IE (that means 6, 7 or 8 or Safari) on Windows XP supports SNI. :-(
They use the system library, it does not use SNI.
Re:Correct (Score:5, Informative)