Slashdot Mirror
Network Middleware Still Can't Handle TLS Without Breaking Encryption (zdnet.com)
An academic study published last month shows that despite years worth of research into the woeful state of network traffic inspection equipment, vendors are still having issues in shipping appliances that don't irrevocably break TLS encryption for the end user. From a report: Encrypted traffic inspection devices (also known as middleware), either special hardware or sophisticated software, have been used in enterprise networks for more than two decades. System administrators deploy such appliances to create a man-in-the-middle TLS proxy that can look inside HTTPS encrypted traffic, to scan for malware or phishing links or to comply with law enforcement or national security requirements.
[...] In the last decade, security researchers have looked closely at the issue of TLS inspection appliances that break or downgrade encryption. There has been much research on the topic, from research teams from all over the world. But despite years worth of warnings and research, some vendors still fail at keeping the proper security level of a TLS connection when relaying traffic through their equipment/software. Academic research [PDF] published at the end of September by three researchers from Concordia University in Montreal, Canada, shows that network traffic inspection appliances still break TLS security, even today.
[...] In the last decade, security researchers have looked closely at the issue of TLS inspection appliances that break or downgrade encryption. There has been much research on the topic, from research teams from all over the world. But despite years worth of warnings and research, some vendors still fail at keeping the proper security level of a TLS connection when relaying traffic through their equipment/software. Academic research [PDF] published at the end of September by three researchers from Concordia University in Montreal, Canada, shows that network traffic inspection appliances still break TLS security, even today.
Having a MITM on purpose is breaking things by design.
The end user needs to verify that the site they're talking to is the real one, by checking the certificate, but all they get is this stupid cert that was automatically generated by some stupid appliance. No way for the end user to ever know if they've gotten the right website or not.
Good luck if the appliance itself actually checks for cert validity or not.
In short, TLS is working as designed.
all that is that you're not supposed to be able to do this. Sounds like it's working as designed.
Tautologies are still taugologous? Who could have known???
Encrypted traffic inspection devices (also known as middleware)
Really? I don't think I have ever heard of middleware used in that context. I have always thought of middleware as a software layer that abstracts something between applications. It seems weird to refer to a hardware device as "middleware".
Preventing man in the middle attacks is the fucking point of TLS. Of course you can't perform a man in the middle attack without breaking TLS you morons.
The OWNER of endpoints should always be able to see what is flowing over the encrypted channel. Man in the middle is ALWAYS bad. If there are designed in ways for the owner of endpoint devices to inspect their traffic, then man in the middle is irrelevant. But what we have now is different levels of bad depending on the class of device we're talking about. For enterprise devices, the corporate owner should technically already have the ability to enforce a proxy or to enforce software installation that allows inspection of any and all traffic. But the real problem is Internet of things and home user class devices where vendors are weaponizing our devices against us and treating us as the thing that needs to be secured against. I should be able to see, decrypt, analyze and authorize every byte of traffic leaving my home, whether it comes from my smart TV, my PC, my phone or any apps on those devices. And it should be done without the defeating the security with a man in the middle. Just the fact that I own the device means I should be able to inspect all traffic coming and going through the interface before or after decryption but in a state not controlled or limited by any application that I don't have complete control of. The only way this will ever happen is if a consumer bill of rights ever comes.
Digital is, by definition, imperfect. Analog is the way to go.
Encryption in this case provides two benefits: 1) Privacy, knowing that you're only talking to the one site 2) Signing, knowing that the data you got was unaltered from the site
What if they made it so the MITM HTTPS proxies only broke #1 and could just pass through the content. Then the client could at least know that the content was unaltered. Assuming the proxy is decently implemented and validates the site, the proxy could now become responsible for making sure that the connection is secure and the client can assume that the proxy is handling this.
Have gnu, will travel.
Nice angle on the story there /.
SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
As I understand it, a lot of big corporations use these tools and have the employee PC's install certs so that it all works. The upshot is that not only is your traffic not hidden from your employer (something that was made clear to me every time I logged into my previous employer-owned PC) but that when the traffic goes onto the internet, it's not that securely protected because of these weak appliances. That may have an impact on the security of any SaaS products the corporation is using (Salesforce, etc.), so as a Corp IT guy I'd be trying to fix that. Alternatively, as a corporate espionage attacker, it sounds like traffic between corporations and SaaS offering are ripe for the picking!
If you're talking directly to the origin server, you're trusting
a) the public certificate authority.
If you're talking to a proxy, which then talks to the origin server, you're trusting:
a) Your local admins not only set up the proxy securely, but have kept updating the configuration every few months to stay up with the latest attacks.
b) The proxy vendor got it right, and keeps it updated.
c) the proxy server (which has the unecrypted data) hasn't been compromised
d) the certificate authority
The proxy is strictly weaker, in an absolute sense, because it requires trusting the certificate authority PLUS trusting the local admins get it right and keep it right, PLUS trusting the vendor of the proxy. You have to trust the same original CA plus two more groups of people, plus trust that the proxy server itself is insecure, that the server OS etc hasn't been exploited.
Therefore the proxy is more dangerous in an absolute, mathematical sense. It's not even debatable because adding more ways to fail *always* makes it weaker.
Yeah, except at some point there needs to be a level of trust that doesn't fundamentally break the Internet for the average user.
What's the difference between "blindly trusting" a CA that the browser already has loaded into it's certificate trust store, versus John Q. Public mashing the "trust" button blindly for the 37th time since getting their new computer and having to trust all the CAs that usually are loaded into the browser's certificate trust store?
There is no more security with what you suggest, just more dialog spam making it easier for a compromised or false CA to sneak in, a la Android permissions requesting from applications that everyone ignores and just grants. With the current system, we can at least say that we trust Google / Apple / Microsoft / Mozilla to curate the CA list.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Is this the new version of the cows go mooooo moo moo cows guy?
The cows / mooo thing was funnier. You're just pathetic. Sad.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
These MITM proxies only work because they create their own certificates for every domain you visit, signed by their own CA, which is installed as a trusted CA on every corporate machine.
If the software you use doesn't trust that CA, you'll get notified of the MITM.
If the software you use records the fingerprint of the host you connect to, you'll be notified of the changed fingerprint when the MITM proxy intercepts the connection, even if the machine trusts the MITM CA.
They're not magic encryption breaking devices. They simply pose as the remote server and offer their own certificate. They then make another connection to the remote server. The issues come up when the remote server is dodgy. Any trust issues in that connection can't be forwarded on to the client. The proxy needs to decide to accept it or deny it.
Advances made in browsers to detect these issues aren't always made in the proxies.
Compromises get made in the configurations of them so a few broken websites will still work - from accepting weak encryption protocols to ignoring name mismatches to not checking for revoked certificates.
It is actually possible in theory to build a secure MITM HTTPS proxy. In reality they contain bugs and compromises.
the point is that vpn'ing around it doesn't make half the software you use break like letting it pass the mitm does(unintentionally mind you). any sw that does any attempt at detecting a mitm and doesn't take the certs to trust from the operating system just breaks.
also. "corporate installed encryption breaking software breaks encryption". yeah who would have thought.
and if you're using a decent vpn client then yeah you would know because it wouldn't trust the corporate certificate in the first place.
world was created 5 seconds before this post as it is.
If the minions of the undark web weren't so busy implementing stealth TLS MITM (so that the web server doesn't know there's a validated MITM on the client end), the invasive middleware could simply intercept the encryption part, without fudge-hammering end-to-end authentication and the client negotiation of security parameters concerning the public side of the link; if the server knew the client preferences for certain, it would simply drop traffic whose public security envelope was mangled by the MITM layer.
Problem solved.