
BlindBox: Deep Packet Inspection Over Encrypted Traffic [pdf] - nnx
http://iot.stanford.edu/pubs/sherry-blindbox-sigcomm15.pdf
======
mindslight
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.

~~~
swordswinger12
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.

~~~
mindslight
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.

~~~
adricnet
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

~~~
mindslight
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.

------
Canada
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.

~~~
cmdrfred
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...](https://media.blackhat.com/bh-eu-12/Jarmoc/bh-eu-12-Jarmoc-
SSL_TLS_Interception-Slides.pdf)

------
mankash666
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.

