HTTPS is more secure, so why isn't the Web using it?(arstechnica.com)
arstechnica.com
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
16 comments
>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.
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.
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.
E.g. it works with Internet Explorer. Does that include IE6? They don't say.
They're free, why not try it and find out? ;)
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.
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.
To be more precise, IE uses the SSL libs built-in to Windows since 2000. As a result the list of trusted root CAs is built-in too. MS added StartCom to the list in 2009.
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
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
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
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
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?
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?
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.
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.
Encryption in itself does little good without a certification authority model. Without a mathematically robust CA chain, you never know if you're sending your encrypted traffic to your intended target or to a man-in-the-middle attacker pretending to be your target. Encryption protects against a passive sniffer but not a party capable of intercepting messages.
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.
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.
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.
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.
Until then it's extra time, effort and cost to offer something that most users do not understand and do not care about.
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.
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.
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.
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.
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.
> 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.
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.
There are not many cases where you can read traffic, but not intercept/inject your own.
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.
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.
You just ensure the browser warns you if the self-signed certificate changes.
It works fine this way for ssh.
It works fine this way for ssh.
Out of interest, if you are warned that a site's SSL certificate has changed, what steps would you take to confirm the authenticity of the new certificate?
You use the same model as SSH: give a big warning with klaxons "Warning, this site's SSL certificate has changed, it is possible that you are being actively attacked" and then force the user to dig into an text file and manually remove the offending memorized entry (no prompt for saying "Ignore and carry on"). The hope being that an inexperienced user would find someone more competent to help them out.
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).
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).
I normally contact someone who is on a completely different internet connection to myself. I asked a friend of mine who lives the other side of the world to tell me what he saw the cert in question as, and it did not match the cert I was being given, so I rejected it.
That is key continuity.
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.
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.
Actually I don't visit webservers with a uniform random distribution. I come back to some frequently (eg. my bank, HN, BBC News, ...) Maybe that's just me though.
It's not inherent to SSL/TLS, it's a general issue. If you can't verify that the encryption key you're using actually belongs to the person you think it does, you're only protected against passive eavesdropping. Which buys you only weak protection against government mass surveillance, and none at all against someone doing something like DNS spoofing.
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.
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.
The key about self-signed certificates is that while they don't give specific identity assurances, they do give identity assurances across multiple transactions with the website. That is, the website I talked to yesterday is the same one I'm talking to today.
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.
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.
MITMing someone with selfsigned certs on an open wifi network is trivial. Any scriptkiddy can do it with mere minutes of setup and technical rampup: (http://www.thoughtcrime.org/software/sslsniff/).
In the real world, self-signed certs provide neither identity verification nor security.
In the real world, self-signed certs provide neither identity verification nor security.
[deleted]
The reason is that to achieve true security, they go hand in hand. Without identity verification, you can simply perform a MITM attack (decrypt connection from client, re-encrypt when talking to the server). Firesheep showed MITM over HTTP to be trivially easy. Modifying Firesheep to do the same MITM attacks over HTTPS with self-signed certificates would be equally easy.
> Firesheep showed MITM over HTTP to be trivially easy.
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.
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.
Jed. Imagine a world in which browsers don't throw a fit when given self-signed certificates. Imagine Jedsville.com, your new startup that, to save $15, uses a self-signed certificate. Imagine me, visiting that website, getting a certificate so that my browser and your server can agree on an AES key for us to encrypt traffic with.
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?
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?
I'm not sure why you condescend me by writing my name in responses to me, but it bugs me to death. That's the second time you've done it to me (you did it when I took the unpopular side in the Square credit card bonanza, too), and I am capable of communicating with you from the same level. I don't see you naming other people you're communicating with to add emphasis, so I must assume it's me.
> 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".
> 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".
I'm sorry you find that condescending. I don't mean it to be.
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.
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.
Fair enough -- text is hard to parse. No hard feelings.
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.
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.
There are multiple software packages that make it trivial to set up a rogue ap or attack a physical network (with say, arp spoofing). The same is true for proxies that will attack ssl by replacing any certs that it needs to.
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.
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.
But what is the resource cost to spoof a connection? Very cheap for a teenager to sit at Starbucks and spoof your connection, but how much would it cost when using a fiber splitter at AT&T in order to MITM billions of connections per day?
It would cost more to proxy a billion connections a day than to read them off the wire. But it would not cost so much more as to change the feasibility of the attack. At Internet scale, you may be talking about doubling the cost.
Meanwhile, the proxy attack is the gold standard on the actual Internet we all use. Sniffers are obsolete.
Meanwhile, the proxy attack is the gold standard on the actual Internet we all use. Sniffers are obsolete.
DNS spoofing on a Wi-Fi network is quite simple, the whole MITM process including certificate generation is already automated with a wireshark-like tool. http://monkey.org/~dugsong/dsniff/faq.html
If you are accessing a HTTPS site with a certificate that was not ultimately signed by a private key matching one of the public keys your browser has been told to trust, and you are using a public network (free wireless somewhere, for instance) how can you tell that the certificate your browser receives came from the destination server (your self signed cert) or a transparent proxy somewhere between you and it? A certificate signed by a non-trusted key will look the same to the browser whether it was signed by the site owner or a third party, so it would not be able to tell that a transparent proxy is decrypting the content from the server and re-encrypting it to send to you (potentially inspecting and logging the content on the way through that process).
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).
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).
The only identity verification done by the vast majority of CAs is that you must be able to reply to email sent to one of a few email addresses at the domain you are trying to get a cert for. There have even been cases where people have gotten certs for free email providers just by signing up for one of those email addresses.
Aye, which I assume (but as I've not tried it I can't say for certain) is essentially what they do for the free certs. So they would be no less useful as encryption only certificates than the cheap paid-for ones, assuming the level of acceptance by browsers is adequate for the needs of the site using the cert.
>There's a difference between identity and encryption,
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.
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.
"encryption and identity... as distinct concepts"
It is pretty standard to view these as separate concepts, see:
http://en.wikipedia.org/wiki/Information_security
It is pretty standard to view these as separate concepts, see:
http://en.wikipedia.org/wiki/Information_security
MITM is a type of eavesdropper.
SSL locks identity with encryption to prevent MITM attacks.
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.
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.
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.
Though at least when you're using some public wifi AP, you're unlikely to be upgrading your browser.
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.
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.
[deleted]
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.
And we'll all have muscle memory to add the exception through the browser's four-step "I know what I'm doing" UI.
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.
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?).
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?).
> 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.
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.
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?).
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.
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.
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.
Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.
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.
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.
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?
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?
If you're not transferring private information, why does it matter if it's encrypted? Either you care if someone can eavesdrop or you don't.
The whole online presence might be something that some regard as private since reading a given URL might be as private as a forum password or card info.
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.
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.
If you only use encryption when you 'have something to hide,' then use of encryption is enough to incriminate you.
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.
I don't want to give Symantec (owner of Verisign) money or trust to do something I can easily do myself.
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.
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.
That's what djb's CurveCP is trying to do (http://curvecp.org/) (except with DNSCurve and custom protocols)
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.
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.
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:
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.
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.
> 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.
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.
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.
I understand that lying about your encryption is potentially a bigger deal than not having any at all, but still.
> 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).
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).
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...
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...
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.
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?
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.
Sometimes, I wish I could downvote an article on HN.
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.
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.
> 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).
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).
> "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.
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.
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.
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.
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.
Its due to SSL Tax should be included free with every IP. IMHO.
HTTPS - HTTP = 3 Seconds
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.