Web (in)Security and What Can Be Done

We all like to think that web security is perfect, but we all know better.  You know about spam, phishing, and all manner of malware.  You probably run a virus scanner on your computer.  But what you don’t expect and shouldn’t expect is that the core of our security system would have a flaw.  It does, and has, from the beginning.  What’s more, it’s a known flaw.

How is it your browser decides to trust a site, or to show that lovely lock icon and perhaps a green URL bar when your communication is both encrypted and verified to be to a specific end point?  The simple answer is that your browser provider, Microsoft, Mozilla, Apple, or Google, has made a decision on your behalf that – at least as initially configured – your browser will trust a certain set of authorities– certificate authorities (CAs)– who will validate others.

One such certificate authority got hacked.  Badly.  And because they were trusted by your browser, so might you have been.  Here’s how it works.

  • When you access a URL that begins with “https”, a certificate is sent by that site that is signed by one of the trusted CAs, saying “yes, I agree that this is google.com,” (for example).  If someone gets in between you and Google, they won’t have the private key associated with that certificate, and they won’t be able to validate to your browser.
  • If someone breaks into a CA and gets a certificate for “google.com” (again, for example), and then gets between you and the real Google, they will be able to masquerade.  It doesn’t matter which CA it is, as long as your browser trusts it.  Google needn’t have any relationship with that CA.

This is what happened with DigiNotar.  Not only did they get hacked, but they didn’t notice.  They didn’t have sufficient controls in place to even spot the attack.  That they should have had.

But now there’s something else we can do.  In the Internet Engineering Task Force (IETF), a few folks led by a gentleman by the name of Paul Hoffman have developed an approach where sites like Google can effectively register which certificates are valid for them in an separate alternative authority that we largely trust, the Domain Name System (DNS).  You use DNS to convert site names like ofcourseimright.com to IP addresses like 10.1.1.1.

The group working on it is called “dane“.  Had the dane mechanism been in place in the browser, the attack on Diginotar and Google would have failed, even if Google was a customer of Diginotar (which they weren’t).

When we speak of security we always discuss defense in depth.  That is– never rely on exactly one mechanism to protect you, because at some point it will surely break.  In this case, the attacker needed to (a) compromise the CA and (b) get in between the service and the end user to succeed.  Had dane been in place, atop (a) and (b), the attacker would also have to have compromised Google’s DNS for the attack to succeed.  That’s likely even harder than compromising a CA.

Dane has another potential benefit: in the long run, it may get browsers completely out of the business of telling you who to trust, or it will extremely limit that trust.

This attack also demonstrates that as threats evolve our response to those threats evolves.  Here we understood the threat, but just didn’t get the work done fast enough before a CA was compromised.  I still call this a win, as I think we can expect to see dane even faster than we expected before the attack.

How Much Do You Value Privacy?

People in my company travel a lot, and they like to have their itineraries easily accessible.  My wife wants to know when and where I will be, and that’s not at all unreasonable.  So, how best to process and share that information?  There are now several services that attempt to help you manage it.  One of those services, TripIt.Com, will take an email message as input, organize your itinerary, generate appropriate calendar events, and share that information with those you authorize.

The service is based in the U.S., and might actually share information with those you do not authorize, to market something to you- or worse.  If the information is stolen, as was the case with travel information from a hotel we discussed recently, it can be resold to burglars who know when you’re way.  That can be particularly nasty if in fact only you are away, and the rest of your family is not.

But before we panic and refuse to let any of this information out, one should ask just how secure that information is.  As it happens, travel itineraries are some of the least secure pieces of information you can possibly have.  All a thief really needs is an old ticket stub that has one’s frequent flyer number, and we’re off to the races.  In one case, it was shown that with this information a thief could even book a ticket for someone else.

So how, then, do we evaluate the risk of using a service like TripIt? First of all, TripIt does not use any form of encryption or certificate trust chain to verify their identity.  That means that all of your itinerary details go over the network in the clear.  But as it turns out, you’ve probably already transmitted all of your details in the clear to them by sending the itinerary in email.  Having had a quick look at their mail servers, they do not in fact verify their server identities through the use of STARTTLS, not that you as a user can easily determine this in advance.

Some people might have stopped now, but others have more tolerance for risk.

Perhaps a bigger problem with TripIt is that neither its password change page nor its login page make use of SSL.  That means that when enter your your password, the text of that password goes over the network in the clear, for all to see.  It also means that you cannot be sure that the server on the other end is actually that of TripIt.  To me this is a remarkable oversight.

For all of these concerns, you still get the ability to generate an iCal calendar subscription as well as the ability to share all of this information with friends and family.  Is it worth it?  One answer is that it depends on whether you actually want to enter the information yourself, whether you care about security concerns, and whether you like using calendaring clients.  It also depends on what other services are available.

Another service that is available is Dopplr.  It also attempts to be a social networking site, not unlike Linked In.  Dopplr allows you to share you itineraries with other people, tells you about their upcoming trips (if they’re sharing with you), and it lets you create an iCal subscription.

Dopplr also has some security problems, in that they do not use SSL to protect your password.  They also do not use SSL for their main pages.  They do, however, support OpenId, an attempt to do away with site passwords entirely.  I’ll say more about OpenId in the future, but for now I’ll state simply that just because something is new does not make it better.  It may be better or worse.

And so there you have it.  Two services, both with very similar offerings, and both with almost the same privacy risks.  One of them, by the way, could distinguish themselves by improving their privacy offering.  That would certainly win more of my business.