Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Why Doesn't Every Website Use HTTPS?

CmdrTaco posted about 3 years ago | from the asked-that-more-than-once dept.

Networking 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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Haven’t we been here before? (4, Informative)

Anrego (830717) | about 3 years ago | (#35558566)

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.

Correct (2)

GameboyRMH (1153867) | about 3 years ago | (#35558664)

Yep, the one-line answer is:

It's too CPU-intensive for the server.

Cost could be an issue but it's like $100 a year? Hardly a problem for anything but the most amateur of blogs.

Re:Correct (5, Informative)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#35558746)

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.

Re:Haven’t we been here before? (4, Insightful)

SCHecklerX (229973) | about 3 years ago | (#35558684)

If you are going to switch back over to http, you might as well not bother in the first place. HTTP, being stateless, one need only sniff that session ID, and they are now in. That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me.

Re:Haven’t we been here before? (4, Insightful)

EasyTarget (43516) | about 3 years ago | (#35558808)

"That so-called webmasters think they are guarding access by only encrypting/authenticating the login amuses me."

..which is why you need to let real webmasters get on with it and not try it yourself. We are protecting -something-; it's your loss if you cannot work out what that is.

Re:Haven’t we been here before? (1)

Anrego (830717) | about 3 years ago | (#35558836)

I would assume in cases like this, they set the SSL bit in the cookie and do whatever web voodoo is necessary such that the cookie gets sent over ssl.

Then again, I've seen some pretty boneheaded stuff security wise on the web... maybe they don't!

Re:Haven’t we been here before? (5, Interesting)

fuzzyfuzzyfungus (1223518) | about 3 years ago | (#35558848)

I suspect that some are merely clueless, and some are mostly concerned with preventing persistent "lockout" type attacks at the lowest possible cost. You'll notice, for instance, that most sites that authenticate over HTTPS, then drop back to HTTP, go back to HTTPS and demand the original password if you try to do things like change the password(and possibly certain other operations considered sensitive), even if you have the session ID.

Obviously, that does nothing to prevent assorted public-wifi hilarity; but it makes it comparatively difficult(difficult enough that social engineering or just guessing that the password is 'password123' because they always are is easier) to permanently compromise the account and generate a customer support/being flagged as a spam host cost problem.

Webmasters who think that this is actually good security are fools. Webmasters who think that it blocks a certain class of especially costly attacks, while being much cheaper than full HTTPS, are entirely correct. And, given how little one pays for access to many sites that do this, they probably don't care too much unless something attracts mainstream attention *cough*firesheep*cough*...

Re:Haven’t we been here before? (4, Informative)

Zorpheus (857617) | about 3 years ago | (#35558924)

The use of encrypting the login is that the passwords are save from being sniffed. Too many people use the same password for multiple sites.

Re:Haven’t we been here before? (1)

mariushm (1022195) | about 3 years ago | (#35558706)

This. Lots of page accesses = lots of processing power spent on encryption and decryption. Not everyone can afford hardware cards to do the encryption.

Second, proper certificates costs money, and you "kind of" need one static IP for each website - it's a big hard for a person to justify the need for one IP for each of his 10 blogs - most companies will only issue a block of 8 IPs (5 usable) to a single server.

Re:Haven’t we been here before? (2, Informative)

Anonymous Coward | about 3 years ago | (#35558730)

Most websites are virtual hosts on a single server. SSL does not support more than one certificate per IP address/port.

Re:Haven’t we been here before? (1)

Malc (1751) | about 3 years ago | (#35558834)

1) Isn't SSL done on a per domain name basis?
2) Can't virtual hosts be NATed or something and each domain given it's own private IP address?

Re:Haven’t we been here before? (1)

Malc (1751) | about 3 years ago | (#35558886)

Don't even bother responding... I'm being dense today. I can see why that won't work.

Re:Haven’t we been here before? (1)

Anrego (830717) | about 3 years ago | (#35558896)

Not really and not really.

The problem is, domain information is sent over as part of the _decrypted_ http data (the host header). In other words, you don't know what domain name was used until after it is decrypted. As such, you can't use that information to decide which key to use in the decryption process. The only thing you have to key off on is the IP address, ergo why it has to be unique.

The exception to this is to send the host info in plaintext first so the server can identify which cert to use... but this is of course not supported by all browsers and no one would want to depend on it for their business.

Re:Haven’t we been here before? (3, Informative)

vlm (69642) | about 3 years ago | (#35558954)

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.

Re:Haven’t we been here before? (1)

Toe, The (545098) | about 3 years ago | (#35558736)

It used to be noticeably slower to access a site via https than by http, even accessing the same page.

However, now we have server processors which operate in the GHz, and which run in multiples. Heck, we have that even for tiny home PCs and now phones. Servers are apt to be instances on clusters or clouds these days. So I don' think there is a major penalty for using https.

If your traffic is huge enough that you will notice the hit: then you really should be using https anyway. If you're serving that kind of audience, perhaps you owe it to them to provide a bit of protection.

Re:Haven’t we been here before? (1)

skids (119237) | about 3 years ago | (#35558762)

The article goes into this a bit. While crypto processing requirements are a small factor, the big deal really is the share-the-same-ip browser-reliant virtual hosting that people decided to use even though it was a crummy hack to start with. The Internet totally relies on it at this point. If you try SSL to such a site, there's no way for the server to choose the correct SSL certificate for the virtual host you are trying to reach -- because that information is not transmitted until the HTTP session is started, which with SSL happens encrypted, after the cert exchange.

Re:Haven’t we been here before? (0)

Anonymous Coward | about 3 years ago | (#35558826)

"I’m no HTML technician, however I would assume it requires significantly more processing power. "

Nope. Well not a significant amount assuming appropriate tuning:

"In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware."

The biggest issue to do with the deployment of SSL is simply certificates. We need a better model than trusted root certs.

Re:Haven’t we been here before? (1, Insightful)

stonecypher (118140) | about 3 years ago | (#35558844)

Except the sites that offer HTTPS are the highest traffic sites on the web: facebook, gmail, twitter.

You are dead wrong.

Holy fuck! (0)

Conspiracy_Of_Doves (236787) | about 3 years ago | (#35558574)

Facebook and twitter don't have secure logins?!

That's one more reason for me to never sign up with them.

Re:Holy fuck! (4, Informative)

WrongSizeGlass (838941) | about 3 years ago | (#35558600)

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:Holy fuck! (1)

somersault (912633) | about 3 years ago | (#35558646)

I just always visit https://www.facebook.com [facebook.com]. Seems to work. There is also a setting I noticed that says something like "use secure sessions wherever possible", which perhaps redirects you to the https site even if you click on an http link. I haven't tested it though, I'm happy using https all the time so that people can't steal my session cookie or whatever.

Re:Holy fuck! (2)

realityimpaired (1668397) | about 3 years ago | (#35558652)

Dunno about Twitter, I'll never use the site. But Facebook does support full HTTPS connections, and there's an option in your profile to force Facebook to use https on every connection on your account.

Re:Holy fuck! (0)

Anonymous Coward | about 3 years ago | (#35558670)

Facebook has it since end of January this year.
(before that it was possible unofficially, but chat was disabled)

Re:Holy fuck! (2)

Mascot (120795) | about 3 years ago | (#35558724)

They have secure logins, just not secure sessions after you've logged in.

Facebook fairly recently added an option to always use https.

Twitter announced a few days ago that it was adding the same option. No idea if they've implemented it or just announced it though.

Re:Holy fuck! (1)

postbigbang (761081) | about 3 years ago | (#35558788)

Facebook has full https control (they had partial, but some APIs didn't work, they do now) and Twitter works with https as well.

Using https seems to be becoming default, rather than an option, and yes, it does requires more muscular hardware and yes, it uses up session sockets. Ultimately, it's what we'll use until it too, gets cracked.

Re:Holy fuck! (1)

bfields (66644) | about 3 years ago | (#35558868)

They have secure logins, just not secure sessions after you've logged in.

And that's an important distinction. It means someone can sniff your credentials for the *session*, and impersonate you as long as you're logged in; but if you detect the mischief, then you can regain control, because your real long-lived credential (your password) is sent under ssl.

It's a tradeoff, but for something non-critical it seem to me like a reasonable one.

Re:Holy fuck! (0)

Anonymous Coward | about 3 years ago | (#35558704)

do you really believe that facebook is so lame about security?

from their home page source it can be seen that they send your password securely:

form method="POST" action="https://www.facebook.com/login.php?login_attempt=1" id="login_form" ...

the plaintext cookies are another issue :)

Re:Holy fuck! (0)

Anonymous Coward | about 3 years ago | (#35558918)

Except that action URL can be intercepted and re-written to something like action="http://www.goatse.cx/....". I believe it was Tunisia was caught doing something like this already.

Certificate? (3, Interesting)

Lord Lode (1290856) | about 3 years ago | (#35558592)

Maybe because it requires certificates that cost money and annoy users when they expire?

Re:Certificate? (0)

MikeDirnt69 (1105185) | about 3 years ago | (#35558678)


Re:Certificate? (1)

TWX (665546) | about 3 years ago | (#35558820)

That's why I never got on the https bandwagon. I couldn't self-sign without generating error messages in the browser, and none of the content that I served at the time had any need to be secure. It was self-publishing, for crissake, effectively vanity publishing.

Come to think of it, so is everything on facebook, twitter, and most other websites, including this one. I guess it's not really important for almost anyone.

I have an idea- if you need something to be secure, don't use HTML or HTTP at all. Use a real protocol, one designed for security, and don't use a web browser.

Re:Certificate? (5, Informative)

spinkham (56603) | about 3 years ago | (#35558796)

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.

And because IPv4 addresses are scarce (1)

tepples (727027) | about 3 years ago | (#35558810)

There are reportedly free certificates through StartCom [startssl.com], but how does the server know which certificate to present to the client? The HTTP Host: header doesn't show up until after the connection has already been established. There is SNI [wikipedia.org], but a lot of deployed clients still don't support SNI; they need a distinct IPv4 address and port per server. End users expect all hosts to run on port 443, and we've run out of IPv4 addresses.

Re:Certificate? (1)

chemicaldave (1776600) | about 3 years ago | (#35558858)

Certainly it's not feasible for small sites, but it really shouldn't be an issue for enormous, revenue generating websites, i.e. Facebook. Why they don't default to https boggles my mind. There must be a good explanation, but I haven't heard it.

Cost (1, Informative)

isorox (205688) | about 3 years ago | (#35558598)

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:Cost (1)

kju (327) | about 3 years ago | (#35558732)

Nowadays "real" certificates are not expensive anymore. Certificates from "Comodo" were in the past offered for as little as USD 5 per year. Currently they can be had to USD 9,95 for one year for example at www.litessl.de (Disclaimer: I'm not affiliated with this company but a happy company of their "main" operations under a different name).

While some SSL vendors try to put these cheap certificates into a bad light (because they are issued in a automatic process, certain data is not included into the certificate etc), they most certainly do the job i.e. prevent the browser from showing a warning. Currently the SSL vendors try to salvage the cash cow SSL by the introduction of EV certificates.

And regarding virtual hosts this problem has been solved as well, see http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org] This technology is still not universally available and thus it will still take some time but it solves the problem.

So the remaining problem is computational costs and this is the real problem. For big operations this increases the costs significantly and you might need/want to obtain for example SSL hardware acceleration boards.

Re:Cost (1)

spinkham (56603) | about 3 years ago | (#35558876)

Free certs are available, and every bit as (in)secure as the paid standard ssl certs.
http://cert.startcom.org/ [startcom.org] [startcom.org]

Virtual hosts are only a problem if all the following are true:
You use IE on XP on IPv4.
Everyone else but IE on XP now supports SNI. http://en.wikipedia.org/wiki/Server_Name_Indication [wikipedia.org]
IPv6 makes name based virtual hosting unnecessary.

I think personally I'll give IE on XP on IPv4 another year or two before I'll stop supporting that combo on my personal sites. Sorry MS, but you don't get to hold the internet back forever.

Re:Cost (1)

tgd (2822) | about 3 years ago | (#35558962)

How is it Microsoft's responsibility that people are still using a ten year old operating system?

They're not holding the internet back. The fact that usage has exploded by nearly an order of magnitude since XP came out, and a crapton of those people are not wealthy "new computer every two years" types is.

If your target demographic is in that pool of people, then that will drive the requirements you have around SSL support. If not, then why are you worried about it?

Re:Cost (0)

Anonymous Coward | about 3 years ago | (#35558916)

there's a new-ish standard called sni to allow name based virtual hosts over ssl

Certs are a pain (2)

BradleyUffner (103496) | about 3 years ago | (#35558604)

For the company I work for it's because Certs cost money, and self-signed certs are a pain for users.

Re:Certs are a pain (1)

somersault (912633) | about 3 years ago | (#35558674)

They aren't exactly expensive though. Slight pain in the ass to set up, but not that bad. I just use a self signed cert on our own site since it's only employees that need access to the private section.

Price (0)

Anonymous Coward | about 3 years ago | (#35558612)

Because trusted certificates are expensive and don't last long?

Because getting a signed SSL certificate is $$$ (5, Insightful)

realityimpaired (1668397) | about 3 years ago | (#35558614)

Subject says it all. It's expensive to get a signed SSL certificate. If I'm not doing commerce through the website, and it's just a blog of some sort, I'm not going to pay extra money for a certificate when I'm not making any money off it. A self-signed cert is fine for personal use, and I use it for my webmail portal, but it doesn't exactly look professional, or even legitimate, to joe user out there.

*most* commercial websites do actually have an SSL cert for their e-commerce operations. For most, if not all, of the sites I ever use (except Slashdot), I can simply change the http to https and the site will work fine. But I don't really see the point in a website using https for anything that doesn't involve the exchange of personal or financial information. It's unnecessary overhead, and expense, for these websites. HTTPS does add extra sever load on their systems, you know. :)

Re:Because getting a signed SSL certificate is $$$ (1)

Albanach (527650) | about 3 years ago | (#35558752)

Subject says it all. It's expensive to get a signed SSL certificate.

You're kidding, right? You can pick up a single site SSL certificate for under $20 and a wildcard certificate for about $100. For all the other costs associated with running a website, the cost of an SSL certificate is negligible.

You don't need to be doing e-commerce to have data worth protecting. If nothing else, half your users probably use the same login and password for your site as they do for their email, their social networking and possibly their bank! Of course they shouldn't but they do. That data is valuable and worth spending a few dollars to protect.

virtual hosts, money (2)

kae_verens (523642) | about 3 years ago | (#35558616)

1. it costs money to get an SSL from a recognised signing company
2. SSL for virtual hosts is not supported by Internet Explorer (yet another problem with IE)

Re:virtual hosts, money (1)

Ferzerp (83619) | about 3 years ago | (#35558712)

Show an example of something properly configured that it doesn't work on please. If you do it properly, IE will have no clue you're serving sites based on host-headers.

Re:virtual hosts, money (1)

mother_reincarnated (1099781) | about 3 years ago | (#35558828)

The problem is that the SSL negotiation happens before the HTTP session begins so there is no Host header available when the server has to cough up a certificate.

There are really only 3 options for HTTPS virtual hosting:
1) Wildcard certificates if all the sites are in the same domain
2) SAN certificates if the certificate ifs purchased with up to 5 names on it
3) An extension to SSL called SNI that sends the host information in the SSL negotiation.

The OP is referring to the fact that SNI is far from universally supported today.

Re:virtual hosts, money (1)

_Shad0w_ (127912) | about 3 years ago | (#35558900)

Most of the major browsers support SNI, as far as I know. As does Apache on the server side (using OpenSSL or GNUTLS). I suspect the fact that IIS doesn't may be a stumbling block for some sites.

Re:virtual hosts, money (1)

_Shad0w_ (127912) | about 3 years ago | (#35558838)

IE7 and newer, for the record, do support SNI; so long as you're on Windows Vista or Windows 7.

Re:virtual hosts, money (1)

Albanach (527650) | about 3 years ago | (#35558866)

2. SSL for virtual hosts is not supported by Internet Explorer (yet another problem with IE)

What do you mean? Recent versions certainly support it. Perhaps IE6 does not, however many sites have already stopped supporting it at the design level.

Re:virtual hosts, money (1)

EasyTarget (43516) | about 3 years ago | (#35558930)

SSL for virtual hosts is a server side problem, at least for name based hosts; the browser is irrelevant.

Because... (2)

The MAZZTer (911996) | about 3 years ago | (#35558632)

....every [sub]domain needs a dedicated IP for the certs to work properly.

Re:Because... (1)

Albanach (527650) | about 3 years ago | (#35558880)

....every [sub]domain needs a dedicated IP for the certs to work properly.

SSL virtualhosting is neither new, nor uncommon. Both apache and modern browsers support it just fine.

Why should they? (0)

Anonymous Coward | about 3 years ago | (#35558636)

Not every web-site needs you to log in. I know it sounds shocking, but for some of us old-timers who remember the web free, that is how it is supposed to be: you publish your information to be accessible by everyone. With that in mind you do not publish pictures of yourself or your friend hugging the johnny.

Re:Why should they? (1)

tepples (727027) | about 3 years ago | (#35558840)

Not every web-site needs you to log in. I know it sounds shocking, but for some of us old-timers who remember the web free, that is how it is supposed to be: you publish your information to be accessible by everyone.

Without user authentication, how do you prevent a vandal from removing what you have published in favor of what he wants to publish?

Why?! (0)

Anonymous Coward | about 3 years ago | (#35558638)

It cost CPU to crypt and uncrypt! Some servers are dedicated to this task (it s called ssl off-loading). But why do you want HTTPS everywhere? look at the CA you have in your browser. You may have a tunisian or a chinese certificat which means that thay MAY intercept your traffic and read it clearly :)

Duh (0)

Anonymous Coward | about 3 years ago | (#35558642)

The answers to this question are so obvious I wonder why the question was posted to begin with.

1. Additional processing power and bandwidth required to encrypt/decrypt secure streams.
2. SSL certificates can be expensive in some cases.
3. It's just one more thing that can expire and whose lifetime must be tracked on a production Web site.

Another thing to go wrong (1)

iamhassi (659463) | about 3 years ago | (#35558644)

I use to work for.... big hosting company. We were constantly getting calls about problems with https, especially people who bought their https from another company. Most of the problems were people not filling out the information correctly causing the https not to resolve or the other company not communicating with us properly. It's also just another thing to remember to renew every year.

Idiots (0)

Anonymous Coward | about 3 years ago | (#35558658)

If you're posting personal info on Facebook or twitter then you're already an idiot. Posting your personal info by https isn't going to make you less of an idiot.

Cost-benefit (5, Insightful)

Shoten (260439) | about 3 years ago | (#35558672)

Implementing HTTPS isn't quite as simple as just turning something on and walking away. For larger web-based infrastructure, the best practice involves use of SSL terminators to maintain performance at scale; the encryption load of doing SSL or TLS at the actual web server itself is a Very Bad Idea when you're handling a lot of traffic. But those devices are not cheap, and there's a substantial amount of effort in both architecting them into an environment and keeping them running well; it's like any other IT infrastructure, in that it adds cost and complexity. In some cases, other aspects of the environment would have to grow as well...if the IDS and/or IPS sensors, for example, wouldn't see traffic in that section that is 'in the clear' between the web servers and the SSL accelerators, the organization would have to decide between purchasing more of these (much more expensive) security devices and giving up visibility into attacks over what is likely their highest-risk bit of attack surface. For smaller sites, the complexity is lower but cost is a more significant factor, as (for much smaller sites) the challenge and uncertainty of maintaining certificates. And for what? For most sites I can think of, I would be hard-pressed to make a business case in support of ubiquitous SSL...why should the New York Times spend so much just to make sure someone else can't see what news I'm reading? Even if they sniff my account credentials off the wire, what harm could really be done with it that would justify the expense?

Simply put, it's not free, and in most cases, the cost of security would be greater than the cost of the risk being mitigated.

A lot of stuff doesn't need to be secure (4, Insightful)

dkleinsc (563838) | about 3 years ago | (#35558676)

For instance, a large website where the primary goal is public commenting on interesting tech stories, or a public online encyclopedia - the whole point is that it's public, so encrypting it makes no sense.

And SSL encryption has a non-zero cost: it takes cycles to encrypt and decrypt on each end, and costs something to get a certificate.

Re:A lot of stuff doesn't need to be secure (0)

Anonymous Coward | about 3 years ago | (#35558862)

An encyclopedia doesn't need to be verified?

Too often people think of HTTPS in terms of encryption, which admittedly is a major benefit for some sites. Sometimes forgotten is that HTTPS is right now the only reasonable way to provide verification, to ensure that when you're connecting to a site with lots of great information, that information hasn't been forged.

long discussion (2, Interesting)

roman_mir (125474) | about 3 years ago | (#35558680)

Part of this was discussed long ago [slashdot.org], with browsers treating self-signed certificates worse than they treat plain unencrypted traffic, even when passwords are passed around in plain text, nothing will change, because it is a major PITA to deal with browser issues as well as with CAs.

Here is a hint: create more incentives to use HTTPS, not fewer, and more people will use them.

This is not going to be fixed until stupid browsers stop treating a new connection to a website, that is using a self-signed certificate as some sort of a virus, while absolutely not doing the same for plain HTTP connections.

Re:long discussion (1)

thePowerOfGrayskull (905905) | about 3 years ago | (#35558878)

THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.

Under the theory that there's no valid use other than identification, refusal of self-signed certs makes perfect sense. Unfortunately, that theory has little to do with reality.

Why do certs cost $$$? (2, Interesting)

Anonymous Coward | about 3 years ago | (#35558682)

This is something that has really bothered me.

I understand that a self-signed certificate is vulnerable to MitM... however, it's still better than plain-text! And we could be a little smarter about this too, couldn't we?

SSH is a perfect example. When you first connect via SSH, you confirm that you trust the certificate. Your client then remembers the certificate for future use. Why doesn't web technology do this?!?

Instead, when you self-sign a cert, browsers throw a hissy fit and shows a huge warning.

I understand that you need a certificate chain for banks and things like that... Fine. Let them pay money for that. But at least give us the option of having self-signed certs that function. No, it's not as secure as a certificate chain, but it is better than plain-text.

Re:Why do certs cost $$$? (2)

Amnenth (698898) | about 3 years ago | (#35558884)

Browsers exploding in fury when self-signed certs show up is a design decision to protect stupid users from themselves. Otherwise, Joe Sixpack is going to start blindly 'trusting' every self-signed cert he sees just to get the dialog box/popup whatever out of the way, just like he already blindly clicks 'ok' when faced with those fake antivirus popups.

Unreliable (0)

Anonymous Coward | about 3 years ago | (#35558690)

There is no reliable method with https for determining what website is being requested before the user accesses the website. If for example (just making it up, fortunately it wouldn't happen) Facebook and Google were hosted on the same IP addresses, other then differentiating by port, how would the servers be able to tell what website is being requested? They could send Facebooks certificate for google requests, which would cause alarm for the users because wrong site certificate issues. Coupled with the price of certificates, its not a viable option at this time. However, if we made a way to differentiate between websties before we send the cirtificate, then https on every website in the world would be a viable option.

Re:Unreliable (1)

TheCarp (96830) | about 3 years ago | (#35558824)

Actually the first part is readily solved by the use of "subject alternative names".

This is a problem price wise, since crooks like verisign insist that you need some special package to request such certs, and then each name is the full price of a full cert per year. so no break at all on cost (though, you could not use verisign)

I would love to see CACert in the default CA databases widely, that would help a lot.

SSL issues (3, Interesting)

thetagger (1057066) | about 3 years ago | (#35558692)

It's more expensive in terms of processing power, you add latency due to negotiation, you lose caching across sessions, moving the user across servers is not as easy, you lose some amenities like sendfile() support, you have to manage certificates, you have to buy certificates, and in most real-world settings it's a minor security improvement anyway because the biggest security issue is the user's own worm-infested machine.

Well lets see... (2)

mother_reincarnated (1099781) | about 3 years ago | (#35558694)

1) SSL certificates are not free
2) SSL key exchanges are horribly expensive compared with serving a web page
3) Right now EVERY web site would require a unique IP address

Enough reasons?

Some reasons (5, Interesting)

jolyonr (560227) | about 3 years ago | (#35558696)

Ok... In reverse order of significance:

1. Expense (at least traditionally) of SSL Certificates. Although today that's not such a big issue, and an SSL certificate costs about the same as your domain registration. However, if you have multiple subdomains you still need a more expensive certificate.

2. Complication. It can be a highly confusing process for someone who's not an expert to do the certificate request process and the associated installation of the certificate. I know the first time I tried to do it, it went horribly wrong and I spent a day trying to sort it out.

3. Client Performance: SSL websites are slower than non-SSL websites. Not such a big deal again these days, but I remember when I had to wait it would seem forever for the images on my online banking site to load, cursing them every time for such a graphically-intensive SSL site.

4. IP addresses: This is a big one, if you host multiple websites on your server, and you only have a single IP address, you can't host more than one SSL certificate. So you need more IP addresses (which is not easy nowdays). Big deal for small company hosted websites, which are often on shared IPs.

5. Server Performance: A server that can cope with one million users per day using HTTP will not be able to cope with anywhere near that number of connections over HTTPS for obvious reasons. So you not only need a certificate, you potentially need a whole new server architecture to deal with it. Scale this up for a big business like Twitter or Facebook and you're talking implementation costs in high millions of dollars.

Re:Some reasons (0)

Anonymous Coward | about 3 years ago | (#35558936)

6. Site doesn't need https.

Let's face it - a lot of sites simply don't -need- https, so why bother with all of the downsides listed in 1-5 for them?

I understand the need for https if you need some manner of encryption of data and authentication and to prevent the login cookie attack (where even if the login was through https, subsequent non-https traffic can still result in a hijacked session). But if you don't have any of these things - no need for encryption, no need for authentication, and the user isn't logged in or your site doesn't even -have- login capabilities.. why bother?

slower on the wire, harder on the processor (1)

circletimessquare (444983) | about 3 years ago | (#35558718)

of course, this was more of an issue when we were using 386s and 28.8kbps modems, so its more of a historical reason than a present-day reason

although, modern AJAX sites require low latency for a good user experience. HTTPS introduces latency. so there's a new technological issue why HTTPS all of the time won't necessarily take hold

mobile sites and smart phones, which are pretty much the future of the web, and which are growing in leaps and bounds in terms of bandwidth and processor power, are still subject to slow connection/ battery taxing considerations of having HTTPS on all of the time that desktops aren't subject to

but, back to desktop, here's a corollary question: why isn't everyone on ipv6? all sorts of new abilities come into possibility and all sorts of problems are solved with such a huge address space

but here's the rub: all of the benefits are modest enough that it doesn't necessarily outweigh all of the costs involved in making the transition. and the same answer applies to using HTTPS all of the time

It's fairly obvious (0)

Anonymous Coward | about 3 years ago | (#35558742)

1) Granny's not going to pay $100s per year for her blog.
2) Processing overhead. Security comes at the cost of speed.

Dedicated IP (1)

watermark (913726) | about 3 years ago | (#35558754)

HTTPS also requires a dedicated public IP, so you can't share your IP with other websites. Many cheap hosting environments have many websites running on the same IP. This is no excuse for people like Facebook, Twitter, or other big names, but this is one reason why *all* websites don't use HTTPS. For the most part, a cert can only be used for one website. Shared IP hosting uses the host header in the HTTP 1.1 protocol to determine which website to deliver when it receives a request on an IP that hosts multiple websites. The problem with HTTPS is it encrypts the host header, so the web server doesn't know which website to deliver. It can't decrypt the traffic until it knows which cert to use, which it could determine using the host header (which it can't get until it decrypts the traffic.) Chicken and egg scenario...

Named based Virtual hosting doesn't work via HTTPS (1)

alta (1263) | about 3 years ago | (#35558760)

You can put 100's of websites on 1 IP address to virtual host... Kinda one of those evil things like NAT. Cheezy way to save IP addresses, but done very often.

The moment you turn on SSL you're locked to one IP = one website. Much less efficient.

As far as the old SSL = LOAD issues... the first thing I do in PHP on the sites I control is do a header forward to HTTPS.... Computers now can handle a lot more load.

Processing Power/Bandwidth/Expense (1)

Nethemas the Great (909900) | about 3 years ago | (#35558770)

At the end of the day it's all about the money.

  1. The cipher algorithms request processing power which translates to fewer pages served per unit of processor resource.
  2. Standard page compression utilized by web servers to keep bandwidth low no longer works... fewer pages served per unit of network resource.
  3. The cost of security certificates from Verisign, et al. are expensive and self-signed certificates show up as big scary browser warnings to the ignorant masses where as standard unencrypted offers no such scare tactic.
  4. quit asking this question it's getting really tired...

Because.... (1)

Lumpy (12016) | about 3 years ago | (#35558778)

Honestly I do not log into most websites, so why should they "encrypt it"?

if you are not logging in, then who cares if it's encrypted.

Also I have seen very good login systems that are encrypted from client to server that use a JS client side encryption system and it does not use cookies to keep you logged in. Unfortunately most web developers are lazy and dont do a nice secure non https login and session system. https is the fix for lazy cookie session status.

Name-based virtual hosts and TLS/SSL (1)

infernalC (51228) | about 3 years ago | (#35558782)

Most web sites run on name-based virtual hosts. This allows multiple web sites to use the same instance of the web server (Apache, IIS, etc.), reducing costs.

This presents a chicken-an-egg problem with TLS/SSL (the encryption used for https).

When the web server receives the initial request from the browser, it sends back a certificate for it's domain that says to the browser, "Yes, I am really where-ever.com, because I paid money to GoDaddy, Comodo, Verisign or whoever and they'll corroborate."

The problem is, when that first request comes in, and you are using TLS/SSL and name-based virtual hosting, the server can't read what domain name was requested to present the correct certificate. You haven't finished negotiating the TLS/SSL connection yet, so you can't read the URI embedded in the request.

So, you need a different IP for each domain that you are going to serve (IP addresses are becoming rare) or use some other hack to accomplish this.

Does this even merit a reply? (1)

jimicus (737525) | about 3 years ago | (#35558784)

Okay, let's look at this one issue at a time:

1. The great majority of small sites (which an earlier poster has said "wouldn't notice the extra load") run on shared servers. The hosting company certainly would notice the extra load, they'd need more servers, therefore more electricity and floorspace, therefore higher costs, therefore hosting price goes up. Probably rather substantially.

2. HTTPS requires 1 IP address for every site you host. (There is the SNI extension but if this article [techrepublic.com] is to be believed, it's not supported under IE on Windows XP, or for that matter Safari on any version of OS X prior to 10.5.6 - which means it's really not much of a solution yet).

3. Cost and Complication. Sure, hosting providers could bake into their control panel a process to generate a CSR, get it signed by a trusted CA and install the signed certificate without all the messing around this normally entails, but virtually every reputable CA that already has their root certificate in widespread use charges for signing. Oh look, more cost.

This ain't rocket surgery (1)

Lieutenant_Dan (583843) | about 3 years ago | (#35558790)

Cost & Complexity:
- certificates aren't free
- certificates need to be properly managed
- encryption requires computational power
- you would be surprised how many things break when you move around http:/// [http] to https:/// [https] in URLs. There's a lot of amateurs implementing things.
- a SSL cert is usually married to a dedicated IP address, this makes it cost or technically prohibitive for web hosting companies. IPv6 won't be around for a while.

and more importantly

- SSL is not necessary all the time!!!!

I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.

Re:This ain't rocket surgery (1)

Shados (741919) | about 3 years ago | (#35558842)

[blockquote]I would have hard a time recommending to anyone to run their whole site in SSL. Get the logins or most forms in SSL, but the rest would be overkill.[/blockquote]

While most of your post is correct, not that part. Encrypting the login without encrypting the rest of the session is virtually completely pointless, since you leave your users vulnerable to session replay attacks. Yay, I don't know your password! Who cares, I have your authentication token.

They Do Use HTTPS (0)

Anonymous Coward | about 3 years ago | (#35558798)

They do use HTTPS for login authentication, and your username / password are sent encrypted. The authentication token is transmitted unencrypted on those sites.

The security advantage may not last long anyway (2)

jenningsthecat (1525947) | about 3 years ago | (#35558818)

If HTTPS becomes ubiquitous, then there will be much more opportunity, as well as more incentive, to break the encryption consistently and therefore nullify the security.

On the other hand, if everything is encrypted, the traffic that truly NEEDS encryption will be less likely to call attention to itself, because the 'needle' will be in a bigger 'haystack'.

All in all I think it'll end up being a wash.

performance (0)

Anonymous Coward | about 3 years ago | (#35558832)

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.


because we don't need it (0)

Anonymous Coward | about 3 years ago | (#35558860)

financial transactions are ALWAYS handled by 3rd party usury security forces. most of us have no (0) secrets.

Facebook and twitter use https for login page (1)

rjha94 (265433) | about 3 years ago | (#35558874)

The poster has changed
[Every time you log in to any service that uses a plain HTTP connection that's essentially what you're doing.] to
>>Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection and that is not accurate. The Facebook login page uses https.

Smae reasons as always (1)

nedlohs (1335013) | about 3 years ago | (#35558888)

1. Name based virtual hosting doesn't work with HTTPS (unless all virtual hosts use the same cert)
2. Requires more CPU grunt on the web servers
3. Certificates cost money
4. Certificates expire and hence add work to keep the site up and running
5. Embedding http resources in an https page cause some browsers to pop up annoying confirmation boxes

Two major reasons (1)

Burdell (228580) | about 3 years ago | (#35558898)

The CPU overhead of SSL is largely moot at this point; except for servers handling millions of requests per hour, any server from the last 5 years or so is powerful enough that SSL overhead is lost in the noise. I manage a server that gets over two million requests per day (mostly during business hours), all of them SSL (but almost all for static content), and the server is 97% idle during the busiest periods. There are two major reasons people don't use SSL.

First, SSL requires each site to have a unique IP address; shared hosting with multiple sites per IP doesn't work. There is an extension in TLS (version 1.2 IIRC) that allows for multiple sites per IP, but browser support is spotty. IPv6 will fix this (since it'll be just as easy to put sites on different addresses and the same), but not for many years (after IPv6 surpasses IPv4 in market penetration).

Second, SSL requires more maintenance and costs more. The site (or server) admin has to manage the SSL certificate and get it signed periodically (every year or two in most cases) by a recognized certifying authority (CA). Somebody has to remember to do it (or users get warnings) and it costs money (the cheapest widely-recognized CA I'm aware of is $50/year).

People here like to rail against the CA "cartel", but SSL without CAs is mostly pointless. If non-SSL is like a postcard, SSL without CAs is like putting your username/password in an envelope and then flagging down the first person you see and asking them to deliver it for you. Without CAs, you don't know who is on the other end of the encryption path; you could be the subject of a man-in-the-middle attack, a spoofed domain, etc. Some of this can be mitigated by just accepting a cert the first time you visit a site (and verifying it is the same on future visits), but that doesn't protect you against MitM on the first visit or when the cert expires and is replaced.

It's a simple matter of cost... (1)

Zazi (601795) | about 3 years ago | (#35558910)

The simple answer is it is just too costly in some environments to do so, and I'm not talking about SSL Certs, which are arguably pretty cheap.

With using HTTPS for everything, you need that much more processing power to encrypt and decrypt all traffic. That needed processing power has to come from somewhere, and that is going to be more hardware, which in turn says a lot more money is needed for security.

Sure, you can minimize the cost a bit by using SSL gateways, but those can get quite expensive as well, especially in larger web environments like Facebook, Twitter, etc.

Don't get me wrong here -- I would love to see every site using HTTPS (and some of the major ones do offer the option like Facebook), but the cost of implementing a solution like this can be prohibitively expensive.

Caching (0)

Anonymous Coward | about 3 years ago | (#35558914)

I noticed a lot of comments mentioning extra processing, but also browsers don't cache any SSL transferred content between sessions. This includes things like stylesheets, images/sprites, scripts, etc. This can give a poor visitor experience.

It's probably a bad idea, but I think if browsers didn't give a warning about loading "unsecured" content (like any of the above) over a "secured" connection this would be less of a problem. It would be handy if designers were able to say that a particular piece of content is cacheable even over a secured connection. This would provide a better experience.

Although less of a concern now, (transparent?) caching HTTP proxies cannot help speed up the web over HTTPS either.

Filtering HTTP proxies are more common, and are rendered ineffective by HTTPS.

Also (1)

trollertron3000 (1940942) | about 3 years ago | (#35558942)

Why doesn't every house have a digital+analog lock with one time pad? And why doesn't my car fly?

It's called cost and effort smarty pants. It's not like we've been over here in the dark ignoring it.

Because... (1)

ceeam (39911) | about 3 years ago | (#35558948)

Because it's impossible/complicated to have multiple "HTTPS'd" domains on a single IP address.

Also, it's not really more "secure" in most senses of this word.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account