Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deep packet inspection is dead, and here's why (2017)

security.ias.edu

Post reply on HN
Print view View original

41–50 of 126 posts

Re: Deep packet inspection is dead, and here's why (2017)

#41

Post by ryukafalz »

rocqua wrote: post #34
ryukafalz wrote: post #29

Earlier quoted context omitted.

The implication here is that you can't trust the devices on your network. IMO that's itself a problem; rather than weakening encryption to enable network owners to analyze traffic on their network (which also harms dissidents who need secure network access), I would prefer a push for more trustworthy devices. The devices we own should be acting in our own best interest; we shouldn't need to treat them as adversaries.

> The implication here is that you can't trust the devices on your network. IMO that's itself a problem; A large part of trust is auditability. And a large part of auditing a device is looking at its communication. What we are kind of running into is the security implications of a debug-interface. Your point about dissidents needing secure access is a strong one. Any way to MitM a connection for audit purposes can be…

>A large part of trust is auditability. And a large part of auditing a device is looking at its communication. What we are kind of running into is the security implications of a debug-interface.

Sure, but you can also look at the device's communication if you have administrative access to it yourself, rather than trying to MITM it. I suppose this could be a vulnerability itself if done poorly, but users have administrative access to their PCs; why should other devices they own be any different?

>These are much more essential, so it is more important that it is hard to MitM them even if the user gives consent.

If the user gives consent, they should be allowed to inspect the connection. The device's UI can make it _very clear_ that they're about to do something dangerous, but it's their device and should be their choice.

Re: Deep packet inspection is dead, and here's why (2017)

#42

Post by fouc »

rocqua wrote: post #25

I'm worried about this development. One the one hand, ubiquitous encryption is simply required for security on the internet. Things like lets encrypt and warning on http are great improvements. On the other hand, the owner of a network has some right to look into the packets on that network. Especially if the owner of the network also owns the end-points of that traffic. My main use-case here isn't corporate networks…

What about an enterprise situation? Would a company allow devices that don't accept their root CA on the network?

Are there enterprise versions of all these devices that we can buy instead?

Re: Deep packet inspection is dead, and here's why (2017)

#44

Post by jrockway »

rocqua wrote: post #38
LeifCarrotson wrote: post #13

Earlier quoted context omitted.

A user has no way of knowing whether a packet inspection will be performed by benevolent actors seeking to protect their security or by malicious actors seeking to invade their privacy. As in the good old post "What colour are your bits" [1] regarding the subject of copyright, the computer is colorblind when it comes to privacy vs. security tradeoffs. You seem to see color, believing compromise for security to be acc…

It could be shown client-side whether an SSL connection uses a locally installed root CA or a globally trusted CA. This way, an employee could see whether their employer is MitM-ing their connection to FB / reddit.com / pornhub / their bank. Based on this, they could complain to their employer for unreasonable MitMing, and serve as a weak detection point for compromise of the company root CA.

You can't trust your client. The IT department will just push a browser that says "you're using the root CA for this connection" while actually using the MITM CA.

Maybe you'll download your own Chrome, but that silently gives you their hacked version. The SHA256sum on their website has also been tampered with. Fine, you say, you'll download the source code and compile it yourself. But the compiler has been tampered with to detect when it's compiling Chromium, and adds the IT department's hacks.

You cannot trust a client you do not fully control.

Re: Deep packet inspection is dead, and here's why (2017)

#45

Post by meuk »

ryukafalz wrote: post #29
rocqua wrote: post #25

I'm worried about this development. One the one hand, ubiquitous encryption is simply required for security on the internet. Things like lets encrypt and warning on http are great improvements. On the other hand, the owner of a network has some right to look into the packets on that network. Especially if the owner of the network also owns the end-points of that traffic. My main use-case here isn't corporate networks…

The implication here is that you can't trust the devices on your network. IMO that's itself a problem; rather than weakening encryption to enable network owners to analyze traffic on their network (which also harms dissidents who need secure network access), I would prefer a push for more trustworthy devices. The devices we own should be acting in our own best interest; we shouldn't need to treat them as adversaries.

Another problem is that nowadays, all devices need internet to do anything. It's ridiculous. Even offline gaming is impossible for most platforms/games.

Re: Deep packet inspection is dead, and here's why (2017)

#46

Post by criddell »

cesarb wrote: post #37
criddell wrote: post #24

Earlier quoted context omitted.

Even with certificate pinning?

For legacy compatibility reasons, browsers ignore certificate pining when the certificate is signed by a certificate authority which was added by the user.

Isn't that a giant security hole? When some shitty anti-virus suite installs a generated root certificate to use for man-in-the-middle traffic inspection, doesn't that open up a big hole for an exploited browser to be installed?

Re: Deep packet inspection is dead, and here's why (2017)

#47

Post by logfromblammo »

rocqua wrote: post #35
jstanley wrote: post #33

Earlier quoted context omitted.

> Really, my issue is stuff on my own network. I want to see what my TV sends home. Same with an amazon-echo, or really any IoT thing. Yet, if they all use SSL and don't allow me to add a root CA, I can't look at what they run. Which is part of why the more paranoid of us steadfastly refuse to own such devices.

I'm hoping for something like 'Right to Repair' or 'Right to Tinker' that'll let us verify more devices are trustworthy. My smart TV (I am ashamed to admit I have one) is really useful. Very little about the idea of a TV with build-in Plex support requires it be totally locked down. Hence it is a buisness decision that could be competed or regulated away. (I was going to make the same argument about a TV with build-i…

Some of us (for whom Charisma is not their dump stat) need to get elected to national legislative assemblies and form technology and engineering caucuses.

Possible items for its agenda:

  - Right to Repair
  - Right to Tinker
  - Right to "Pwn Ur Own"
  - Hardware sellers required to deliver firmware source to buyers
  --- including build scripts
  --- including device-specific signing keys
  --- even for cars and tractors
  - Public APIs required for public-facing services
  - Right to non-backdoored strong encryption
  - Formal requirements for custodianship of PII
  - Formal requirements for security in IoT devices
  - Ban on local monopolies on wired telecoms
  - Definitions for terms used in advertising (i.e. "5G")
  - Establish a separate USPTO regime specifically for computer programs
The lawyers of the Boomer generation that seem to be running the show now are not very well-suited to understand the near-future problems in the technology field. A lot of these problems are better solved by strongarming companies into behaving more eusocially than by attempting a technical solution or starting disruptive competitor businesses.

Re: Deep packet inspection is dead, and here's why (2017)

#48

Post by rcarmo »

There was a pre-2010 burst of interest in DPI in the carrier world, back when they thought it would be feasible to bill different kinds of traffic separately (i.e., beyond zero-rating traffic's to their walled gardens).

That lead to an arms race from core networking vendors to push out all sorts of traffic sniffing and policing with insane degrees of intrusion that made me quite uneasy (I worked in core network planning), and it's been a relief to finally see LetsEncrypt take hold and TLS become de rigeur.

I do have some qualms about the way legal interception can be abused (in general) and occasionally ponder how far those vendors may have progressed in MITM, though - carriers and exchange points are not as secure as they should (in sometimes surprising ways), and back then finding bugs in carrier equipment was relatively frequent.

I wonder what's it like now that most of it are actually Linux VMs running someplace in their ancient datacenters.

Re: Deep packet inspection is dead, and here's why (2017)

#50

Post by rcarmo »

rocqua wrote: post #25

I'm worried about this development. One the one hand, ubiquitous encryption is simply required for security on the internet. Things like lets encrypt and warning on http are great improvements. On the other hand, the owner of a network has some right to look into the packets on that network. Especially if the owner of the network also owns the end-points of that traffic. My main use-case here isn't corporate networks…

It's not just the Alexa-like and IoT devices, it's your entire home LAN that might be indirectly exposed.

The last carrier I worked for was running trials of a "virtual CPE" that replaced your home gateway with a much dumber and cheaper device that effectively extended your home LAN to the local exchange (at least), where the actual isolation, filtering and NAT were performed.

I switched home providers when I left there, and if my current provider ever goes the same route I'll drop my own firewall in front of my LAN.

(Theoretically there is already relatively little isolation between your LAN and parts of the carrier network if you have VoIP or IPTV, but in this case I happen to know who tests that equipment and have a very good idea of what it really does, because I used to work in that team a long time ago...)

Post reply on HN