TAG | web
On July 2, Google engineers discovered unauthorized certificates for Google domains in circulation. They had been issued by the National Informatics Center in India. They are a trusted sub-authority under the Indian Controller of Certifying Authorities (CCA). They in turn are part of the Microsoft Root Store of certificates, so just about any program running on Windows, including Explorer and Chrome, will trust the unauthorized certificates.
The power of this attack is that the holder of the private key to the certificate can impersonate secure Google servers. Your browser would not report any security alerts because the certificate is “properly” signed and trusted within the built in trust hierarchy.
Firefox does not have the CCA in its root certificate list and so is not affected. Likewise Mac OS, iOS, Android, and Chrome OS are safe from this particular incident as well.
It is not known exactly why these certificates were issued, but the obvious use would be national surveillance.
While this attack seems to be targeted to India and only impacts the Microsoft ecosystem, the larger problem is much more general. There is a long list of trusted certificate authorities, which in turn delegate trust to a vast number of sub-authorities, any of whom can trivially create certificates for any domain which would be trusted by your computer.
In this case the attack was detected quickly, but if it had been very narrowly targeted detection would have been very unlikely and monitoring could have continued over very long periods.
As an end user, you can install Certificate Patrol in Firefox to automatically detect when a website’s certificate is changed. This would detect this kind of attack.
On Chrome you should enable “Check for server certificate revocation” in advanced settings. That will at least allow quick protection once a certificate is compromised.
Update: Microsoft has issued an emergency patch removing trust from the compromised authority.
Researchers recently announced the discovery of an incredibly dangerous bug in the OpenSSL encryption library. That library is used by about two thirds of websites, and many VPNs and other secure communications services.
The problem is in a memory leak that allows an attacker to request heartbeat responses which will contain up to 64KB of memory, and to do so over and over without being detected. This has already been shown to be able to capture the server’s RSA secret key. That is the key used to authenticate communications with the clients, and to encrypt the session keys. Other data could be captured as well, but those keys are really the biggest threat.
An attacker with that key could perfectly impersonate the server, or run man in the middle attacks undetectably.
It is unknown if, or how often, this attack has been run in the wild. It is entirely possible that major players, like national intelligence services, may have known about this for some time, and could have been silently intercepting traffic to certain websites, potentially for over 2 years. We just don’t know. There is a call for researchers to set up test sites to detect this activity going forward, but there is no way to know if it happened in the past.
The solution is non-trivial. All affected services need to install the recently available patch to fix the underlying problem. They then need to address the possibility that their keys have been stolen. All server certificates need to be revoked, so clients will know to reject them, and new certificates created and distributed. This is likely to take time, and many sites will be very slow to respond.
For years I have been telling people to be especially careful when they venture into the dark back alleys of the Internet. My thinking was that these more “wild west” areas would be home to most of the malware and other attacks.
Dark Reading analyzes a Cisco report which says that online shopping sites and search engines are over 20 times more likely to deliver malware than counterfeit software sites. Advertisers are 182 times more dangerous than pornography sites.
So, I guess I need to change my tune. Be careful when you are going about your daily business, and have fun in those dark alleys!
Their Asha and Lumia phones come with something they call the “Xpress Browser”. To improve the browser experience, the web traffic is proxies and cached. That is a fairly common and accepted practice.
Where Nokia has stepped into questionable territory is when it does this for secure web traffic (URLs starting with HTTPS://). Ordinarily it is impossible to cache secure web pages because the encryption key is unique and used only for a single session, and is negotiated directly between the browser and the target website. If it was cached no one would be able to read the cached data.
Nokia is doing a “man in the middle attack” on the user’s secure browser traffic. Nokia does this by having all web traffic sent to their proxy servers. The proxy then impersonate the intended website to the phone, and set up a new secure connection between the proxy and the real website.
Ordinarily this would generate security alerts because the proxy would not have the real website’s cryptographic Certificate. Nokia gets around this by creating new certificates which are signed by a certificate authority they control and which is pre-installed and automatically trusted by the phone.
So, you try to go to Gmail. The proxy intercepts that connection, and gives you a fake Gmail certificate signed by the Nokia certificate authority. Your phone trusts that so everything goes smoothly. The proxy then securely connects to Gmail using the real certificate. Nokia can cache the data, and the user gets a faster experience.
All good right?
The fly in the ointment is that Nokia now has access to all of your secure browser traffic in the clear, including email, banking, etc.
They claim that they don’t look at this information, and I think that is probably true. The problem is that you can’t really rely on that. What if Nokia gets a subpoena? What about hackers? What about accidental storage or logging?
This is a significant breaking of the HTTPS security model without any warning to end users.
This article on The Consumerist reports that Capital One provides different car loan rates based on the browser you use when visiting their site. I suspect that there are some strong demographic trends among the users of various browsers. It would be interesting to see if they give different rates to the same browser in different states or zip codes.
Once again, evidence that “they” are using your personal information in way that may not be good for you.