Is Privacy in Browsers a Lost Battle?
Here’s a little story. Back in 2011, some Iranians hacked DigiNotar CA-signed Google and other sites, hacking hundreds of thousands of people in a state-level attack. I think that the only difference between Iran and every other country in the world is that Iran needed the hack, and everyone else just has a CA they can use for such purposes.
Now, how did the world even learn about it? From Google Chrome, which pins Google-certs, and reported the mismatch back to Google.
Suddenly, the world faced another problem: how do we kill these illegal google.com-signed websites in Iran?
In theory, there are options like Certificate Revocation Lists (CRL) and OCSP. CRLs don’t work because of the file size. A browser will likely fail if it has to download a gigantic file and keep it updated. OCSP browsers validate the cert through a separate request to an OCSP responder, which is an idiotic idea, due to (1) privacy (2) single point of failure (3) external dependency in your connection creation logic. So the question is what should a browser do in case OCSP was not avl? The only answer is to fail soft.
To resolve the problem, the DigiNotar root was removed from the trust chain. Then, new ideas came out or maybe old ideas re-emerged- I am not sure. But it was clear that if a CA were to get hacked, they would need a way to manage the situation without releasing Chrome and going out of business.
Then came OCSP-STAPLE and OSCP-MUST-STAPLE. These are mechanisms in which the application server can go to the CA, get the OCSP and provide it as a part of TLS header. For it to work, a particular extension must be activated in the certificate.
Here is the trick:
Since I have been looking at MITM attack vectors and what it takes to set them up, it is clear that today, any valid public CA can sign for any domain. This includes the multitudes of government CAs:http://pki.treas.gov/crl_certs.htm
Or you can just install a CA on victim’s computer or phone and terminate the connection on a proxy of your choice: either sslsplit or mitnproxyhttps://mitmproxy.org/ or a tool that I could write in few hours. In Safari, it’s impossible to get the actual CA that signed the request.
So the only technical solution is SSL Pinning. Which is another way of saying, I don’t trust the CA system, and I am matching the actual signature.
We can do this in a native app. But it is not possible in a browser. And by the way, if its such a bad idea why is Google doing for their own certs?
Coming back to the OCSP Must-Staple, we want to make sure that the browser is connecting to a known server, and I would like the browser to fail in case the cert is wrong or revoked.
OCSP Must-Staple will take care of the revoked certs. And we are getting to a world that could have revocation, greatly improving security and privacy along the way.
Here is an example of a response:
Now take a good look. This is a response from GlobalSign to OCSP Req. Take a good look. Do you know what’s missing there??
Hint: the thing that SSL is all about. The Common Name.
What does that mean? Anybody with a CA trusted by the victim’s browser can issue a new certificate which the browser will not fail, or produce a warning on, and MITM continues to live and prosper.
Of course, I understand that sometimes, a web provider will replace a certificate, a certificate will expire and need to be replaced.
Well, just like I have the responsibility to manage my cert, and there could be a way to supply two responses: old and new, and prove ownership of this first to update the browser to recognize the new cert.
@chromesecdev you are crypto engineers you can solve these kinds of problems or don’t you want to?
Interestingly enough, the folks that developed SSH never worried about it.
They just tell you:
Zeev Glozman is the founder and CEO of Beame.io, an information security company enabling secure connections between mobile devices.
