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…
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.
Deep packet inspection is dead, and here's why (2017)
111–120 of 126 posts
Re: Deep packet inspection is dead, and here's why (2017)
#112Earlier quoted context omitted.
> There is always that guy who will click on any link or open the document from what appears to be their co-worker. Which is another reason why DPI is ineffective. The smart malware will identify when its connection is presenting a custom root certificate rather than the expected one and not proceed with its suspicious activities (if not deploy some kind of steganography). Then the same "that guy" will plug his perso…
I'd argue that those examples are a higher bar to hurdle than failing to recognize a spear phishing attack, and can be mitigated by solutions like always-on VPN. And if the malware doesn't work because it has certificate pinning, well, that's a win too. Its not a 100% solution, but you can significantly raise the bar on your attackers.
The theory behind TLS MITM is that it's an extraordinary and dangerous method that could be justified if sufficiently effective. If there are a dozen common ways to route around it, the risk is more than the benefit.
A VPN can't fix it because a compromised endpoint would be able to choose which traffic it sends over the VPN. Whereas if the endpoint isn't fully compromised then you could be doing whatever scanning is being done by the middlebox on the endpoint itself, without centralizing on single point of compromise for the entire network.
> And if the malware doesn't work because it has certificate pinning, well, that's a win too.
It may not make an outside connection, but that doesn't mean it doesn't work. It could still infect every machine on your internal network. What's the chance that none of them are ever in range of a public WiFi?
This is before even getting to the issue of steganography. Information theory says that if your legitimate communications contain zero entropy then they can be encoded into zero bits, i.e. you don't need a network connection at all, but if they contain nonzero bits of entropy then an attacker can encode that much arbitrary data into the stream and still be indistinguishable from legitimate data.
So the whole thing is inherently a cat and mouse game. A lazy attacker may use a data pattern that isn't found in the legitimate data and then a middlebox vendor may find it and use that to distinguish their traffic, but as soon as they do the attacker can stop using it. The longer the game is played, the better the attackers get at making their data indistinguishable and the fewer remaining undiscovered ways to distinguish it that it's possible to find. In the limit there are none left, the data is completely identical to legitimate data with the same amount of entropy, the attacker is only assigning different meaning to it at the endpoints.
Re: Deep packet inspection is dead, and here's why (2017)
#113I'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…
Re: Deep packet inspection is dead, and here's why (2017)
#114Deep 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)?
Nobody is under any threat of prosecution for talking about our ridiculous censorship regime, and the surveillance side of the program is probably no worse than in any other developed country.
Which isn't much of a compliment, but at least we're not China-level evil -- just incompetent. DPI for blocking SNI hostnames is a particularly annoying way to waste taxpayers' money. It's almost as if they timed it to coincide with wide availability of DoH and ESNI!
Re: Deep packet inspection is dead, and here's why (2017)
#115I'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…
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.
Re: Deep packet inspection is dead, and here's why (2017)
#116https://www.youtube.com/watch?v=4Vp8-UONhmM&t=0s&index=17&li...
Re: Deep packet inspection is dead, and here's why (2017)
#117I 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 th…
SSL certificates have to be signed by a vendor ( authority ) your browser trusts or the certificates are considered invalid ( hence the hoo-ha when firefox or chrome occasionally stop trusting some vendor for bad practices ). Your workplace can install themselves as a trusted certificate authority on client machines in order to break that model and allow themselves to issue certificates on the fly for any website. If…
How SQUID enables SSL failure is obscure to me because the failure of SSL is complicated and this slide is overwhelming https://blog.ivanristic.com/SSL_Threat_Model.png
SQUID is a proxy for the website you want to access - so when your browser negotiates the TLS handshake it's really talking to SQUID who then talks to the website if necessary. So how does your browser get directed to an illegitimate proxy? The only way I can imagine is if the DNS is bad but I don't see how that can happen. So for example you want to go to google.com Your browser goes out to your DNS (the ip you plugged in to the network configuration settings) and gets the ip for google. How can someone interpose squid between you and google ?
And then even if squid talks to the server on your behalf, it cannot just forward that stuff to you in clear text because you are expecting that stuff to be encrypted with a private key that only the server or the certificate authority has. Since squid doesn't have the private key it needs, I don't understand what it does. This wiki https://wiki.squid-cache.org/Features/SslBump says "Squid-in-the-middle decryption and encryption of straight CONNECT and transparently redirected SSL traffic, using configurable CA certificates." I interpret that to mean that squid configures a CA certificate. So squid can make it appear like you are talking directly to google?
Re: Deep packet inspection is dead, and here's why (2017)
#118I'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.
You might have purchased a particular device, but you generally don't have the rights to the software or firmware that runs it.
If you're truly concerned, you should support manufacturers that leave their system open by design, or support open source devices, and contact manufacturers describing your concerns.
But the tradeoff wars of freedom v. security were lost long ago. The idea that one should shoulder any blame for choices is lost on a generation that needs YouTube videos to cut an onion. Likewise, a significant number of individuals can't be bothered to change their router password from 123456, and an even greater number of folks think the govt needs to regulate the internet to keep it fair and safe for everyone.. Forced encryption with no choice by design is a feature, not a bug.
Use open source or
Re: Deep packet inspection is dead, and here's why (2017)
#119I 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,…
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.
Re: Deep packet inspection is dead, and here's why (2017)
#120Earlier quoted context omitted.
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 classifier…
Neat paper but as soon as this becomes more widespread malware authors are going to adapt to hide as regular traffic so the analysis is going to get more & more complex until it's not useful as malware traffic will look indistinguishable from real traffic. This is a fundamental evolutionary cat & mouse game that's impossible to win; antibiotics & bacteria, toxins in prey & toxicity resistance in predators, etc.