HTTPS is more secure, so why isn't the Web using it?

http://arstechnica.com/web/news/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it.ars?utm_source=rss&utm_medium=rss&utm_campaign=rss

by zoowar • 15 years ago

84 82 15 years ago

arstechnica.com

kennet• 15 years ago

I have a silly, fictional view of the future: That every website will be HTTPS by default, and instead of Firefox/Chrome/etc using a "green" bar to tell a secure website, it will not say anything, but will display big red warnings when a website is not secure.

jedsmith8• 15 years ago

And we'll all have muscle memory to add the exception through the browser's four-step "I know what I'm doing" UI.

drzaiusapelord2• 15 years ago

In Chrome and IE its one or two clicks. I don't know why people tolerate Firefox's silly "ZOMG THIS SSL CERT MIGHT BE WRONG" 90-click UI. Joe Averge is still going to run through the clicks. Badgering the user with more prompts has been shown to not increase security and only frustrate power users.

drzaiusapelord2• 15 years ago

The problem is that there aren't enough IPv4 IP address for this. Each SSL cert requires an IP address. So if you have 200 sites on one virtual setup with one IP, only one of them can have the SSL. The connection needs to be established before Apache or IIS can be told what site to serve.

Maybe v6 will solve this, but right now you simply cannot do this. Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?).

duskwuff2• 15 years ago

> Or maybe the spec can be changed somehow (ask for host first then start SSL handshake?).

SNI does exactly this. Sadly, MSIE doesn't support it under Windows XP (and earlier), so we have to live without it for a while longer.

benjoffe• 15 years ago

> 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.

I'll be honest, I didn't read any more of the article after this totally false statement in the intro. Facebook and Twitter both use https for login (they are http pages that submit to a https endpoint that redirect to http, that way https is used for authentication but never appears in the url).

djjose• 15 years ago

True, but it's not obvious to non-techies (hence the article). I was curious how FB did logins when we were creating our API and site since I couldn't fathom them sending l/p's without https. A long look at their source on the homepage is really all it took to guess what they did (a guess, I could still be wrong). After a good deal of painful eyestrain I noticed they seemed to be using their internal APIs via JS over https for authentication. I wonder how many "non-https" sites also do this. I'd still wager a good deal of sites still send authentication over plain ol' http though. Is the lag for authentication purposes really that bad? Anyone have any hard metrics?

watchandwait• 15 years ago

Yeah but even with https login, if a site also serves regular http pages, cookies with session credentials are still visible (on open networks) and the session can be hijacked.

kinofcain2• 15 years ago

Sort of. Twitter and Facebook still serve their home pages as HTTP and provide a login form that posts over HTTPS.

The problem is that I can do a MITM attack on the unsecured home page and put my own script in there that siphons off the user's password when they click the submit button.

So the HTTPS-posting form prevents the eavesdropping case, but not the man-in-the-middle case.

That's how the Tunisian government was harvesting their citizen's facebook logins:

http://www.thehackernews.com/2011/03/exposure-how-does-tunis...

bitskits• 15 years ago

I have a feeling it has more to do with the sharing of cookies and tracking code than anything else. Once everything is https://, marketers aren't able to share information across sites, and although the internet is made of cats, those cats need their money.

DrStalker2• 15 years ago

If browsers would be happy to allow users to a site with a self-signed SSL certificate, which is far more secure than HTTP, then I'd be happy to put in the extra time and effort to ensure 100% of communications occured over HTTPS.

Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.

mukyu7• 15 years ago

A self-signed cert provides effectively zero protection. You have no guarantee of the identity of the site and there is no confidentiality in your traffic. Key continuity (the only assurance you have that the cert might be legit) is not effective on the web, where you are likely to interact with hundreds of unknown hosts.

If browsers do not throw big warnings at self-signed certs it is trivial to impersonate even sites that do have real certificates. The user sees a lock icon and thinks they are secure, but they are sending their credit card to someone other than Amazon.com. This is slightly fixed by EV certs, but there is still a large user training issue.

jedsmith8• 15 years ago

> A self-signed cert provides effectively zero protection.

From the other end.

I had this debate with someone in person, and they tried to tell me that since you cannot trust the other end with a self-signed there is no point in protecting your traffic from eavesdroppers on the open AP. That makes no sense to me, but he was passionate enough about it that I let it go. He never could tell me why, so I invite a more learned HNer to complete his argument for him and persuade me.

My take:

There's a difference between identity and encryption, and I think warning users about a site that wants encryption but doesn't necessarily want or need identity is a bigger user-training mistake than anything else browsers have ever done.

Perhaps the lock was the problem there; in that case, if I offer a self-signed certificate, perhaps the better UI experience would be to inform the user in that "Page Info" that their connection is encrypted, but they have no idea if the other end is who they say they are -- and don't bless the page with a lock, bar, anything. The entire construction of https:// needing to imply both encryption and identity doesn't make sense to me, as I see them as distinct concepts. One does not necessarily imply the other, but browsers make it so.

Maybe this is inherent to SSL/TLS itself and I'm the off-base one, but logically it makes sense to me.

tedunangst• 15 years ago

It provides protection if you have access to a reasonably trusted network. Let's say HN adds https with a self signed cert. I trust my home network, more or less, so I'll agree and accept the cert. Then if I take my laptop on the road, I can verify that the cert I'm getting over public wifi is the same cert I downloaded at home. That is tons better than the current "broadcast your password in plaintext" scenario we've got going on now.

It means you can't trust sites if you're out of the house and you haven't been there before, but every site I care about trusting gets visited from in my house.

And how big are certs? Not that big. It's conceivable you could download a bundle of them beforehand. We're getting almost back to CA land, though, so I'm going to cut this idea short, but you can imagine a service that collects certs and verifies nothing except that they are the same as they were last week.

asharp3• 15 years ago

Yes and no.

Yes, on any sort of small network, you can be instantly MITM'd with basically no protection.

No, in that on any sort of large scale traffic it becomes impractical to filter, ie. with modest hardware you can trawl through http at say 10Gbps, it's basically impossible to MITM at that sort of speed without much greater hardware requirements.

Imo, having a self signed certificate simply appear to be http, ie. no "secure" icon, no locks, etc. would be a good middle ground.

jeza2• 15 years ago

If an attacker manages to MITM your initial browser installation or upgrade download then we're in trouble. We'd then have to resort to verifying the authenticity of our browser install file through some other means. You could use HTTPS for your download though you'd need to be sure that you've done this every time and the original copy was from a trusted source. No doubt this is why open source developers are so keen to exchange GPG keys when they meet in person.

Though at least when you're using some public wifi AP, you're unlikely to be upgrading your browser.

pilif• 15 years ago

Let's use FireSheep to illustrate the problem: If browsers wouldn't complain about self-signed certificates, I would extend FireSheep just a little bit to arp-spoof the IP-address of the gateway.

This means that all the traffic in $coffeeshop is now being routed through my machine.

Now whenever I see someone logging into facebook, I'm just pretending to be facebook, using my very own self-signed certificate.

The user on the other end wouldn't notice at all if they didn't warn about self-signed certificates.

Now the user thinks they log into facebook while they are actually logging in at my proxy.

Browsers that blindly accept self-signed certificates would make for a much worse attack than firesheep (Firesheep allows hijacking of active sessions, man-in-the-middle-ing SSL connections gives you the password for offline use.

You could of course try and work around this by having browsers "blow up" if the certificate changes at all. But what if facebook has to renew their self-signed certificate? Ok. Then let's just blow up if the signer authority changes? How do you make sure that the facebook who has signed the current certificate is actually the real facebook and not me impersonating as facebook?

Accepting self-signed certificates might work with some kind of web of trust. Imagine the browser showing a message like:

"Do your trust this site? 99.992% of our users have seen the same certificate, so it's pretty certain that this is really the right site"

This, again, works until Facebook has to change that certificate:

"Do you trust this site? 0.00001% of our users have seen this certificate. This is probably a phishing attempt"

Don't get me wrong. I think that the current CAs overcharge for their services. I do think that there are way too many CAs already listed in your browsers. I do think that the whole process is too complicated.

But over the years, I really came to an understanding that this, for the moment, is a necessary evil.

ericmoritz• 15 years ago

We had a dream of taking an ardrino, a wifi shield and writing a session cookie sniffer that will tweet/facebook status updates that says something along the lines of, "X coffee is so much better than Y coffee" and hiding the think somewhere need two competing coffee shops. Seemed like a perfect demonstration of how bad the problem is. We never got around to doing it though.

mopoke• 15 years ago

> Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn't work with virtual hosts.

That's a bit confusing. They mean when multiple sites share the same public IP. You can run SSL on a "virtual host" (i.e. a host running as a VM rather than on bare metal).

Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic. (or the additional cost of investing in a dedicated layer to do that for you).

jedsmith8• 15 years ago

> "virtual host" (i.e. a host running as a VM rather than on bare metal).

That isn't what virtual host means, particularly not here. Your "they mean ___" is exactly what virtual host means. http://en.wikipedia.org/wiki/Virtual_hosting

> Also not mentioned is the general increase in server load by having to encrypt/decrypt all traffic.

Because it's fairly negligible, especially with OpenSSL able to take advantage of AES-NI and equivalents. Most of the hit you see is setting up a connection. You can move SSL off your app stack and onto load balancers, too, and it's wise to do so.

streeter• 15 years ago

It is actually possible to serve multiple virtual hosts from the same IP (http://en.wikipedia.org/wiki/Server_Name_Indication#The_fix).

The first technique is called Sever Name Indication, which is a way to specify a virtual host with TLS (https) negotiations by sending the virtual domain as part of the TLS negotiation

The second method is a specification that introduces the subjectAltName field which allows one cert to be used across multiple subdomains (for things like wildcarding). This would make it really easy to do organization-based subdomains with TLS encryption.

There are limits to which browsers and which servers can do it. It requires IE7 and up (not on XP though), and basically all recent versions of other browsers.

Edit: noted that IE on XP doesn't work.

duskwuff2• 15 years ago

SNI doesn't work in IE7 (or IE8) if you're running Windows XP. This ends up leaving a sizable chunk of users unable to use it.

listrophy2• 15 years ago

From the article, it's not so much the TLS protocol that allows SSL on virtual hosts, it's specifically the Server Name Indication (SNI) TLS extension. And every major browser version supports SNI except IE6 (arguably not major anymore) and any IE on XP (except maybe IE9?).

jedsmith8• 15 years ago

IE9 will never run on XP, so you're right, just not in a way you expect.

listrophy2• 15 years ago

I thought that might be the case, but I figured I had already hit my limit on parenthetical phrases, so I didn't bother investigating.

tghw• 15 years ago

The real problem, according to Lafon, is that with HTTPS you lose the ability to cache.

I'm fairly certain this is false, unless they're talking about proxy caching. Normal browser caching works equally well in HTTPS as it does in HTTP.

jedsmith8• 15 years ago

The leading browsers were fairly stubborn on caching SSL resources for a while -- specifically to disk -- but (I think) most of them now obey the magic words:

    Cache-control: public

Some data here: http://stackoverflow.com/questions/174348/will-web-browsers-...

I'm interested in what the state of this is, myself, but I know that one of IE 9's improvements was HTTPS conditional requests.

justinludwig• 15 years ago

> unless they're talking about proxy caching

I'm fairly certain that's what he's talking about. A) He's Yves Lafon, and B) when you're talking web architecture, you care very much about what intermediaries can do.

kinofcain2• 15 years ago

What I find as slightly amusing is that the major web browsers will throw up all sorts of fancy, scary warning messages if you're hitting a site with an expired or invalid certificate, but they don't say a darn thing when you hit a site over http.

I understand that lying about your encryption is potentially a bigger deal than not having any at all, but still.

eapen• 15 years ago

Disappointed to see that this author doesn't really understand the issue he is writing about. The Firesheep tool would actually pick the cookies sent over HTTP rather than the username/password which was sent securely (in most cases). Also, as others have mentioned, it is possible to have an SSL cert installed on Virtual hosts. Dreamhost offers an option for as little as around $3-4 a month to have an SSL cert for a site.

Sometimes, I wish I could downvote an article on HN.

nate• 15 years ago

I was doing some load testing on a new project of ours and noticed that I couldn't break 50-60 reqs per second sending all the requests through stunnel-haproxy or apache-haproxy to a cluster of app servers that should have handled about 200ish reqs per second. This wasn't a problem if the traffic wasn't encrypted. Didn't seem like a CPU bottleneck with the machine doing the load test measurements either.

So I did some digging. And noticed that https://encrypted.google.com uses RC4_128 as a cipher. You know what Bank of America uses too? RC4_128. RC4 happens to be a much faster cipher.

RC4 has gotten some bad press as it was used in WEP encryption and was cracked. But I believe it was because their RC4 implementation had a flaw rather than RC4 at 128 bis being a terrible choice for encryption? I'm not positive and would love to hear your input.

I switched our load balancer to make sure we were using RC4_128 instead of AES_256, and bam I had 3-4 times more throughput of encrypted requests going through just fine.

mukyu7• 15 years ago

The attacks used against RC4 as used in WEP are not applicable to RC4 as used in TLS connections. If you do not use related keys and discard at least the first 256 bytes, RC4 is fine. It is not that they implemented RC4 incorrectly, but that they did not account for its known weaknesses.

yason2• 15 years ago

I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed.

It's much like bumping onto someone at the gym frequently but not really knowing their name or who they are. You can still trust that he's the same guy, sans having had a facial plastic surgery.

Sending passwords over plaintext http is just stupid. To mount a man-in-the-middle attack you actually have to do something and position yourself between the two ends, not just listen to the passing network traffic.

So, you might log on to Twitter at home (a relatively safe connection) and receive their public key and then use that to communicate with Twitter again later in public wifis or among middlemen at the airport. The browser would refuse to connect if the key doesn't match, much like ssh will complain if the host key fingerprint has changed (and require you to do manual purging of your known_hosts file).

Gmail is the only one where you can tap "Always use https" on. To Facebook you can connect with https://facebook.com but I don't know whether any auxiliary or Ajax/XMLRPC connections will use that.

chrisbolt2• 15 years ago

I'm strongly in favor of encrypting the channel even without signed certificates. A self-signing certificate doesn't authenticate the session but it can be used to later verify that the other end hasn't changed.

Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.

pyre2• 15 years ago

Errr... Are we advocating HTTPS everywhere? Or just when it's time to transfer private information?

When I want to read an essay on some random website, to I need to now that the website owner is who they say that they are? Isn't self-signed HTTPS better than just plain old HTTP? Or is it better that we only use HTTPS for a select few sites that aren't self-signed and HTTP everywhere else?

yason2• 15 years ago

And that is somehow worse than letting this 'man' just read the same information any time in Wireshark without ever getting to the middle?

Note that with self-signed certificates the man can only attack in the middle on the very first connection. After that the other end will be known (not authenticated, but known!) and the browser can guard that.

Currently, I trust my home DSL connection to not have eavesdroppers everytime when I authenticate to some web service over HTTP. Doing the initial connection once using the same network wouldn't be any worse but it would be much better when using any public wifi when I don't know exactly who is providing the service or who is intercepting the wireless connections.

known• 15 years ago

HTTPS - HTTP = 3 Seconds

fierarul4• 15 years ago

'The web' isn't using HTTPS since SSL is a nice yearly 'tax' on the domain owner.

It seems to me we have a nice centralized monopoly here with the existing Certificate Authorities (most US-centric) for something as decentralized as the internet.

Why can't the domain name registrar give me a SSL cert for free? I mean, if I did buy a domain name, and I'm able to change the records, it's pretty clear I own the thing. Certificate info should just be a DNS record imho.

Regarding identity checks, there are other stupidities I see here: for example, my company has to send monthly/yearly papers to the government entities (some of which get publishes into some official government papers). Why can't I publish my public key there?

I mean, if anything, it's very bureaucratic to do anything involving public institutions so each paper is stamped, checked, etc.

I would trust more a local clerk to check for identity then some US guy that has never in his life actually seen a deed of incorporation for a Romanian entity.

So, yeah, I would love to have my site with HTTPS and to sign all my JARs and emails but until this becomes more sane or my customers actually start demanding it, I'm not going to waste money on that.

bsdbuddy• 15 years ago

Although I absolutely agree with your whole comment, I would just like to add one point.

If you doing online business, and successfully, the yearly charge shouldn't be such an issue. However, for non-profit websites its absolutely out of the question. I'm curious - as your customers aren't demanding SSL what industry are you in?

fierarul4• 15 years ago

Well, the yearly charge isn't such an issue, but I cringe knowing I could pay a small server for an year of uptime with the money I pay for an SSL cert, which is essentially an official stamp of a member of the CA oligarchy.

I mostly do contract work so I don't need SSL on my front-facing sites. We do use sites that have SSL to send deliverables and such, but I just pay for their service, not for the cert itself. Internally we've also used self-signed certs, our own CA or just SSH port forwarding.

As an industry we should move towards encription but away from the current CA model. Somehow everybody portrays it as if it's the same thing.

JonnieCache2• 15 years ago

>Why can't the domain name registrar give me a SSL cert for free?

http://www.startssl.com/ will give you a free class one SSL cert that works in all major browsers. They will also sell you a class 2 cert with wildcard support for $49 a year. These can cost $800+ in other places IIRC.

They are trying valiantly to destroy the entrenched price structure of the SSL cert market and I wish them the best of luck.

mooism2• 15 years ago

Their website says their certs work in all major browsers, but I can't find anywhere where it says which versions of those major browsers it works with.

E.g. it works with Internet Explorer. Does that include IE6? They don't say.

mukyu7• 15 years ago

The EFF[1] mapped out the CA structure of the internet and it is easy to see it is anything but a monopoly or US-centric. [2]

DNS is not used for key storage as DNS is not authenticated. There is nothing stopping your registrar from being a CA and issuing you certificates.

SSL certs are assigned to specific domain names. The CA really doesn't need to care if you are a Fooian Industries registered as a Romanian company. They are only interested in if you are the proper owner of fooian-ind.com. That your local government official knows that you are fierarul is of no value in determining if the cert someone sent me for fooian-ind.com is the correct one for fooian-ind.com.

The infrastructure to support SSL is the result of a large number of smart people sitting down together and working out solutions. Chances are that any deficiencies or alternative solutions you may think of were considered or result from your lack of understanding. It is clearly arrogant to think otherwise.

[1] http://www.eff.org/observatory

[2] http://www.eff.org/files/colour_map_of_CAs.pdf

fierarul4• 15 years ago

I think I've stumbled upon that EFF link at some point, but I didn't study it very much.

The CA graph they list there is nice, but it doesn't say much since many of the CAs there don't actually sell to consumers certificates, no?

Looking at this PDF[1] I see on page 23 that there are about 30 root CAs that have signed more that 1000 certificates. And (from page 21) it seems to me that the providers are very much US centric.

With regard to what does the SSL cert contain, I don't know much about this field, but I do know that the certificate may present and organization name and address/state/country. Hence I assume, identity also matters for some besides just domain ownership.

Anyhow, I'm not claiming I've found a better solution than the smart guys sitting down and working out solutions, but I do find annoying that the solution they found is so expensive for commoners.

As an armchair discussion, I still think that certificate info seems best to belong into a DNS record. DNSSEC perhaps could help with this?

1. https://www.eff.org/files/DefconSSLiverse.pdf

kogir• 15 years ago

Why can't I add my site's certificate as a DNS record, use DNSSEC and be done?

I don't want to give Symantec (owner of Verisign) money or trust to do something I can easily do myself.

dchest• 15 years ago

That's what djb's CurveCP is trying to do (http://curvecp.org/) (except with DNSCurve and custom protocols)

asharp3• 15 years ago

because DNSSEC isn't required.

As an example, if i mitm your dhcp request, i insert myself in as your dns server and gateway and i just say that DNSSEC isn't enabled for this domain. You have to trust me, and I can give you a MITM'd page.

Similarly dnssec uses a very similar model. You need somebody to sign that your record is valid which is roughly the same as somebody signing your certificate as valid. They are both a chain of trust, they just differ slightly in implementation.

I do agree with you that using dnssec makes more sense then our current system.

jeza2• 15 years ago

Living in Australia, I can tell you the main reason caching is so important is because our main telco decided to charge by megabytes of usage. Back in the days when most of us were stuck on dialup, they were charging $0.18 a megabyte. At least the slow speeds limited the damage, though downloading a 600MB would still have cost a ridiculous $108. Meanwhile the rest of the world hadn't even though of charing such tariffs for internet usage. Of course once you have one company setting the standard then their competitors all follow suite.

While things have improved tremendously since then, broadband plans are still based around download and sometimes even upload usage. At least now you're looking at something more reasonable like $50/month for 50 gigabytes a month of included download usage. So originally caching would actually save you serious money (unfortunately ISPs rarely passed on these savings to customers if they used their proxy server). Though nowadays it's less important as long as the websites you visit are responsive. Granted you're always going to have some kind of client side cache.

PHPAdam• 15 years ago

Its due to SSL Tax should be included free with every IP. IMHO.

HTTPS is more secure, so why isn't the Web using it?

Related Stories