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, snooping there makes me uncomfortable.
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.
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.
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.
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.
> 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.
> 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.
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...)
>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.
I share your worry about not being able to inspect communications for various apps and devices purely from a privacy advocacy perspective.
If you own a device, and said device is transmitting data from your environment, you should be able to know what information this device is communicating. It is not enough to trust a company privacy policy.
That can't prevent a malicious device which act like harmless for the most time, but do evil thing on certain conditions are met.
You may found the evidence of malicious act after it has happened, but often it's too late.
If Amazon is directly responsible for Amazon Echo's malicious act, you can blame Amazon. But if the attacker was government spy agency, you're out of lack.
Just don't use these devices which cannot be examined thus cannot be trusted.
It's a major bugbear I have with Android. Now most apps don't by default respect CAs you've added, even via MDM. They get marked differently and can only be used by VPN, WiFi, ActiveSync, and apps that opt in to your custom certs.
So it's perfect time to start a powered-by-community smart device. NLP and voice commands should work offline, without license issues, trained for private use, no constant connection bullshit.
You ostensibly have access to any private key being used to decrypt this traffic, assuming you have access to the device, which I believe is the correct boundary.
I think a more correct title would be "Deep packet inspection should be dead, and here's why"
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).
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.
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.
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)
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)
My workplace has such a MitM gateway where every host has a company root CA installed and every SSL certificate we receive in the browser is an interchanged one. Fair enough.
However, the huge problem is that employees are completely left in the dark about this privacy invasion... only the tech-savvy ones notice and understand it.
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.
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.
This is exactly what has been researched at multiple security companies and productized by Cisco under "Encrypted Traffic Analytics". This is based on research from 2016 that can be found on arXiv: https://arxiv.org/abs/1607.01639
> We conclude that malware's usage of TLS is distinct from benign usage in an enterprise setting, and that these differences can be effectively used in rules and machine learning classifiers.
The Chinese have been doing this for a age now, using pattern analysis to detect firewall avoidance methods. There of course have been developed anti pattern analysis methods and the fight goes on.
What was the name of the company? My management responsibility at work includes networks (by default, we are small) and I always say I don’t have to know/care that you’re using BitTorrent (encrypted/port shifting), so much as there’s an anomaly on the network impacting others. I’d rather have something flagging “hmm this is atypical” based on size/src/dst/ports then try to make rules ahead of time that might miss new trends.
I find this is interesting however I cannot see businesses with important data to protect depending on this when decryption is a far safer option, there is no guessing what it is when on a corporate network you can simply decrypt the traffic and see what it is.
In a corporate environment, managed devices can be configured to force the use of specific DNS settings. The same type of implementation (MITM) could be used to analyse the requests.
That being said, this is at the OS level. An app such as Firefox could still override those settings or provide their own implementation.
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 a couple of times a day.
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.
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.
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.)
How else are you going to catch APT (Advanced Persistent Threat) data exfiltration/control channel traffic?
Assumption 1: Machines on your network are already compromised and fully owned by a sophisticated and extremely difficult to detect rootkit. This is true of every large business. There is always that guy who will click on any link or open the document from what appears to be their co-worker.
Assumption 2: APT tries to disguise their traffic as ordinary web traffic, because anything else is suspicious.
Assumption 3: You have massive legal liabilities if your data is exfiltrated.
Being able to do DPI and pattern matching on all TLS traffic (and firewall off anything you can't DPI) is pretty much mandatory.
There's plenty of this stuff at the US government level for data exfiltration and the fact that ordinary websites can have XSS or other funny business going on. For instance there's EINSTEIN https://www.dhs.gov/einstein.
There's also the opposite of what the initial boon of DPI gave you for egress traffic and instead doing DPI on ingress traffic in places in front of critical applications using things like SSL bump and so on. This seems worse but better in a way, where the DPI is part of the secure system instead of doing a carte blanche decrypting streams (the traffic that the internal secure system receives is in fact the traffic that it is party to instead of just wile e coyote to the universe). It's very hard to detect targeted attack to third party enterprise webapps otherwise.
Corporate MITM devices/proxies are surely in a new business boom. Now we went from lack of encryption to encryption with MITM certificates on questionable appliances running questionable code.
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.
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 »
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:
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:
https://www.grc.com/fingerprints.htm
Though I think the facebook one is wrong (the one I see starts with BD 25 8C for SHA-1)
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.
[+] [-] rocqua|7 years ago|reply
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, snooping there makes me uncomfortable.
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.
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.
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.
[+] [-] ryukafalz|7 years ago|reply
The devices we own should be acting in our own best interest; we shouldn't need to treat them as adversaries.
[+] [-] gnode|7 years ago|reply
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.
[+] [-] jstanley|7 years ago|reply
Which is part of why the more paranoid of us steadfastly refuse to own such devices.
[+] [-] rcarmo|7 years ago|reply
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...)
[+] [-] jmcqk6|7 years ago|reply
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.
[+] [-] hsbaut76|7 years ago|reply
If you own a device, and said device is transmitting data from your environment, you should be able to know what information this device is communicating. It is not enough to trust a company privacy policy.
[+] [-] fouc|7 years ago|reply
Are there enterprise versions of all these devices that we can buy instead?
[+] [-] ezoe|7 years ago|reply
You may found the evidence of malicious act after it has happened, but often it's too late.
If Amazon is directly responsible for Amazon Echo's malicious act, you can blame Amazon. But if the attacker was government spy agency, you're out of lack.
Just don't use these devices which cannot be examined thus cannot be trusted.
[+] [-] k__|7 years ago|reply
[+] [-] amaccuish|7 years ago|reply
[+] [-] hrez|7 years ago|reply
[+] [-] romeisendcoming|7 years ago|reply
Years ago sticking these types of devices on a trusted home LAN would have been unthinkable.
[+] [-] est|7 years ago|reply
[+] [-] api|7 years ago|reply
The best solution to the privacy problem is to do research and exercise consumer choice about what sorts of devices you purchase.
[+] [-] diminoten|7 years ago|reply
[+] [-] znpy|7 years ago|reply
[+] [-] helen___keller|7 years ago|reply
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).
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.
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.
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)
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)
[+] [-] dillz|7 years ago|reply
However, the huge problem is that employees are completely left in the dark about this privacy invasion... only the tech-savvy ones notice and understand it.
[+] [-] mabbo|7 years ago|reply
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.
[+] [-] m-app|7 years ago|reply
> We conclude that malware's usage of TLS is distinct from benign usage in an enterprise setting, and that these differences can be effectively used in rules and machine learning classifiers.
Disclaimer: I work for Cisco
[+] [-] xnyan|7 years ago|reply
[+] [-] jsperx|7 years ago|reply
[+] [-] genpfault|7 years ago|reply
hmmm[1]
[1]: https://everything2.com/user/The+Custodian/writeups/Seek+And...
[+] [-] ajr0|7 years ago|reply
[+] [-] lpcvoid|7 years ago|reply
[1] https://wiki.mozilla.org/Trusted_Recursive_Resolver
[+] [-] rcarmo|7 years ago|reply
[+] [-] dstjean|7 years ago|reply
That being said, this is at the OS level. An app such as Firefox could still override those settings or provide their own implementation.
[+] [-] kijin|7 years ago|reply
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.
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 ;)
[+] [-] rcarmo|7 years ago|reply
[+] [-] adrianratnapala|7 years ago|reply
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.
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.
[+] [-] anonymousisme|7 years ago|reply
[+] [-] jandrese|7 years ago|reply
Assumption 1: Machines on your network are already compromised and fully owned by a sophisticated and extremely difficult to detect rootkit. This is true of every large business. There is always that guy who will click on any link or open the document from what appears to be their co-worker.
Assumption 2: APT tries to disguise their traffic as ordinary web traffic, because anything else is suspicious.
Assumption 3: You have massive legal liabilities if your data is exfiltrated.
Being able to do DPI and pattern matching on all TLS traffic (and firewall off anything you can't DPI) is pretty much mandatory.
[+] [-] xemdetia|7 years ago|reply
There's also the opposite of what the initial boon of DPI gave you for egress traffic and instead doing DPI on ingress traffic in places in front of critical applications using things like SSL bump and so on. This seems worse but better in a way, where the DPI is part of the secure system instead of doing a carte blanche decrypting streams (the traffic that the internal secure system receives is in fact the traffic that it is party to instead of just wile e coyote to the universe). It's very hard to detect targeted attack to third party enterprise webapps otherwise.
[+] [-] robohoe|7 years ago|reply
[+] [-] rcarmo|7 years ago|reply
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.
[+] [-] Scoundreller|7 years ago|reply
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 »
[+] [-] jimmychangas|7 years ago|reply
[+] [-] shaklee3|7 years ago|reply
https://www.youtube.com/watch?v=4Vp8-UONhmM&t=0s&index=17&li...
[+] [-] 75dvtwin|7 years ago|reply
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.
So not only DPI should go away, but also IP address-based blacklisting/whitelisting, tracking/ advertising and so on.
[+] [-] jordan314|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] chrischen|7 years ago|reply
[+] [-] xer|7 years ago|reply
[+] [-] dtagames|7 years ago|reply
[+] [-] suff|7 years ago|reply
[+] [-] suff|7 years ago|reply
[+] [-] yholio|7 years ago|reply
[+] [-] bawana|7 years ago|reply
[+] [-] drieddust|7 years ago|reply
https://www.sonicwall.com/en-us/products/firewalls/security-...