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.
And these dumbass corporations/organizations wonder why I VPN around their shit.
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.
Who wrote this?
Encrypted traffic inspection devices (also known as middleware)
You are a pathetic person, you sound like you have a miserable life.
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.
they meant to say malware. it's breaking encryption to spy.
for encrypted HTTPS proxies that have the proxy handle endpoint termination and pass sideband info to the browser identifying the remote site.
It is a lot of code, but if they need these capabilities then someone should be able to fork over the dough to get it included as an optional feature in the major 2-3 browsers.
Filter on other things if you need to filter. I like the approach in used in DNSthingy which combines DNS filtering with Firewall.
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!
https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.pdf
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.
The whole concept of your browset maket putting a set of CAs in front of you, that are blindly trusted... witout you ever having even met a single person at any CA ...is already completely invalid security.
The browser should ask you, if you trust a CA to verify a site, for each site, and only trust the CA for verification, if you do.
And it should give you ways to easily check the trustworthiness of CAs.
Which ends up just becoming a PGP-like web of trust.
PGP's awful implementations should not distract us from its necessity. Wr should just find a better way to do that!
And if someone by accident was let in front of a computer without having a clue, then they should appoint a legal guardian to help them and their disability.
Since when do you need to inspect packet contents, to limit traffic. Just limit based on source and destination.
So if you put a middleman device in a TLS connection, that connection no longer has TLS end to end. Well no shit... That's the whole point.
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.
I'm surprised Blue Coat Systems, Inc. doesn't have any representation in this study. Were the researchers legally hamstrung to prevent them releasing results of their testing on such a device?
Malware and malicious traffic is being stopped without unencrypting and doing MITM type analysis. See here https://blogs.cisco.com/news/cisco-extends-encrypted-traffic-analytics-to-customers
The whole point of TLS is to prevent eavesdropping. There is no way to filter TLS streams' content without bypassing the encryption.
This isn't a story. I'm surprised it was worth spending the effort to research. Actually, I'm not "publish or perish" has made a mockery of research publications.
I thought secure end-to-end communication was a goal, not a problem..
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.