A major part of the e-rant mission is to expose conspiracies.  Like Michael Jackson’s death, the Great TP Debacle of ’09, and mullets.  But every now and then, I get riled up over something and I just have to set people straight when they’re DOING IT WRONG.  I just came across an article on ThreatLevel that got my dander up due to the hype it infuses into a product that certainly appears to demonstrate wrongness. 

http://www.wired.com/threatlevel/2010/03/packet-forensics/

The device it’s describing is a man-in-the-middle box intended to intercept and decrypt SSL communications.  Author Ryan Singel does a good job describing that it’s a bigger problem than this device demonstrates, but the people he quoted didn’t seem to grasp the big picture.   For the record, I’m a huge fan of Ryan Singel’s – particularly after he posted an article poking the “cyberwar” camp in the eye and incorporating a Beastie Boys video.  Awesome!

But back to the rant:

From what I can gather from the article and the associated research paper, it appears that you drop it inline between your target surfer and an SSL web site.  The device will intercept all communications – when it sees an SSL session being established, it will intercept the communication and impersonate the site, presenting a certificate for the site in order for the device itself to serve as one end of the encrypted tunnel.  Then it will connect to your intended destination and forward all the data from you to the real destination, thereby acting as a proxy for your ssl sessions.  And of course, all that information gets copied out somewhere useful.

Here’s the how-to instruction from the article:

Aye, there’s the rub.  Sounds great, but it certainly seems that the LE or Intel Agency using this box would have to do something really dastardly first, just to get one certificate for one domain.  This just sounds like way too much trouble – not to mention all too easy to get caught doing.  Ask a web site for it’s cert?  Threaten them?  Twist the proverbial arm?  Find somebody with enough spine to blow a whistle, and you’re in a PR shitstorm.  Good luck with that.

If this was MY super-secret-spy-device (SSSD?)…

(There’s no good way to emulate the Wayne’s World dream sequence “deedle-eedle-eedle, deedle-eedle-eedle, deedle-eedle-eedle” finger rain, wavy scene transition, and fade-in with Gary Wright’s Dream Weaver (thanks, FC), so just imagine that bit here, please)

…I’d want to spoof EVERY ssl site with my SSSD.  And EVERY ssl vpn connection.  And everything that was encrypted with X.509 certificates.   And build a big honkin’ appliance that could do this for hundreds of users at the same time (no more efficienct than that, though - I’d like to sell a whole buttload of these).   But you’ll still need a spoofed SSL cert for every site under God, indivisible, forever and ever, Amen.  And Wired says that PacketMotion says that you’d have to convince the site owner to give you a copy of the certificate.  Oh, woe is me!  How would you ever do that for all sites everywhere??  Looks like our desire to take over the world is doomed!

Well, you could try to create them on the fly and sign them yourself with your own CA.  It’d look something like this, for ssl on the web:

  1. Target surfer accesses ssl site in his browser.
  2. SSSD sees ssl handshake start (SYN), and intercepts it (ACKs it on web site’s behalf, not forwarding the packets).
  3. SSSD initiates its own ssl handshake with the website the target surfer was going to, grabbing the website hostname out of the Server Hello during the SSL handshake.
  4. SSSD generates a certificate signing request for the hostname, and signs it.
  5. SSSD completes ssl handshake with website, establishing a tunnel between itself and the website (tunnel A).
  6. SSSD presents the new certificate as part of the Server Hello between itself and the target surfer, and completes the ssl handshake to establish that tunnel (tunnel B).
  7. SSSD accepts input from target surfer via tunnel B, and relays it to ssl website via tunnel A, all the while copying out all the information that’s decrypted between the tunnels.

Steps 4 and 6 are the only things that are materially different between the PacketMotion and my shiny new SSSD.  Where the PacketMotion would present just one crappy spoofed (counterfeit? stolen?) certificate, my SSSD would create it (and cache it for future use, of course).  “But wait,” you say, “then the browser will warn* the user for all ssl sites!!”  You’re absolutely correct… unless, of course, you can get the cert from the CA running on your SSSD into the target surfer’s browser’s trusted root store.  Exploits aside, I wonder how hard it is to get into a major browser’s root store? 

* - how the U.S. Military greatly assisted in destroying any semblance of meaning those warnings ever had by signing EVERYTHING .mil their own damn CA and asking users JUST TO IGNORE IT is another rant altogether, but trust me, one day I’ll get to it.

So it turns out, getting in the Trusted Root Certificate store is a fairly straightforward process, and it’s described reasonably well on technet.  All the trusted root certificate authorities are already downloaded locally for XP.  The process for Vista / Windows 7 is a bit better - it will check with Windows Update to find if a new trusted root has been added and will download it into it’s local store if so.  And if your target is a Firefox guy, the requirements are similar.  Using Chrome on Windows?  Chrome uses the Windows root store.  So does Safari.

But wait, there’s more…  There’s already 104 entities that have a total of 285 certificates accepted into Microsoft’s root certificate program as of November 2009.  Among them?  China Internet Network Information Center and the governments of Austria, Brazil, Finaland, France, Hong Kong, India, Japan, Korea, Latvia, Macao, Mexico, Portugal, Serbia, Slovenia, Spain, Switzerland, Taiwan, the USA, Tunisia, Turkey, and Uruguay.

Yep, there’s the US in there – two of them, in fact.  Both for the Federal Bridge Certificate Authority.  Including one called “Common Policy” that is trusted for web ssl connection usage.   How handy is that for the feds?  Sounds like the government already has exactly what it needs to do this!  – except my Super-Secret-Spy-Device (patent pending), coming soon from RedSpot Systems, an affiliate of Jim Jupiter Enterprises.  All they’d need to do is buy one SSSD (or better – several), clone the Common Policy CA private key, and deploy at will.  Bang-zoom, the US Government owns the internet.  

Then again – so do 20 other countries.  Or should I say, 20 other “future customers”…