Unauthorized SSL certificates put everyone at risk

Google warns of unauthorized TLS certificates trusted by almost all OSes Ars Technica

“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."

The existing SSL certificate authority structure is fatally flawed. Its integrity relies on a huge number of primary and secondary certificate authorities to follow the rules and only issue certificates to the valid owners of websites. Of course many of these certificate authorities are in places where they can be pressured or forced to issue certificates to other entities for other purposes, like surveillance.

In February we saw SuperFish installing it’s own certificate on every computer where it was installed.

In January we saw Gogo Inflight simply self signing certificates, generating errors which were widely ignored.

In July 2014 an Indian certificate authority was caught creating fake certificates for Google services.

In April 2013 Firefox black listed a certificate authority for this kind of thing.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Use VPN to avoid Gogo Man In The Middle vulnerability

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.

This allows them to read all of the supposedly encrypted communications in the clear. That information could include personal, financial, corporate, or other confidential data. It also tends to train users to ignore security alerts, which leaves them vulnerable to any other attacker using the same kind of Man in the Middle attack.

In their response, Gogo EVP / CTO said:

“Gogo takes our customer’s privacy very seriously and we are committed to bringing the best internet experience to the sky. Right now, Gogo is working on many ways to bring more bandwidth to an aircraft. Until then, we have stated that we don’t support various streaming video sites and utilize several techniques to limit/block video streaming. One of the recent off-the-shelf solutions that we use proxies secure video traffic to block it. Whatever technique we use to shape bandwidth, It impacts only some secure video streaming sites and does not affect general secure internet traffic. These techniques are used to assure that everyone who wants to access the Internet on a Gogo equipped plane will have a consistent browsing experience.

We can assure customers that no user information is being collected when any of these techniques are being used. They are simply ways of making sure all passengers who want to access the Internet in flight have a good experience.”

I am not very reassured by this, particularly given their previous history of going above and beyond requirements to support law enforcement intercepts. Even if they are acting in good faith, this kind of action puts all users at risk. Any compromise of the proxy server would give full clear text access to the communications of everyone on the plane.

To protect yourself, make sure you use a VPN service (like Anonymizer) to encrypt your traffic out to an endpoint beyond Gogo’s reach.

Nokia did something similar a while back.

Even certificate authorities can’t always be trusted.

Thanks to the following articles:

Gogo Inflight Internet is intentionally issuing fake SSL certificates - Neowin

Gogo Inflight Wifi Service Goes Man-In-The-Middle, Issues Fake Google SSL Certificates | Techdirt

Gizmodo - Gogo Wi-Fi Is Using Man-in-the-Middle Malware Tactics on Its Own Users

GoGo in-flight WiFi creates man-in-the-middle diddle • The Register

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

More proof that the web security model is totaly broken

Fake Google Digital Certificates Found & Confiscated

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.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Update: Microsoft has issued an emergency patch removing trust from the compromised authority.

Most websites may already be completely pwned by the Heartbleed Bug

Heartbleed Bug

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.

Lance Cottrell is the Founder and Chief Scientist of Anonymizer. Follow me on Facebook, Twitter, and Google+.

Apple SSL vulnerability

Everybody has been talking about the Apple SSL vulnerability, but just in case you have missed it…. 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.

Google upgrades SSL Certs to 2048 bit

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. 

Blacklisting SSL Certificate Authorities

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.