5 Comments

Summary:

In the event you were too distracted by the festivities associated with the ringing in of the new year and missed the news: the internets are broken (again). To be more specific, what has actually happened is a portion of the trust system that is the […]

In the event you were too distracted by the festivities associated with the ringing in of the new year and missed the news: the internets are broken (again).

To be more specific, what has actually happened is a portion of the trust system that is the foundation of secure transactions on public IP networks has been found to be deficient, mostly due to laziness of services such as Verisign and RapidSSL and lack of knowledge/skill on the part of site owners.

The key to this deficiency lies in how SSL certificates are “signed” (a way of proving their validity). This post is not about the intricacies of public key infrastructure (PKI), so the takeaway is that certificates signed with a hash algorithm called “MD5″ really cannot be trusted anymore and those that are signed with the “SHA-1″ hash algorithm can be trusted (at least to the extent you trust the site you are visiting or the issuer of the certificate). If you are a site owner, make sure your current SSL certs use SHA-1 and insist that your certificate provider/authority (CA) does not use MD5 anymore.

Surfin’ Safari Securely

When you visit a secure site in Safari (or any other modern browser) on your Mac, you should see the familiar “lock” icon indicating that you are, indeed, in “secure” mode.

Clicking on this icon reveals what are, to most users, boring and useless bits of information that you never look at.

As you can see, the US Bank (which is not my bank) certificate uses SHA-1 as the signature algorithm, which is A Very Good Thing™. You can use this technique on any site to verify the signature algorithm.

Well, you can do this in your desktop browser, at least. To my knowledge, there is no way to do this on the iPhone…until now.

Mobile Safari SSL Shenanigans

From my experiments, the only useful bit of SSL information you get within Mobile Safari from Apple is when there is a problem with a certificate.

Yes, that site is Amazon.com, and yes, if you surf to “https://amazon.com/” the way they protect it creates a trust issue (which you can see if you go to that URL in your desktop browser as well).

While that iPhone alert panel is helpful, you still have no way to get access to the certificate information which is where the following bookmarklet can help:

Check SSL

You can drag that URL to your bookmarks bar in your desktop browser and sync it to your iPhone to use within Mobile Safari. I have my bookmarks organized so that “Check SSL” is very convenient to use when I bring up the bookmarks panel.

Now, just surf to any secure site in Mobile Safari, bring up the bookmarks panel and select “Check SSL.” This will bring up a new “tab” with SSL certificate data.

For that example, I went to WaMu’s (again, not my bank) mobile site and used the bookmarklet. You can see the majority of the relevant SSL certificate information (more coming soon) including the hashing algorithm being used.

Unlike WaMu, RapidSSL, one of the certificate providers called out as relying on the outdated hashing algorithm (MD5), itself continues to use MD5-signed certs.

You can use this tool either as a bookmarklet or as a standard mobile page and just enter the hostname of a site to check.

“Check SSL” fills a gap left by Apple in Mobile Safari, one which I hope they fill soon.

I’m definitely interested in feedback on the tool, especially if there are security-related features you’d like to see added to it of if you encounter any issues with it on sites you try it out on.

You’re subscribed! If you like, you can update your settings

  1. Loved the fact that your Blog was insecurely certified! Was that just sick humour or what?

  2. Thank you for making this.

  3. Is this a joke? You’re checking the certificate on a secure site by sending the URL to a 3rd party site over HTTP (a security vulnerability, as it could contain personally identifiable information).

    Clearly, if you need to worry about the local network or ISP you’re using, the last thing you should be doing is basing trust decisions on what an insecure website says, and especially not sending sensitive URLs over HTTP.

    This blog post should be amended ASAP to prevent misleading additional readers.

  4. [...] [...]

Comments have been disabled for this post