Iran forged the wrong SSL certificate
daemonology.net
daemonology.net
1. 47% of the top 1,000 web sites include google-analytics.com
2. 69% include a remotely loaded web analytics solution
3. 97% load something remotely
If you can attack any of these you get access to a very large number of web sites and can inject arbitrary code. Clearly forging the SSL certificate for SSL loaded remote JavaScript is one way in, another is an attack on the DNS of non-securely loaded remote JavaScript.
At the time techcrunch.com loaded 18 different JavaScript elements remotely. Attacking one would allow a complete site takeover using JavaScript. And those 18 elements could easily have been loading other elements so that attack could have been done through a third-party.
A quick survey in the UK shows that the banks HSBC, Lloyds TSB, Royal Bank of Scotland all load third-party JavaScript on the secure page used for online banking login. Barclays look like they are not, but in fact the domain they are using for one piece of JavaScript is a CNAME for a third-party.
Why I use NotScripts: the extension lets you enable JS temporarily or permanently for a particular website with just a mouse click. As well, at the same time, you can do the same thing for any third-party JS because it presents you with a list of them. So you can enable jsquery and disable google-tracker at the same time.
It's much easier than navigating the menu system to add an exception to the list of blocked sites for each time you just want to read a PDF, for example. That's the main use-case for me.
Happily, my bank doesn't load Javascript from anywhere else.
Not only that, but I was surprised how much paranoia-induced plugins like NoScript and RequestPolicy induce paranoia themselves. And not entirely without cause, either: sites that load 5 different analytics systems are not uncommon, and I've seen 10 different ad providers on a single page.
Then, the only resource loaded form Google's servers is http://ssl.google-analytics.com/__utm.gif, and that's just loaded via a new Image(), so even if you MITM that resource request, it doesn't execute as a script or anything similar.
Moxie Marlinspike pointed out that it was his script 'sslsniff' that the hackers downloaded to carry out the attack. They didn't even change IPs from the one they used to download 'sslsniff' to the one used in the attack. The lesson: this could have been carried out by a script kiddie.
The head of security companies implying that hacking attacks must be caused by a state actor, simply because they don't understand the attack, creates a frightful prospect for the future of world security. Take these claims with a grain of salt. So long for 'sophisticated state actors'.
Diginotar haven't (AFAIK) released even a partial list of affected domains, other than admitting that there were quite a lot of them.
[Edit: Certainly looking through the list of Trusted Root CA certs on this machine I have no idea who 95% of these organisations are - I also have a certificate installed by a proxy so it can intercept any SSL traffic and inspect the contents].
The reason browsers have the crazy PKI model is that browser SSL/TLS has to scale to the entire Internet and allow new sites to come online with only days or hours or minutes of advanced warning.
But you have to admit the general default for SSL is the PKI implemented in web browsers. Even too often in non-web applications, unfortunately.
I am very partial to the Perspectives[1] solution. I wish it would gain more wide-spread support...
Browsers won't run without the Verisign/Thawte CA system. That's not an SSL/TLS problem; that's a browser problem. Browsers exist in a complicated ecosystem involving banking and credit cards, cooperation between hostile software vendors, and the most massive installed base of users in the history of the world.
Don't conflate the problems that browsers have with the attributes of the SSL/TLS protocol. If you need to create an new kind of encrypted transport between two endpoints on the Internet and choose almost anything other than SSL/TLS, you might as well write your own block cipher while you're at it.
I am not a fan of the HTTPS/TLS CA system. You know I'm not.
I am a "fan" of TLS, as much as anyone can be a fan of a protocol. Most if not all of the smartest crypto protocol people in the world have taken shots at TLS. Roughly once every 3-5 years, one of them finds a new vulnerability in TLS, which, when fixed, makes the protocol stronger. That's gone on for roughly 15 years now, making TLS the soundest cryptosystem available to developers on the whole Internet.
You don't like TLS. I get it. You think TLS is too complicated, that it has too much negotiation and too much statekeeping to reason about its security. I think that's a reasonable position to take.
You used to advocate that people write their own encrypted transports to avoid using TLS. You don't do that so much anymore. When you used to advocate that, I yelled about it, because you were wrong. Predictably, when people† write their own encrypted transports, they make grave errors that cause their cryptosystems to blow up.
Now you advocate that people use things like spiped, your new encrypted transport. That's fine too. I'm not recommending it, but wouldn't flag it if I found it on an engagement.
There you have the entirety of our engagement on the issue of SSL and TLS. Note how the Internet trust model doesn't factor into it? That's because we agree on that issue and there is no reason for us to argue about it.
† never mind.
Yeah, but to 99.99% of people out there, the existing CA system is an integral part of TLS. Every time you tell people to use TLS, you're (inadvertently) encouraging them to trust the certificate authority structure.
You have to weigh up the pros and cons I agree. However, do you need that like button which works by including javascript from facebook.com, or can you live without it? Even better, can you do something alternative which allows you to have a like button, but without including third party script?
How about create a JavaScript library that sandboxes execution of third-party scripts by loading them in iframes based off of a different domain? This would allow site owners to embed Google Analytics or FB Like buttons without worrying about the third-party scripts getting compromised or becoming malicious.
E.g. search for iframe in http://developers.facebook.com/docs/opengraph/
Edit: I think I may have misunderstood you. Did you mean embed an iframe and using postMessage to control it?
Now, if you want to add the XFBML version of the like button, you'd have to embed Facebook's JavaScript SDK script (https://connect.facebook.net/en_US/all.js) to your site. If connect.facebook.net ever gets compromised via a fake SSL certificate, your site will also be compromised.
Instead of letting third-party scripts run on your main site, it may be safer to let them run within an iframe based off of a different domain so that a compromised third-party script doesn't compromise your main site.
There has been some work done in this direction. I don't know how active the project is, but it's called ADsafe (http://www.adsafe.org/). It's a subset of regular JavaScript and doesn't allow access to global variables or the DOM, instead giving access to an ADSAFE object to limit the access of the script.
ADsafe makes it safe to put guest code (such as third party scripted
advertising or widgets) on a web page. ADsafe defines a subset of
JavaScript that is powerful enough to allow guest code to perform
valuable interactions, while at the same time preventing malicious or
accidental damage or intrusion. The ADsafe subset can be verified
mechanically by tools like JSLint so that no human inspection is
necessary to review guest code for safety. The ADsafe subset also
enforces good coding practices, increasing the likelihood that guest
code will run correctly.
- Global variables: Limited access to Array, Boolean, Number, String, and Math is allowed.
- Dangerous methods and properties: arguments callee caller constructor eval prototype stack unwatch valueOf watch
- Date and Math.random: Access to these sources of non-determinism is restricted in order to make it easier to determine how widgets behave.Until this incident DigiNotar seemed trustworthy.
This project is in its infancy, so get involved, set up a Notary, contribute on GitHub.
This is not the common case. There was a very similar incident with Comodo in March, and they weren't removed. This is because Comodo certifies some non-negligible portion of the internet (between 1/4 and 1/5th of certificates), and so removing them would break a lot of things.
The same is true for VeriSign, Thawte, Comodo RAs, Geotrust, Equifax, etc...
I don't trust any of these parties, and yet I kept them in my trust DB for years, because without them the internet was unusable.
What Convergence aims to do is make trust agility even easier than it was for DigiNotar, which itself was unusually simple for the CA model. It also aims to invert the trust relationship, and put trust decisions fully in the hands of the client.
Right now, I trust the browser/OS vendors with the ability to black-list individual CAs (or white-list, as the case may be). In the "trust agility" model, I just have to choose somebody else I trust, right?
Maybe as a technical person who spends time in the security world, I can figure out who that should be, but isn't the average person going to find themselves in the same situation (trusting the browser/OS provider)?
Perhaps the better way to phrase this question is thus: How does this prevent 1/4th of the SSL Internet from going down when Comodo gets hacked?
Trust agility ensures that clients have the ability to make these trust decisions easily. A client does not necessarily have to be a user, it could still be the browser/OS vendors. For details on how Convergence works, in order to answer your question of how it prevents 1/4th of the SSL internet from going down when Comodo gets hacked, the best reference is (unfortunately) still the presentation: http://www.youtube.com/watch?v=Z7Wl2FW2TcA
Thanks for taking the time to educate me.
I really, really hope this catches on and gets built into browsers...
I don't understand - if you are uncomfortable loading the GA javascript into your pages when users are using https to visit your site, why are you ok with loading the GA JS when visitors are using http?
Or is it implied in here that the analytics is used on http only pages because the sensitive pages on your site are https only? In other words, you are only using GA on non-sensitive portions of your site?
Now, when a browser is used to go to a website using SSL it will ask that site for its cert, which contains the public key and the digital signature from the CA. If the cert is signed by a CA that the browser trusts then the browser in turn trusts that specific cert. The browser then uses the public key to encrypt a message to the site containing information for encrypting return transmissions to the browser.
The point being, all CA's are on an equal playing field, and fully trusted. The moment any one CA is no longer fully trustworthy or the moment its private key is no longer secure the whole system fails.
It doesn't have to be that way. SSL/TLS libraries, for the most part, only verify that the certificate chain is properly signed all the way to the root. That doesn't mean the browser trust system is limited to that! After certificates are verified, it should be straightforward to apply additional policies, such as "Colin Percival does not trust certificates from this CA with the exception of these three domains which unfortunately rely on it, but Colin and all his friends are also helpfully monitoring the fingerprints of the known good certs for those domains".
You don't need permission from the IETF, IANA, Mozilla, or Verisign to build this. You just have to build it and get people to use it.
Moxie Marlinspike is working on an idea similar to this at CONVERGENCE.IO.
http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-ce...
but I think they just pushed new minor versions with them removed anyway.
Utilities > KeyChain Access > System Roots (left) > All Items > find "DigiNotar Root CA" > right click, get info > expand Trust > When using this certificate, never trust
You teach people to fear one thing, and in this case, they leap head first into something even further beyond their comprehension. They need to start teaching Internet 101 classes in middle school.
Which, in this case, was the right thing to do.
As per my understanding the browser simply trusts all certificates issued by a trusted issuing authority, so how would you revoke a single certificate?
1. You add the certificate to your Certificate Revocation List.
2. You pretend that people will check the CRL before trusting the forged certificate, ignoring the fact that some clients only check for updates to the CRL periodically and most don't check CRLs at all.
In short, it doesn't really work.
But according to https://www.google.com/adsense/support/bin/answer.py?answer=... AdSense isn't available over https, so this specific problem of forged SSL certs does not apply here. But if you embed non-SSL code in your httpS page (and I assume that most users just ignore the message that would popup in this case, alerting them that non-SSL code is loaded into the "secure" site) there's no need to do that: just do the MitM attack.
So sure if they could reroute the request to their servers evil things could be done. But they can NOT. Or am i missing something ?
It's 'local', since you somehow need a way to intercept the traffic and there's a limit to the feasibility. Let's say this is 'local' for everyone in Iran.
But going for the certificate Colin suggests broadens the attack quite a lot: Instead of being able to server your own version of GMail/intercepting mail traffic you're now able to inject Javascript into what? 60% of the websites of the net? Basically everyone using Google Analytics now silently serves your code and the browser runs it without warnings.
So local/global is orthogonal to this impersonation 'improvement'. Even if you do this (somehow tricking a CA) yourself in the internet cafe of your choice, you would make the attack so much worse if you don't target a single service anymore and inject your code into as much content as possible.
The government almost certainly controls all internet traffic entering or leaving the country at the ISPs, and could intercept and/or redirect it as necessary.
* Force every ISP/Telco within their borders to add fake google.com entries to their DNS servers.
and/or
* Force every ISP/Telco to transparently proxy all DNS traffic and provide fake replies for google.com queries
You can even make it easier:
Just hijack IP routing at the borders, such that IP traffic to 209.85.149.99 (and all other google networks) are not routed to the real google servers on the internet, but their own malicious filtering proxies.
Even without involving the ISPs/Telcos, they could transparently hijack and proxy you, for a whole country it might be a rather big task though, but here's what you do:
* Find all the cables carrying internet traffic in/out of your country.
* Bring a shovel, dig up the cables.
* break the cables.
* hook up the cables to your transparent proxy/filtering machinery.
Done properly, all everyone would know know was some lights flickering in the few seconds the cables were broken.
No browser wants to be the one which doesn't work with someone, somewhere's bank, so once you're on one list, you tend to get added to all of them; and it becomes nigh-on impossible for marketing reasons to remove anyone from the list ever.
15 years later, browsers have 80 CAs and 200 certificates built-in.
I'm not sure having a central authority would be practical, but the approval process and audits need to be more thorough to find the type of security problems that DigiNotar and Comodo had.
This is not an anonymous argument. If you were sitting next to me, I'd be, right now, arguing that you should not publish this article because it will only cause harm overall.
What's next? "Why terrorists are stupid and what they should do to cause maximum damage"? How will you feel when the Iranian government does implement your kind suggestion?
I've not lived in a dictatorship, but my parents have, and from their stories, I gather that most of the smart people in a dictatorship do not really want to help the regime, but they have to because otherwise their lives or their families' lives and careers could be destroyed.
By pointing out exactly how they should do it, this article removes the wiggle room of plausible deniability that "we didn't know there was another way to do it".
Or it's the difference between knowing the ingredients to Coke vs. the recipe.