What seems like a relatively simple thing in the SSH world, a simple warning about fingerprints changing, you think would be a very invaluable thing in the SSL world as well. The reason this should be important is because of a simple problem, Verisign has the potential to do a lot of things after all they’re the ones left guarding a couple of root name servers (which controls the entire DNS system), they also directly have control over several TLD zones (.com/.net) and to top things off they have their root certificates in every browser out there.
However that’s just the tip of the ice berg, Verisign is also one of the largest providers of snoop services for the US Government, and anyone else able to afford their services, and this is where a warning would come in handy.
If Verisign decided to redirect your traffic from from your website by making their name servers authoritative for your domain and then point your host name to their proxy server which in turn relays your traffic to your proper website, they could. But wait, you’re using SSL on your web-mail so no one can listen in to your passwords and/or emails, right? WRONG! This is where my earlier point about Verisign having their root certificates in browsers comes in, they can issue a new certificate for their proxy server for say “*” (a wild card for any domain/host name/everything) and if you connect to HTTPS the browser will never warn you that you are hitting a different certificate, and that all your traffic is now being proxied, captured, proded, poked and anything else you can think of.
What’s that I hear you say, that it’s illegal to intercept traffic like that, think again, the NSA is doing it to all traffic going across US international borders and have said that any and all is fair game to it. Not to mention the US has some interesting laws that they could force Verisign into doing it, then throw in a gag order for good measure!
So back to my original statement, if browsers cached and checked that certificates haven’t changed, then any kind of interception like this would then cause the user to be warned in an active sense, rather then the passive method of trying to view who issued a certificate.
This then leads to an interesting dilemma for browser developers, if you on one hand state all traffic that goes via SSL/TLS is encrypted and can’t read by others, and then on the other hand it really can, doesn’t that make you liable for making misleading statements?
The guys working on Mozilla software doesn’t seem to think so, nor do they seem to think it is a good idea to actually provide security for their users, they’d rather you lived under a rock and think commercial certificate authorities are such perfect entities. So far I’ve been met by nothing but a wall of silence on their news groups when the topic comes up, and when I filed a bug report, it was hastily marked as invalid.
I’ve said it before and I’ll say it again, I trust SSL in most browsers as far as my credit card number, I certainly wouldn’t be trusting it if I were a Chinese dissident!
Good points.
I’ve changed the bug from INVALID to NEW. Hopefully someone will take notice.
By the way, do you know that anyone can register and post an entry to this blog?
Yes but you get moderated on at least your first post and an email is triggered on all posts for that matter…