Live data from Hacker News

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

security.ias.edu

51–60 of 126 posts

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

#51
post #48

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 plann…

The other interest from carriers is protecting their media interests.

Slowing torrents or streaming video directly helps maintain their « golden age of double dipping by running data over lines paid by audio/vidéo infrastructure »

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

#52
post #5

The author suggests towards the end to analyze DNS queries, but that's on the best way [1] to be encrypted as well (finally). [1] https://wiki.mozilla.org/Trusted_Recursive_Resolver

DNS queries are monetized by some carriers, who sell the aggregate data to brokers. I was actually approached by one such company a few years back.

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

#53
post #26

Deep packet inspection seems to be alive and well, even outside of corporate networks. My ISP uses the User-Agent header in outgoing requests to guess how many computing devices I have at home, and tries to charge money if it's more than an undisclosed limit. This of course only works for plain HTTP, but there are still enough unencrypted sites out there that my ISP has an opportunity to intercept a request at least…

Where do you live (if you can share the country name, of course)?

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

#54
post #42
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?

Most Internet connected consumer devices don't have separate enterprise versions. The usual approach for enterprises that care about security is to ban them (DHCP server won't issue an IP address and switch blocks all traffic), or segregate them onto a very limited virtual network.

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

#55
post #48

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 plann…

The other interest from carriers is protecting their media interests. Slowing torrents or streaming video directly helps maintain their « golden age of double dipping by running data over lines paid by audio/vidéo infrastructure »

The "policing" bit was actually about doing that. Strategies varied, from smooth shaping to randomly dropping packets to force TCP window resets and drastically lower throughput.

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

#56
post #34

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…

If you actually were to carry out an audit of a device you'd request source code, not the SSL key. If device manufacturers want you to trust their stuff, they need to stop locking bootloaders. Wanting stuff to be SSL-free for auditability is like asking for web pages to be fully renderable on lynx so you can scrape them

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

#59
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…

> On the other hand, the owner of a network has some right to look into the packets on that network.

I don't agree. If you let a guest use your WiFi network for instance, there's no inherent moral right for you to intercept their emails.

However I generally agree with the principle that if you own a device, you have the right to learn what it's doing, and the trend towards black boxes is concerning.

Post reply on HN