HTTPS is more secure, so why isn't the Web using it?
arstechnica.com
arstechnica.com
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.
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?
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.
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.
E.g. it works with Internet Explorer. Does that include IE6? They don't say.
But yes, as far as I remember, they do work on IE6. The root certs dont really change between browser versions I think, its more a matter of the the different vendors.
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.
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?
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.
Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.
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.
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.
All you need to do is generate your own cert for the site and the user will encrypt their traffic to you. This is why the lack authentication means that no confidentiality is provided.
It works fine this way for ssh.
There are loads of ways this could go wrong (the phishing website earnestly telling the user that they "changed" their SSL key and that you need to follow these simple steps to "fix" your browser; the initial contact being the bogus website; the huge loss of traffic if your SSL key legitimately changes and you're not prepared; you need to deal with revocation).
It works for ssh because you generally know the parties you are trying to connect to ahead of time and have ways to communicate with them (to confirm keys etc).
You do not have the same relationship with 99.99% of the servers you will be connecting to over https. It does not work.
Firesheep does not perform MITM attacks (the media made this mistake too). It catches sessions out of the air and impersonates them, which is session hijacking.
As you wrote yourself, a man in the middle attack makes the victim think he is communicating with the far end; Firesheep doesn't involve the victim except to catch his packets.
Tell me this. How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to?
> to save $15, uses a self-signed certificate.
Valid SSL can be had from StartSSL for no charge. Money is not the issue, it's browsers completely flipping their shit at a self-signed.
> How does my browser know if I've agreed with your server for a key, or with the man-in-the-middle proxy I've transparently been redirected to?
It doesn't. Which is why, quoting myself and adding emphasis:
> 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
This is the function of the big red warning, but it's the implementation of that very warning that I disagree with. However, the traffic in between you and the other end (the other end that you cannot verify, remember) is still encrypted from completely unrelated third parties, so there is still a negligible benefit.
It limits "opened Wireshark and watched you work" to "need to know specifically what I'm after and generate a certificate and poison DNS and ..." A self-signed alone raises the barrier to entry at Starbucks significantly from "really, really easy" to "need to reconnoiter the target and have significant control over the network".
The distinction you're trying to draw between "attacks that can be carried out with Wireshark" and "attacks that can be carried out with Wireshark and a Perl script" aren't meaningful to me, so I'm obviously the wrong person to try to persuade you about this. Sorry for wasting your time.
I don't see why it's a meaningless distinction. To pull off a MITM, you need quite a bit more than a Perl script, and you're pretty much not going to do it on a network that you do not control. I'm speaking from a basic knowledge of networking theory (I've unintentionally avoided dark arts), so I'm willing to be corrected if I'm wrong.
That's the value I see: I don't think I'm going to walk into Starbucks with Perl and successfully MITM even my theoretical browser that doesn't care about self-signed certificates. The value is that in that scenario, even a self-signed makes reading traffic that doesn't belong to you harder.
I'm here to discuss, though, and I'm willing to learn; don't give up so easily.
These are not theoretical attacks. Any 16 year old with a $300 netbook can download software written by others and perform these attacks at your local Starbucks in a few hours. They would be able to see all traffic (even https) and without self-signed warnings the only outward sign would be the lack of the green url bar associated with EV certs.
Meanwhile, the proxy attack is the gold standard on the actual Internet we all use. Sniffers are obsolete.
On the other hand, the whole top-down certificate authority model is pretty weak anyway, especially since browsers don't provide any warning when a certificate for a site you've visited before has changed before its expiration date.
In the real world, self-signed certs provide neither identity verification nor security.
I agree completely with this and would love a way to encrypt all the sites I look after without jumping through all the hoops needed to confirm identity to get an SSL cert that doens't make the site appear less secure than an unsecured HTTP site.
It is pretty standard to view these as separate concepts, see:
If I had to implement "automatic" HTTPS, I would probably ask browsers to automatically accept self-signed certificates on the first transaction. Thus, with no user-interaction in the good case, an attacker must manage to MiTM the user on the very first time they access a site, and this is considerably harder to do and less likely to result in interesting information. So I do believe encryption without MiTM protection is a security increase. But there are usability trade-offs and obvious costs for rolling something out like this, and I don't think this particular proposal makes the cut, unfortunately.
The way around this is for there to be fee SSL signing CAs that have their root trust certificate commonly installed. It is getting to the point now startssl's root key used for their free certificates is trusted by most browsers (http://en.wikipedia.org/wiki/StartCom), so you can probably use those for your needs. I don't think any other of the free providers (like cacert.org) have this level of acceptance yet.
The difference between using a free cert from startssl or similar and using a self-signed certificate is that startssl will only issue a certificate to someone who has somehow verified they are in control of the name being certified (i.e. their contact details are in the whois records or such - I'm not sure what validation method they use as I've not used their service yet myself but they must do something adequate enough to get their root cert trusted by the big name browsers/OSs), whereas I can self-sign a certificate for any domain name, as could you, as could that nefarious transparent proxy.
TL;DR: For personal use on your own machines, use a self signed cert and install your CA cert as trusted on your machines. For more general access (i.e. a public facing service) you'll have to try startssl or pay your dues (otherwise even "encryption only" does not work because of the proxy problem).
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.
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.
Though at least when you're using some public wifi AP, you're unlikely to be upgrading your browser.
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.
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?).
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.
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.
Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.
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?
But 'either you care or you don't' seems too inflexible to me.
For example, I might care that my bank has a certificate signed by a CA.
But for some usergroup's online forum, a self-signed certificate is enough. Sure, we might get some MITM but the barrier to this is so high and the relative importance of the online forum so low, it seems an adequate trade-off. I'd say there's a higher chance of the server hard drive failing than to see an actual MITM attack on a given niche server.
But overall, as I've said in another message here, I see this whole centralized design as flawed and much too expensive. Certificate info should be a DNS attribute.
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.
I don't want to give Symantec (owner of Verisign) money or trust to do something I can easily do myself.
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.
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.
Cache-control: public
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.
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.
I understand that lying about your encryption is potentially a bigger deal than not having any at all, but still.
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).
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...
Sometimes, I wish I could downvote an article on HN.
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.
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).
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.
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.