BlindBox: Deep Packet Inspection Over Encrypted Traffic [pdf] | Hacker News Reader

BlindBox: Deep Packet Inspection Over Encrypted Traffic [pdf]

iot.stanford.edu

60 pointsnnx11 comments

The fantastic thing about misguided research ideas is that they go nowhere, bearing endless publications over the years as terminology changes.

The Internet is essentially the manifestation of the End to End principle. DPI is directly at odds with the Internet - if the functionality provided by DPI were actually beneficial to users, it would just be implemented as end-node software.

I'm not sure you're right about that. There are legitimate reasons to criticize this paper (its unclear, confusing security claims, for one) but the basic functionality they build can be used for an IDS, which seems beneficial to users to me.

A skim should clarify the security claims as much as needed - it's a complexifying of encryption schemes in order to accommodate third-party communications escrow.

Any communications-auditing regime relies on detecting and preventing steganography. This can be immediate successful, but is an endless escalation that should cause honest people (ie those who aren't trying to restrict communication) to focus on node security.

While an IDS can indeed benefit end users, its same functionality can be implemented as edge software - either on the nodes, or if worried about nodes being already compromised, then a separate "network processor" domain. The only point of needing a centralized IDS is the centralization - top-down control.

In line with the principle of charity I'd like to point out that your declaration here that network IDS provides only "minor cost savings" is controversial to the point of almost being aggressive towards folks working in information security. In the same vein, I'm simply disregarding the politically charged motive you assign to the technology.

If that was your intent (to start a political argument), then so be it, but if instead of picking a fight you would like to understand the problem space better there are plenty of smart folks on HN and elsewhere who can provide use cases and data ... to say nothing of vendors who will argue from either side depending on what they are selling.

hth, adric

Well, I removed "minor cost savings", because even that is being too charitable. Silicon is cheap, and it wouldn't take much of it to create a separate network processing domain on each node, which would perform all the functions of an IDS on cleartext, but working for the node's owner rather than whomever supplies them network transit. It's also better security with regards to heterogeneous nodes, telecommuting, unenumerable Internet links etc.

Information architectures can't help but being simultaneously technical and political. The original "End to End principle" came out of utterly technical concerns. But codified into a principle, it becomes "political". This is inevitable, because the drawbacks of poor engineering aren't felt immediately, and in fact can be quite beneficial in the short term.

There are of course plenty of vendors selling top-down "security". Right in this paper, they say "the market for such DPI devices is expected to grow to over $2B by 2018". Power tends to centralize until it collapses, which is why we as individuals must work to rebuke such trends.

Actions can be deeply political, weither you acknowledge that fact or not. Do you think providing dpi capabilities to nations like china, where the information is used to tourture and kill people is in any way politically neutral?

Closing your eyes and pretending the politics don't exist dosen't make them go away.

No, I'm sorry, that's not how cryptography works. A 'skim' clarifies nothing - you need precise proofs to understand security. And yes, I'm aware they provide proofs in the extended report, but the adversarial model seems not to model a real attacker particularly well. Here's a concrete question affecting real-world security that is seemingly unaddressed: what does their scheme leak about the frequency of rule matches? Can an adversarial middlebox see that some rules are matched more frequently than others? Are there rule sets for which this frequency information allows the adversary to guess plaintexts?

"as much as needed" being my key phrase. The parties interested in the "benefits" of such a scheme are attackers (governments and ISPs). A scheme touting designed-in attacks just isn't that interesting otherwise.

The old field of electronic payments is littered with papers detailing "secure" systems, but who's only novel contribution was a way of defeating security. They all went nowhere because to any organization that had the power to force adoption of such a scheme, preventing any encryption still offered the best value proposition.

What if the attacker can inject a string that causes a rule match and enables "probable cause" decryption?

Also, MITM attacks against vanilla TLS can be detected by endpoints. That doesn't seem be to the case here, so it makes the trusted third party problem even worse.

I'd reject anything based on this concept.

Also, lets say it detects a 'malicious string' what happens then? Can you force a new handshake with your root CA now as the signer in the middle of a request? I'm not positive but I don't think you can without having the root certificate to begin with. Then what do you do? Just allow the connection to timeout? Sounds pretty bad from a usability perspective.

> Some existing systems mount a man-in-the-middle attack on SSL by installing fake certificates at the middle- box. This enables the middlebox to break the security of SSL and decrypt the traffic so it can run DPI. This breaks the end-to-end security of SSL, and results in a host of issues, as surveyed by Jarmoc.[0]

That slidedeck they cite also notes a number of issues with middleboxes that are unrelated to decrypting the traffic. If the middlebox does not have a fully updated cypher suite then it can essentially do a downgrade attack on all of it's clients. Many of these middle boxes in the past have been found to do boneheaded things like accept self signed certificates as well. A mess all around. I say sandbox the browser and be done with it.

[0]https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-S...

This work is well known in the crypto research circles. Raluca Popa, now a professor at Berkeley was the lead for cryptDb, an encrypted SQL database that can still execute queries.

Reply on news.ycombinator.com