Slashdot Mirror
Why Doesn't Every Website Use HTTPS?
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?"
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.
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)
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.
The fact that it can muck up cheap-n-cheerful 'zillion sites on one host' arrangements unless everybody's TLS ducks are in a row probably counts as a fairly significant cost, as well. Especially on the low end.
Also, HTTPS does not play well with proxy caches or load balancing.
Free certs are available, and every bit as (in)secure as the paid standard ssl certs.
http://cert.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
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.
Blessed are the pessimists, for they have made backups.
- 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.
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/
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/
Blessed are the pessimists, for they have made backups.
We use Pound for load balancing which makes requests to the cache servers, works great, very configurable, supports sessions, etc.
neorush
"I'm pretty sure this means you can have more than one webserver/hostname entry, all with the same IP, and use host header names (IIS) or Name-based Virtual Host Support (Apache/others) to determine which site and certificate to connect the user to."
... and you would be incorrect. Name-based Virtual Hosting cannot be done with HTTPS. The reason is that the name of what is being requested is also encrypted in the SSL data. The only way for a web server such as Apache to know what virtual host to use is to look at the name. In order to get the name it would have to SSL decrypt the request. In order to SSL decrypt the request it needs to know what SSL key to use. In order to know what key to use, it would need to look it up in the name-based virtual host record. In order to do that, it needs to know the name... oops.