SSL Certificates Compromised By Governments & Hackers: Time To Fix SSL
from the man-in-the-middle dept
The idea of using man-in-the-middle attacks to spy on encrypted conversations is hardly new, but there hasn't been a really thorough discussion of the likelihood of its use against SSL connections (the encrypted connections you see in your web browser on https sites, such as online banking sites, with the little lock shown in the corner of your browser). A new paper highlights not only how this works, but also how there's a company selling the technology to governments to use. Of course, to make it work and be an effective man in the middle, you need a certificate authority to grant you a fake certificate -- but there are some fears that gov'ts could do this by force or by trickery -- and hackers could certainly do it by trickery. The Wired article above quotes people at both GoDaddy and VeriSign insisting that they've never issued fake certificates to the gov't, but it is suspicious that a company is selling a device to gov'ts to do exactly this. The real problem is in the basic implementation of SSL, which right now involves too much blind trust. Apparently, the EFF is working with some security researchers to make some suggestions on ways that this could be fixed.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: governments, security, ssl, surveillance
Reader Comments
Subscribe: RSS
View by: Time | Thread
[ link to this | view in chronology ]
Re:
This way verisign is not necessary.
[ link to this | view in chronology ]
Re:
Perhaps Google and others can offer webservers the opportunity to identify themselves with credentials and to allow web browsers to know who has been personally identified (ie: with ID cards) and who hasn't.
For there to be like two or three authentication servers seems like a bad idea, anyone should be able to start their own authentication servers and allow anyone to implement them in browsers.
[ link to this | view in chronology ]
Re:
This isn't a problem with the SSL technology, per se. It's a fundamental issue in any system where parties that are otherwise unacquainted are trying to establish each others' identity. A well-known trusted third party (the certificate authority) is relied upon to vouch for the identity of the site you're contacting. If that third party becomes no longer trustworthy, you have a problem.
This was less of a threat when browsers trusted a half a dozen CAs by default, but now they trust many more. When VeriSign and Thawte had a de-facto duopoly on certificates there was no end of crying and bitching that they charged too much and more competition was needed and more players needed to be added to the market. Well, more players are harder to monitor and less likely to apply good security practices consistently. So congratulations, you got your wish.
We have this problem in society, as well. How do you know that your coworker really works at your company? What if he's just a really great impostor? What if a good friend of yours that you met five years ago was really a criminal on the lam from another country who is faking his identity? How do you REALLY know he's not? Oh, you've met his parents? How do you know they're not accomplices, or actors?
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re:
and this is exactly the point. Harder for the GOVERNMENT to monitor, which is GOOD for those who don't want the government to monitor them.
"less likely to apply good security practices consistently."
But if my browser can cross check a public key with many authentication servers then the user can get far better security.
[ link to this | view in chronology ]
Re: Re: Re:
> and this is exactly the point. Harder for the GOVERNMENT to monitor, which is GOOD for those who don't want the government to monitor them.
No, the government doesn't need to monitor ALL CAs at once.
If they want to sniff some company, just see what CA its e-cert comes from, and you know which CA to negotiate to...
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
@ Doctor Strange
Doctor Strange,
We'd like to invite you to be on our next panel-- http://www.theonion.com/articles/onion-news-network,14177/
Please RSVP at TheOnion.com
[ link to this | view in chronology ]
Now just find someone to implement it for Firefox...
[ link to this | view in chronology ]
Re: Firefox plugin to announce changed SSL certs
[ link to this | view in chronology ]
If such CA is found, you can alway remove their CA from your "trusted CA" store, or if you really want to make sure, put it into "untrusted" store.
And from my understanding, if the CA allow government authorities to do this, you can always claim money from their insurance company(ies). The increased insurance fee can make them pay for their mistake, or if they cannot find one for the insurance service, they lose their CA status.
[ link to this | view in chronology ]
How SSL Works
What do you see? About 100 different “root certificates” from Certifying Authorities that your browser trusts implicitly. Any one of those CAs can issue a certificate for any domain, and your browser will trust that certificate.
What we need is some system for assessing the trustworthiness of these authorities, so that we know how much trust to attach to certificates that they issue. And possibly also putting contraints on the domains that each one of them can certify, to prevent them from overstepping their bounds.
It’s not an easy problem. And the biggest hurdle is going to be users. Most of them don’t even pay attention to SSL certificates as it stands; will they see increased security as anything other than more nuisance dialogs they have to click to make them go away?
[ link to this | view in chronology ]
Re: How SSL Works
I think a system of cross consistency is better. You have multiple public key crawlers and each website simply puts its public key in its robots.txt file. My browser authenticates the public key with multiple public key web crawlers and if they all match then it's a good sign. If one of them doesn't match, it's a problem. Instead of trusting a single CA, trust their collective and consistent message, it's a peer review system in a sense.
[ link to this | view in chronology ]
Re: How SSL Works
The ignorant user issue is one that's impossible to solve. but at least we can have verisign that identifies web servers ensuring they have ID cards and other identifiying information and then authenticates them WHILE at the same time having the same web server putting their public key in a robots.txt file for public key crawlers to search through. Then when my browser authenticates a site it validates that a site has physically registered (ie: shown credentials like identification information) with at least one authority like Verisign (and the cert will say which sites it identified itself with so the user can know) while at the same time the browser can check multiple other CA's that simply look at the robots.txt file for the public key to use those to ensure consistency. If there is a lack of consistency the browser warns the user.
[ link to this | view in chronology ]
OpenPGP Web of Trust
The solution is obviously based on a completely de-centralized system that involves everyone in security. You can trust that your bank's employees hand out the proper certificate on official paper. You can see that it's signed by all of them, and you can inform your browser that it is indeed the signing authority for your money.
The caches would be like current DNS servers at ISPs, middle-men that simply cache the records provided by others. They might even be smart and do some basic sanity checks so they can dump errant records.
[ link to this | view in chronology ]
At work
Just because it is SSL, doesn't mean it is secure.
[ link to this | view in chronology ]
Re: At work
Umm, not quite. That applies to SSL traffic that goes through *their* computers. You forgot to mention that part. I.e just because you work for such an employer doesn't mean they can snoop your SSL traffic on your computer at home.
And that brings up the point of *how* they are able to do this. Well, it's because SSL has been purposely compromised on those employer-owned computers in order to allow such snooping. Not only that, but they may have installed key-loggers, cameras and other snooping tools as well.
And that in turn brings up another maxim of computer security: If you don't have control and physical security of a computer, you don't have security. So, anyone thinking that they had privacy on their employer's computer in the first place was probably being naive. No news there.
[ link to this | view in chronology ]
Re: At Work
http://www.microsoft.com/forefront/threat-management-gateway/en/us/features.aspx
[ link to this | view in chronology ]
Re: Re: At Work
[ link to this | view in chronology ]
Central Point of Failure
There are already some great technologies to avoid the central point of failure we're seeing with trusted ssl certs. One I found out about recently is called Monkey Sphere and it replaces ssl certs with openpgp keys.
So you can choose to trust all of today's default certification issuers, and therefore the sites they sign, or you could remove some of those issuers from your keyring and manually verify any of their signed sites that you do business with.
It would also allow sites to get certifications from any number of organizations and people on the same key rather than using ssl certs where the specification mandates a single certifying authority per certificate.
It's very interesting stuff and they have some tools ready for you to deploy.
[ link to this | view in chronology ]
Extended Validation SSL
Extended Validation SSL (the green bar) is the way for a company to show that they are a legitimate website. Combine the thorough site authentication process with the green url bar and your potential buyers are more likely to complete the shopping cart and return as a loyal customer who feels your site is secure.
[ link to this | view in chronology ]
Re: Extended Validation SSL
For the government, the average cost of a "rigorous and involved background check" for a security clearance can run $15,000 or more. And even though they send out people with badges (to whom it would be illegal to lie to) to conduct the investigations, some bad apples slip through.
So how do you manage to do it for only $995 (your price for an SSL EV certificate) and without badges? If you are really doing what you claim, then why don't you offer your services to the government? It sounds like you could save them a lot of money, especially considering they currently have a backlog of over 350,000 investigations to conduct.
[ link to this | view in chronology ]
HELP THE INDIANS
[ link to this | view in chronology ]