Enabling Secure Business Operations

Removing Trusted Certificates from Android

September 15th, 2011

In light of all the discussions about maintaining a secure posture on trusted certificates, we oftentimes forget about the little guys. In this case, I’m talking about our mobile devices. We tend to forget that these devices are just as vulnerable as our desktop/laptops. Unfortunately, it’s not always easy to manage the certificates on these devices. But if you own an Android device and would like to take a little more control over what your device is trusting, here’s how you can do it.

Remove a CA Cert from Android System
The bouncycastle library will be required, you can grab it here:
BouncyCastle Library

You’ll need the Android-SDK as well in order to utilize ADB. It can be found here if you don’t already have it:
Android SDK
Read the rest of this entry »

Post to Twitter Post to Facebook

Certification Authorities Behaving Badly

August 30th, 2011

edited September 2 with an update on Apple/Safari.

Another case of a certification authority (CA) issuing a certificate they never should have has surfaced. You may remember when we discussed the Comodo incident earlier this year. Now, a certificate issued by DigiNotar has surfaced in the wild, being valid for *.google.com – meaning it could be used to secure any transaction with any Google web property, including GMail. According to this pastebin post, this certificate “is being used in the wild against real people in Iran *right* now.” DigiNotar has issued a statement. Here is some information about why this is bad, and what steps you should take to remove this issuer from your trust lists. Read the rest of this entry »

Post to Twitter Post to Facebook

How does SSL work anyway?

May 28th, 2009

We talk a lot about how SSL is useful, but how exactly does it work? Most systems today use SSL v3/TLS v1 rather than “SSL”, and the nitty gritty details are found in RFC 2246. However, that’s only part of what goes on, and certificate validation and path building (RFC 4158) and X.509 certificates (RFC 5280) are also important. This post is only concerned with the SSL/TLS protocol itself, and when the other RFCs are needed “magic happens.” If you’re interested, I highly recommend reading through the RFCs. I do assume that you’ve got basic certificate and PKI knowledge while reading this. If you don’t, Mike wrote a great series on it.

Read the rest of this entry »

Post to Twitter Post to Facebook

Perspectives – Firefox Extension

August 29th, 2008

A while back I posted about my and others’ concerns about Firefox’s newly handled way of dealing with self-signed or unapproved certificates. It seems the folks over at Carnegie Mellon University have released an extension for Firefox to help deal with this exact issue.

My main issue with my last posting wasn’t directly tied to the error in the security model Firefox was introducing, but simply the intrusion factor of what was taking place, and the lack of information that FF was providing when denying access to the site. The extension provides two primary benefits:

  1. If you connect to a website with an untrusted certificate (e.g., a self-signed certificate), Firefox will give you a very nasty security error and force you to manually install an exception. Perspectives can detect whether a self-signed certificate is valid, and automatically overrides the annoying security error page if it is safe to do so.
  2. It is possible that an attacker may trick one of the many Certificate Authorities trusted by Firefox into incorrectly issuing a certificate for a trusted website. Perspectives can also detect this attack and will warn you if things look suspicious.
      The same is true for HTTPS sites with certificates that contain mismatched domain names (e.g., www.gmail.com uses a certificate for mail.google.com) or certificates that are expired.

      The primary description for Perspective also states:

      A client can automatically make a secure connection to one of several publicly available “network notary servers” located around the world. These servers tell the client:

      1. What key does the server see for host.domain.com right now?
      2. What keys has the server seen in the past for host.domain.com?

      The replies from the network notaries can go a long way toward either providing the user with confidence that the key it received is valid, or that a real threat of a “man in the middle” attack exists.

      The end result is that instead of having applications issue bland warnings, which users often ignore, the application can either skip the warning if notary data indicates that the key is valid, or give a very stern warning in the rare cases when an attack appears to be in progress.

      This extension does pretty much exactly what I wished Firefox would have done with the new policy from the beginning.

      Link to the project: HERE

Post to Twitter Post to Facebook

Mozilla’s Firefox 3 New SSL Policy – Is This The Right Way?

August 5th, 2008

Many people have been praising Mozilla’s Firefox 3 ever since pre-beta. I can easily throw myself onto that band wagon, but there is one feature that has been causing a little commotion, and I again can easily agree with the commotion.

Firefox 3 (FF3) limits usable, encrypted (SSL) web sites to those that have an approved digital certificate from an authorized vendor of Mozilla’s choosing, making it so you have to pay to be recognized. What’s the big deal?

When you visit an encrypted site in FF3, and that site uses a self-signed or simply unapproved certificate, FF3 doesn’t immediately show the page. Instead, you are greeted with what, at first glance, would seem to be an error page.

FF3's self signed cert error page

FF3's self signed cert error page

In order to move beyond this page and actually continue to the site as intended, you need to process through 4 clicks to add that site as an “exception.”

The use of a certificate is for SSL – which has two main purposes – allow connections to be encrypted so they can’t be snooped, and allow sites to be authenticated so they can’t be impersonated. Advocates of Mozilla’s policy seem to only focus on the latter, stating that a self-signed certificate has no value for authenticating a web site. The real concern is that snooping is much more of an easily attainable threat than impersonation. So, it is much more valuable to have a self-signed certificate than nothing at all, but doing so puts FF3 users at an inconvenience.

This, to me, sounds like it is blatantly going against the notions of Net Neutrality, something that has been fought to keep open for ages. Something like this completely discriminates against those not willing to purchase an “approved” certificate.

Post to Twitter Post to Facebook