TAG | ssl
“In the latest security lapse involving the Internet’s widely used encryption system, Google said unauthorized digital certificates have been issued for several of its domains and warned misissued credentials may be impersonating other unnamed sites as well.” (more…)
Google engineer Adrienne Felt recently noticed that Gogo in-flight Wi-Fi was messing with the SSL certificates on secure Google web pages.
Her browser showed a problem with the HTTPs connection, and further investigation showed that the SSL certificate was self signed by Gogo’s own untrusted certificate authority. (more…)
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.
It turns out that for several years Safari has failed to properly check the cryptographic signatures on Server Key Exchanges allowing attackers to mount man in the middle attacks against your browser sessions. Anyone with the ability to intercept your traffic could read and modify the data to or from any secure website you visit (of course they can always do it with insecure websites). This would include any WiFi you are using, the local ISP, backbone ISPs, and government entities wherever you might be, or anywhere along the path yo the server you are trying to reach.
This vulnerability impacts both iOS as well as Mac OS X. You can test whether you are vulnerable here.
There is a patch already available for iOS so update your device now!
If you are on a Mac, switch to using some browser other than Safari. Chrome and Firefox are both safe from this particular attack.
If you are on Windows, Linux, BSD, or Android, you would appear to be safe.
Yesterday Google announced that it was updating its certificates to use 2048 bit public key encryption, replacing the previous 1024 bit RSA keys.
I have always found the short keys used by websites somewhat shocking. I recall back in the early 1990’s discussion about whether 1024 bits was good enough for PGP keys. Personally, I liked to go to 4096 bits although it was not really officially supported.
The fact that, 20 years later, only a fraction of websites have moved up to 2048 bits is incredible to me.
Just as a note, you often see key strengths described in bit length with RSA being 1024 or 2048 bits, and AES being 128 or 256 bits.
This might lead one to assume that RSA is much stronger that AES, but the opposite is true (at these key lengths). The problem is that the two systems are attacked in very different ways. AES is attacked by a brute force search through all possible keys until the right one is found. If the key is 256 bits long, then you need to try, on average, half of the 2^256 keys. That is about 10^77 keys (a whole lot). This attack is basically impossible for any computer that we can imagine being built, in any amount of time relevant to the human species (let alone any individual human).
By comparison, RSA is broken by factoring a 1024 or 2048 bit number in the key into its two prime factors. While very hard, it is not like brute force. It is generally thought that 1024 bit RSA is about as hard to crack as 80 bit symmetric encryption. Not all that hard.
The Register has an article on Firefox black listing an SSL Certificate authority.
Certificates and certificate authorities are the underpinnings of our secure web infrastructure.
When you see the lock on your browser, it means that the session is encrypted and the site has presented a valid site certificate (so it is who it claims to be).
That site certificate is signed by one of many certificate authorities.
I see 86 certificate issuing authorities in my Firefox now.
Many of those certificate authorities have multiple signing certificates.
Additionally the certificate authorities can delegate to subordinate certificate authorities to sign site certificates.
Any certificate signed by any of these authorities or subordinate authorities is recognized as valid.
These entities are located all over the world, many under the control of oppressive governments (however you define that).
Certificate authorities can create certificates to enable man in the middle attacks, by signing keys purporting to be for a given website, but actually created and held by some other entity.
There are plugins like certificate patrol for Firefox that will tell you when a site you have visited before changes certificates or certificate authorities. Unfortunately this happens fairly frequently for legitimate reasons, such as when renewing certificates every year or few years.
Some certificate authorities are known or suspected to be working with various law enforcement entities to create false certificate for surveillance.
Here is how it works:
The government has certificate authority create a new certificate for a website.
The government then intercepts all sessions to that site with a server (at national level routers for example).
The server uses real site certificate to communicate with the real website securely.
The server uses the new fake certificate to communicate with user securely.
The server then has access to everything in the clear as it shuttles data between the two secure connections..
It can read and/or modify anything in the data stream.
Firefox is removing TeliaSonera’s certificate authority from the list in Firefox for this reason. Going forward no certificate issued by them will be recognized as valid. This will impact a large number of legitimate websites that have contracted with TeliaSonera, as well as preventing the fake certificates.
There is a lot of controversy about this. What is appropriate cooperation with law enforcement vs. supporting and enabling dictators.
In any case, this is a failure of the protocol. If the browser shows a certificate as valid when it has not come from the real website, then there has been a security failure.
The SSL key infrastructure is showing its age. It was “good enough” when there were only one or two certificate authorities and the certificates were not actually protecting anything of great importance. Now everyone relies heavily on the security of the web. Unfortunately, while it is broken, it is very hard to replace.
In the short term, installing a certificate checker like certificate patrol is probably a good idea, despite the number of false positives you will see.
In the longer term, there is a really hard problem to solve.