Which may be another point, if the security is so complex that its above the average layman, how do we know what to trust?

Damn, you’re making me think about this stuff more than I have in a while! (That’s a good thing though.)

It’s point (2) that I’m most interested in, and most nervous about. If it is possible to effectively use DPI for these kinds of interceptions, then I (hope?) expect we’ll see some quick innovations in security. At the same time, it’s my understanding that systems like the Diffie-Helleman key exchange were developed with the assumption that someone was listening in; are you suggesting that these exchanges are as vulnerable as any other mode of exchange? (Encryption is still a weak point; I have about 4 books beside me to read about it in far more depth, so sorry if this is a silly/stupid question.)

http://www.radware.com/Products/ApplicationDelivery/AppXcel/default.aspx

RadWare AppXcel

The vendor claim for this product is this:

Security Services
Featuring client- and server-side SSL sniffing, AppXcel provides complete transaction visibility and security of encrypted traffic, preventing SSL virus tunneling while guaranteeing end-to-end application-smart performance tuning for web-enabled, SSL-based applications.

AppXcel provides client- and server-side SSL security by expanding the capabilities of all network security devices to scan SSL encrypted traffic. AppXcel peels off the encryption from in-bound and out-bound SSL traffic, providing a clear-text copy to network security devices so they can detect real-time hacking or information leaks.

There’s three potential ways they are doing this, and two of them are troubling:

1) Brute forcing the key. Possible but unlikely. Requires a lot of horsepower and as keys continuously improve, this technology will be left behind.

2) Man-in-the-middle key exchange interception. Technically feasible. But is it being implemented. I have no idea.

3) Preloading of corporate keys to the device to protect corporate information. This is benign as it becomes part of the corporate security apparatus. Could not be used against encryption keys generated outside the corporate network (like your bank for example).

I’m not surprised that you’re none too impressed with OSI – one of my tasks will be to take the work on DPI that approaches it from an OSI model and then try to translate it into TCP/IP in a way that is accessible to non-technical readers. OSI is convenient because literature from vendors is often in the OSI format, and I generally find it easier to explain OSI over TCP/IP. Still, it’s important to shift discussions into the terms of how networks are actually realized, rather than in highly theoretical and relatively unpractical terms.

Thanks for the vendor names – it’ll help when I really take up the hunt in a bit!

I found a patent application by Microsoft, but they are looking at applying a rule before the traffic is encrypted, and then handling the encryption. So this would be gateway level encryption, not software level encryption, and it happens at the wrong point of the communication stream.

Its really hazy as to what the actual capabilities are. But many encryption schemes are vulnerable to a “man-in-the-middle” attack (even Quantum encryption! http://en.wikipedia.org/wiki/Quantum_cryptography#Man_in_the_middle_attack)

Since your ISP (or school, or business) has network devices that are increasing in intelligence, the man-in-the-middle capability is being built into the network. A few years ago, it required someone to hook up a computer and manually track the communications. This is where things will get really interesting.

Oh and I consider the OSI model irrelevant. Did you know that TCP/IP predates the model and is not actually OSI compliant? (IPX/SPX was supposed to be OSI compliant as it was developed with the OSI model in mind).

After layer 3 or 4 (somewhere around there), the OSI model is irrelevant in real world TCP or UDP/IP communications.

But yeah, before DPI, we only concerned ourselves with ports or other header information when applying security policies. Hence the new Deep Inspection term. But we always used network sniffers to see all packets. That required human eyeballs and was in a real sense Deep Packet Inspection. We were (and do now) inspecting the packets. Its how you look for bad or malformed packets. OR look for people using plan test passwords when logging into their mailboxes…

I’m actually not totally in agreement that ‘deep’ packet inspection isn’t appropriate. As I understand it, most manufacturers are pushing their devices (in PR) as using the OSI model; per that, the ‘deep’ analogy works reasonably well. It’s only really once you move to ‘real world’ understandings of how packets move that ‘deep’ becomes somewhat silly. That’s at least my initial thought – I’m sure you can correct it if I’m out to lunch *grin*

It’s interesting/bit worrying that they’re talking of decrypting traffic. At the moment, as I’m sure you know, devices can identify particular encrypted traffic (presumably with the intent of them mediating it – Skype comes to mind, as does a Bittorrent connection); it gets at the application, rather than the content. At the moment, however, particular applications and modes of encrypted traffic are identified using application traffic heuristics (i.e. the pattern that suggests a Skype session, traffic types typically associated with BT, etc.)

Actually grabbing keys…that’s certainly something I hadn’t really thought about. What vendors are using the decrypt/encrypt talk? Have links to white papers?

It wouldn’t surprise me if the following point hasn’t occurred in your recent “nuanced thoughts.”

As I commented over at P2PNet, the concept of a data packet as “sealed” and needs to be opened is flawed. The envelope containing the packet is transparent. What is inside is readily visible to anyone or anything. (Hence the flaw in the really unfortunate name “Deep Packet Inspection”. Its not that deep.)

Even encrypted data is in a transparent envelope. Its use or need is similar to the ciphers used by the military over radio waves. Anyone can capture the broadcast, but if you don’t have the key, the content is meaningless.

Which does bring up a frightening concept (even to me). Newer DPI appliances are claiming to have the capability to decrypt packet streams and apply the optimizations to them. This is a hazy area at the moment where vendors claims and real world application are two different things. It does have real application on the corporate world, as encrypted traffic still needs optimization on congested links. At the moment this is the one weakness in traffic shaping. The corporate world is where most of the demand for SSL shaping is coming from.

For consideration purposes, it could very well be possible to intercept the Key exchange between two data points, and then use those Keys later to break into an encrypted stream.

If that is already or eventually becomes true, then we have a true DPI device, with far reaching consequences in terms of expectations of privacy.

Now I’m certain I have to pay attention to you.