I'm worried about this development.<p>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.<p>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, snooping there makes me uncomfortable.<p>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.<p>A user has no control over an amazon echo. You can't modify the software because the bootloader is locked down. You can't inspect the traffic because it is SSL cert-pinned. Amazon can push updates to it at any time.
All a user gets to do is decide whether it is turned on, and whether it gets a network connection.<p>Really, what I would want to see is the option to install a CA cert on any device I own.
At the same time, that is a terrible idea. Every 14 year old with google is going to find some stack-overflow answer that'll tell them to MitM their TV to do some simple thing.
I think a more correct title would be "Deep packet inspection should be dead, and here's why"<p>Schools, financial institutions, and more will pay big bucks to web gateway vendors who will help them deploy man in the middle attacks on their own machines, employ blacklists or whitelists (even on Google search terms not just at the DNS level), scan traffic for SSNs, and so on. It's not a dead market (quite the opposite, startups like Zscaler are fetching unicorn valuation).<p>It also encourages terrifying but legal behavior for employers like monitoring which subreddits you read or what kind of YouTube videos you watch or how much time you spend slacking off at work.<p>The arms race between security and exploitation isn't likely to stop, and I have no confidence that corporations with sensitive data will willingly take a privacy-granting approach when vendors promise them unmatched security by decrypting traffic.<p>I think the two viable approaches are educating the public that your work machine is not private or looking for lawmakers to step in (but let's be real, that option is unlikely)<p>During my time working for one of these web gateway vendors, I became highly sensitive to what browsing happened on my primary operating system (which had company certificates installed), and what went on my development VM (which I set up myself without corporate certificates)
A few years ago, one of the best managers I ever worked for left to become the CTO of a company doing pattern analysis of network traffic, rather than Deep Packet Inspection. The premise was that most of the internet traffic on your network follows the same typical patterns, but nefarious traffic doesn't. Drop their system into the network and voila, you can start to find the weird things going on that seem out of the ordinary.<p>At the time, I thought that it seemed a bit heavy-handed- just use DPI and you'll get the same results. This article is making me think he was very prescient in the matter.
The author suggests towards the end to analyze DNS queries, but that's on the best way [1] to be encrypted as well (finally).<p>[1] <a href="https://wiki.mozilla.org/Trusted_Recursive_Resolver" rel="nofollow">https://wiki.mozilla.org/Trusted_Recursive_Resolver</a>
Deep packet inspection seems to be alive and well, even outside of corporate networks.<p>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 a couple of times a day.<p>Meanwhile, my country is just beginning to roll out a system that detects the SNI hostname in encrypted connections, in order to block illegal sites that hide behind Cloudflare. Fortunately they can't spoof certificates on the public internet, so users just get a connection error. Too bad Cloudflare supports ESNI now ;)
This sort of development seems good, not exactly from an moral point of view, but from the point of view of long-term reliability of the internet.<p>The IP protocols have some expectation of end-to-end packet delivery. Over time we found ways in which networks could be kept "working" with this requirement relaxed. Except what could be known to "work" was just whatever was tested by the manufacturers of various middle-boxes, making change and development of new ways of solving problems harder than it should be.<p>The less visibility middle-boxes have into what the the traffic is, the less they are able to selectively screw things up and the internet will be more reliable for it.
It's not dead. Encryption has (unjustifiably) pushed the enterprise to install fake catchall certificates on proxies so they can snoop plain-text traffic. (Why anyone would ever think this is a good idea is beyond me.)
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).<p>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.<p>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.<p>I wonder what's it like now that most of it are actually Linux VMs running someplace in their ancient datacenters.
Not related to the core of the article, but it taught me I can pipe random gibberish (such as tcpdump) to the audio output and I am finding it amazing.
Luca Deri, the author of nDPI did an excellent talk on this topic at the DPDK summit in December. The techniques they have to use now to apply heuristics on https is really cool:<p><a href="https://www.youtube.com/watch?v=4Vp8-UONhmM&t=0s&index=17&list=PLo97Rhbj4ceISWDa6OxsbEx2jBPaymJWL" rel="nofollow">https://www.youtube.com/watch?v=4Vp8-UONhmM&t=0s&index=17&li...</a>
I think (and hope), that the next big thing (after https) -- will be VPNs by default.
(and independent from the internet provider service).<p>By default, nobody, and I mean, nobody needs to know ones home IP address, period.
And nobody needs know what sites a person visit or when.<p>So not only DPI should go away, but also IP address-based blacklisting/whitelisting, tracking/ advertising and so on.
This sent me on a spiral of checking for MITM connections on my machine. You can compare the fingerprints of known sites with this list on this site:
<a href="https://www.grc.com/fingerprints.htm" rel="nofollow">https://www.grc.com/fingerprints.htm</a>
Though I think the facebook one is wrong (the one I see starts with BD 25 8C for SHA-1)
Author is dead wrong. Products exist today that perform DPI on SSL streams: <a href="https://www.a10networks.com/resources/articles/ssl-inspection-decryption-cisco-asa-firepower" rel="nofollow">https://www.a10networks.com/resources/articles/ssl-inspectio...</a>
I did not realize that squid could provide false certificates on the fly. The whole business of invalid certificates made people nervous about some sites. Now someone can sit in starbucks with a squid proxy in the middle and harvest everything, regardless of ssl encryption. Looking at the little lock in the URL means nothing to a MITM running squid. Will a VPN protect me by encrypting everything from my machine so that a squid in the middle will be thwarted?
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.<p><a href="https://www.sonicwall.com/en-us/products/firewalls/security-services/dpi-ssl" rel="nofollow">https://www.sonicwall.com/en-us/products/firewalls/security-...</a>