The CIA Solves a Non-Existent Problem

by Tim Lee on November 29, 2006 · Comments

This is odd. Apparently, the CIA has recently decided that access to its entire website will henceforth be encrypted using SSL–the encryption standard used by websites accepting your credit card number.

They say this ensures that no one is able to impersonate the CIA website, but that doesn’t make a whole lot of sense. I can’t imagine why anyone would want to impersonate the CIA’s public website. And if they did, SSL is only an effective deterrent if the user manually examines the site certificate, which doesn’t seem very likely.

The other claimed benefit is to prevent eavesdropping on (or tampering with) peoples’ browsing. But that doesn’t make sense either. An eavesdropper could still see the URLs being visited by a user. And since most of the site is publicly available, static content, encrypting it is kind of pointless. It’s certainly good to encrypt personal information submitted by users, but the site was already doing that before this announcement.

Technologically-challenged institutions have an unfortunate habit of judging security using bulleted lists. Throwing more encryption at something doesn’t make it more secure. You have to think about who your attacker is and what he’s likely to be after before you start looking for solutions. In this case, it’s not clear there’s any attacker at all. As far as I can see, no one is trying to spoof the CIA’s public website or eavesdrop on people visiting it. So adding SSL is a solution in search of a problem.

Comments Posted in: E-Government & Transparency

  • Actually, an eavesdropper could only tell that you had an SSL connection open with a certain IP address. They could certainly trace the IP to the CIA, but they couldn't tell which URLs you were looking at (the bit of the HTTP request that requests the URL is encrypted within the SSL tunnel).

    So this does add a layer of 'Anonymity' that wasn't there before. Of course, the CIA can still tell what you're looking at :-)

    Still, it's an odd direction for the CIA to take.
  • Tim
    Thanks for the correction!
  • chuck
    Also, if someones hijacks my DNS and resolves cia.gov to a different IP address, TLS/SSL will inform me of the signature mismatch, so you're wrong here as well.
  • chuck
    Also, if someone hijacks my provider's DNS server and resolves cia.gov to a different IP address, TLS/SSL will inform me of the signature mismatch, so you're wrong here as well.
  • Chuck: That's a good point. I was thinking about a case where someone tricked a user into going to another domain purporting to be the CIA's website, such as cia.com. But I guess this does provide some protections against DNS hijacking.

    Also, if I hijacked your DNS to misdirect you to a bogus CIA website, couldn't I just opt not to wrap the connection in SSL at all? The user would, at a minimum, need to be looking for the little lock icon to verify that the connection was encrypted.

    In any event, it's not clear to me why anyone would want to hijack the CIA's website.
  • But if an agent's Internet connection were under surveillance, just visiting the CIA's website regularly would be enough to arouse suspicion, wouldn't it? I would think it would make more sense to create a totally separate front site--a travel blog, say--and add SSL to that.
  • tom
    Yeah, I seriously doubt that field agents receive sensitive information from CIA.gov. There are more secure, less obvious ways to disseminate information if the agent's computer can be counted on to run a client-side app (and obviously there are a lot of reasons why an agent would only use a secured agency computer for that sort of thing -- keyloggers and tampering with the certificate authorities being just two).

    I suspect this is born of the CIA being used as a pretext for some phishing scams. This approach is pretty much all they can do about it: turn on SSL and issue a press release telling the public to look for the little lock in their browser whenever they think they're visiting cia.gov.
blog comments powered by Disqus

Previous post:

Next post: