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

31–40 of 126 posts

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

#31

Post by jmcqk6 »

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…

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

I'm with you 100%. The reality is, though, your only choice is to not run those devices with access to the internet. A TV should not require internet access to be usable. I won't use an Echo, and IoT devices are isolated to their own internal network without WAN access.

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

#32

Post by pjc50 »

dstjean wrote: post #11
jopsen wrote: post #10

Earlier quoted context omitted.

If you IT department is your adversary you should get a new job. Or at least use a personal device for personal matters :)

I don't think NOT performing packet inspection due to privacy concern is a good idea. (Good security controls should exist over its administration) One reason why organizations use packet inspection is to protect its staffs, customers and vendors from malicious actors who could cause data breaches leading to huge privacy issues. Privacy over Security? The right balance must be found

Of course, this means the packet inspection host and the organisation's internal CA are now great targets to attack. This approach puts all the eggs in a single central basket.

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

#33

Post by jstanley »

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…

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

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

#34

Post by rocqua »

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.

> 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 repurposed into an MitM for surveillance given enough coercion. However, I don't think this applies to a network connection between my TV and Samsung.

Once a surveillor coerces me to give them access, I can disconnect my TV from the internet. The same goes for an amazon echo, or a juice press with WiFi. It is different with whatsapp, facebook and internet banking. These are much more essential, so it is more important that it is hard to MitM them even if the user gives consent.

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

#35

Post by rocqua »

jstanley wrote: post #33
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…

> 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-in Netflix support, but I believe the DRM requirements of Netflix require quite a bit of lock-down)

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

#36

Post by dstjean »

pjc50 wrote: post #32
dstjean wrote: post #11

Earlier quoted context omitted.

I don't think NOT performing packet inspection due to privacy concern is a good idea. (Good security controls should exist over its administration) One reason why organizations use packet inspection is to protect its staffs, customers and vendors from malicious actors who could cause data breaches leading to huge privacy issues. Privacy over Security? The right balance must be found

Of course, this means the packet inspection host and the organisation's internal CA are now great targets to attack. This approach puts all the eggs in a single central basket.

IMO relying 100% on the end devices to protect themselves is too risky. Layered security seems to work best. Also I prefer to heavily monitor/secure two appliances/systems than heavily monitor thousands of end devices

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

#37

Post by cesarb »

criddell wrote: post #24
Tepix wrote: post #17

Earlier quoted context omitted.

Your machine (browser) will only accept the false certificates without complaining a lot if you have previously added the certification authority of the attacker to your browsers list of valid CAs.

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.

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

#38

Post by rocqua »

LeifCarrotson wrote: post #13
dstjean wrote: post #11

Earlier quoted context omitted.

I don't think NOT performing packet inspection due to privacy concern is a good idea. (Good security controls should exist over its administration) One reason why organizations use packet inspection is to protect its staffs, customers and vendors from malicious actors who could cause data breaches leading to huge privacy issues. Privacy over Security? The right balance must be found

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.

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

#39

Post by SideburnsOfDoom »

corebit wrote: post #7
drieddust wrote: post #2

Not a very informative article. All it manages to say is that deep packet inspection does not work with encrypted traffic. I think author is not aware of transparent deep packet inspection of SSL traffic. Here is one such product doing it. https://www.sonicwall.com/en-us/products/firewalls/security-...

That’s just a run-of-the-mill MITM privacy violator

Yes, but I don't think the article explains why it is, or will be, "dead". Companies that have them don't want to give them up. What compelling reason would make them? "Employee privacy at work" is not one. Not with the level of perceived threat of malware downloads and trojaned NPM packages.

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

#40

Post by [deleted] »

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.

[deleted]
Post reply on HN