Network Middleware Still Can't Handle TLS Without Breaking Encryption (zdnet.com) 101
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.
Re: (Score:3, Insightful)
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 d
Re: (Score:2)
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.
unless its end to end, its going to break (Score:5, Insightful)
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.
Re:unless its end to end, its going to break (Score:4, Insightful)
> What is broken if the user trusts a middlebox?
Nothing. This is just hyperbole.
The real question is do you trust cert authorities that have screwed-up in the past or your local IT guys? After we had several employees install malware from what they thought was a safe site since it used HTTPS, we haven't had that happen again after installing a proxy. It's the lesser of two evils.
More ways to screw it up is worse (Score:2, Informative)
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 strict
Re: (Score:1)
wat? No... so many things break, there's also so many assumptions you're making by using MiTM breaking TLS.
Assumption 1:
* you can stop malware on the wire.
Assumption 2:
* this doesn't materially increase the risk of users behind it.
Assumption 3:
* what you're doing is legal
Number 1, you can't. It's not worth trying to do it this way, even antimalware solutions are deprecating this approach. It's not meaningful security.
Number 2, you aren't better than Google at protecting your certs. And honestly unless y
Re: unless its end to end, its going to break (Score:2)
I actually built a MITM appliance to do name based whitelists. You have a better approach? Not doing whitelists isn't an option for what we're doing.
Re: (Score:2, Insightful)
Bonus: It takes a lot less hardware to run a DNS resolver than a MITM proxy.
Re: (Score:2)
It's not about users, it's about defending against a breach. We transparently proxy all traffic, drop anything that isn't HTTP/HTTPS and only relay requests that match a whitelisted (sub)domain. Since we have so little egress traffic, i take a single system to do this and we keep a hot standby for failover. Relying on DNS doesn't offer you any protection here.
Re: (Score:2)
Good luck if the appliance itself actually checks for cert validity or not.
Care to elaborate?
Re: (Score:2)
.... which is not "broken by design", it's an insecure configuration.
Re: (Score:3)
That's a nice ideal, but in a corporate environment you may have legal and regulatory constraints that prohibit you from actually providing end-to-end encryption from inside your network to outside or vice versa, and the kinds of devices we're talking about fit in between. If you're using someone else's computer, for example at work, then you should never assume that your browser is truly end-to-end encrypting a connection to your bank or GMail or whatever. It is common these days for large organisations to
Re: (Score:2)
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, ju
Re: (Score:2)
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.
I think the point of certificates and ... (Score:5, Insightful)
all that is that you're not supposed to be able to do this. Sounds like it's working as designed.
Re: (Score:1)
You should read the article as it's a bit more nuanced than that. The general points is that even in instances where you want and allow that kind of inspection to take place (ie employer making sure no one's downloading a worm), the "middleware" is breaking things in that they accept certificates they have no business accepting today. No matter what your local security is set to (disallow any connection below TLS 1.2, for example), the middleware will connect to the remote network which is only accepting TL
Re:I think the point of certificates and ... (Score:5, Insightful)
Correct. Any other stance is just wrong. If you don't trust a host on your network communicating with the outside, then don't allow that to happen at all. If some things must be allowed, then work on a whitelist.
If you're trying to read encrypted traffic when you are not one of the 2 hosts involved in the encrypted connection, then you are hostile and malevolent - no matter your purported reasoning or intention.
Re: (Score:2)
That position is untenable both mathematically and legally.
It's perfectly logical that an intermediary device can decrypt and re-encrypt data with no flaw in the security protocols, if suitable certificates and trust are configured on both the originating device and the intermediary.
And while technical people will naturally be concerned about the possibilities of abuse with MITM-style devices, the fact is that we live in the real world and the people responsible for corporate security and regulatory complia
Re: (Score:2)
No, you don't. There is an entire industry based on this kind of technology, and the underlying mathematics is well understood. If you think you can prove that what this industry does every day can never work, then you have misunderstood what is actually happening.
Re: (Score:2)
If the legislators/regulators want the Internet to work that way, then as long as you're using equipment managed by someone under the authority of those legislators/regulators, that's very likely exactly what will happen. If you don't like it, don't use other people's equipment to connect to the Internet.
Re: (Score:2)
An approach that works for computers too. Company sets some rules - but they certainly don't have to manage every device on the network.
Unfortunately, in modern times it doesn't work so easily. That's why handling BYOD policy is one of the current big discussions in corporate IT, why dual-purpose devices where there is a remote wipe controlled by corporate IT exist, and so on.
When you vpn in to work from home/hotel, they can't know whats on those networks anyway.
And again, that's why VPNs and on-site guest networks that have devices outside the firewalls tend to have more limited access.
Have an internal network that is robust, instead of the silly idea of having mega-vulnerable equipment behind very strict firewalls.
It's not either/or. Deploying these kinds of tools is all about having layers of security and isolating different parts of the network as much
Re: (Score:2)
Agreed. They never worked in a NIST environment or had to ensure that certain documents never leave the network. Wait until they learn we also disable USB ports!
At least in the US, that is the company's machine and network and they will damn well do what they want with it. There is no freedom by design.
Re: (Score:2, Insightful)
Disagreed. If you don't want shit leaving your network and you move to break encryption, you're still an attacker and you're still breaking encryption.
I don't care what your reasoning is. I don't care if you OWN the hosts involved. I don't care what you're trying to prevent. By decrypting the traffic on a machine that is not one of the two endpoint hosts that are trying to talk to each other, you are in the wrong.
Re: (Score:2)
Nope. 30 years of networking says I'm right.
Re: (Score:3)
It's perfectly logical that an intermediary device can decrypt and re-encrypt data with no flaw in the security protocols, if suitable certificates and trust are configured on both the originating device and the intermediary.
Fucking WRONG.
Any such intermediary is breaking the protocol by doing that, even if it does so successfully. The protocol is to facilitate END-TO-END encryption between TWO AND ONLY TWO hosts on the network.
A host in the middle decrypting that traffic for any reason is by definition an attacker.
Re: (Score:2)
You're talking about what you'd like to happen. I'm talking about mathematics. No security is being broken here, because the local endpoint is actively configured to trust the intermediary by its authorised administrator. The violation of the protocol is only in the sense that if the local user is not also the administrator of the system, and if that user has not been made aware of the arrangement, then their trust in the system as a whole is misplaced.
Re: (Score:2)
agreed, if you have any business with EU citizens, then, MITM-ing the traffic is illegal, period...
Re: (Score:2)
In fact, I know for sure it is false as expressed.
If you are an european company with european employes or visitor (who are often EU citizens) and you provide them with internet access, and you warn them that you can intercept their trafic, MITM can be acceptable.
ANSSI (Agence Nationale pour la Securite des Systemes d'Informations, french governemental agency for IT security) even publish a guide explaining how to install your MITM proxy (https://www.ssi.gouv.fr
Re: (Score:2)
Sorry, but that simply isn't true.
Re: (Score:2)
>"If you don't trust a host on your network communicating with the outside, then don't allow that to happen at all. If some things must be allowed, then work on a whitelist."
That's what we do for most users (a whitelist). And it is no simple task, either. This is because sites link to other sites and content delivery networks, too. So for a page to really "work", then there might be lots of things that also have to be whitelisted.... many of which are not easy to find/discover. And many of which chan
Re: (Score:2)
So you "trust" for example that Slashdot has not been compromised and there is no possibility loading this page will send down some malicious javascript that might do a heap spray and exploit your browser?
Sorry buddy the entire Internet works on people connecting to hosts and parsing and in some cases execute content from hosts they have no reason to "trust." As a network admin I could ensure one hosts (the intercept proxy) got signature based IDS updates every 15min. I could not make sure every host on
daqfuq? "still"? (Score:2, Funny)
Tautologies are still taugologous? Who could have known???
New definition for middleware? (Score:5, Informative)
Encrypted traffic inspection devices (also known as middleware)
Really? I don't think I have ever heard of middleware [wikipedia.org] 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".
Re: (Score:3)
Re: (Score:2)
It's the same thing. The software layer just runs on it's own separate networking hardware in between the client and server.
True, but in this case the "middleware" isn't really bridging two applications, it is monitoring the communications between them. I suppose you could call the man-in-the-middle attack software "middleware" between the end applications and the monitoring applications, but that feels like a stretch.
Re: (Score:2)
I did find the idea of calling a "device" something-"ware" kind of humorous. I really hope that doesn't catch on.
Re:New definition for middleware? (Score:5, Funny)
They probably meant *meddleware*
Re:New definition for middleware? (Score:5, Informative)
I think whoever wrote or proofread the ZDNet article Introduced mistakes, here.
The phrases "TLS Middleware", "TLS middleware appliances," and "Middleware appliances" appear throughout the article Slashdot linked, BUT
the paper [arxiv.org] does not use the word even once. They are called Middleboxes in the study.
Re: (Score:2)
IDIOTS (Score:5, Insightful)
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.
Re: (Score:3)
Preventing man in the middle attacks is the fucking point of TLS.
The point of TLS is enforcing trust relationships.
Of course you can't perform a man in the middle attack without breaking TLS you morons.
Delegating termination of TLS to something you trust is not an attack. You are confusing middlebox implementation failure with design failure.
This is no different than delegating your secretary to answer a secure call on your behalf and having them relay relevant information to you.
Re: IDIOTS (Score:2)
What about limiting egress traffic from high security networks that have nothing to do with traffic from people? Perhaps you don't know all the use cases for things.
Re: (Score:2)
Employers and colleges intercepting, monitoring, and censoring users secure sessions isn't what I'd call delegation.
If you don't trust a middlebox and don't want to be fooled by one then don't install root certificates necessary for it to function.
Politics surrounding middleboxes especially ones forced upon end users are a different matter from my comments on technology itself.
I personally believe there are both constructive and destructive uses of middleboxes, integrity only cipher suites and even completely insecure communications.
If you are being coerced into accepting trust relationships you don't actually find accep
Re: (Score:2)
Which they can only do with these technologies if the computer being used is theirs.
If the computer doesn't trust the CA used to create the new certificates, you'll get browser security errors.
If you want to use someone else's computer, you need to obey their rules. It's not your computer.
Catch 22 of security (Score:2)
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 allow
Re: (Score:2)
Re: (Score:2)
Ah yes, the consumer bill of rights, and now you're advocating for a key-to-all-encryption to get access to the data you're "entitled" to. That is how these laws will be written after all and unintended consequences will mean that not only can you see the data, but so can the FBI and NSA and everyone else.
Nobody should be able to MITM. If you need control over the end device, you need to obtain control over the end device, not everything else.
Re: (Score:2)
Umm.. that is exactly what I said. The ability of the owner of a device to snoop their own device traffic AT THE ENDPOINT needs to enshrined in law. Our devices are being weaponized against us.
Re: (Score:2)
You already have that capability. Simply read out the chips or upload a custom firmware. The problem is generally that it's not easy, but if you want to make it easy, then you're opening the door for others as well.
Re: (Score:2)
Without MITM, some organisations will have no option but to either
A) break the law
B) block all encrypted communication
Why not sign? (Score:2)
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 cli
Re: (Score:2)
The basic premise of these systems is that the person managing the endpoint has voluntarily configured it to trust a MITM device that will impersonate (through certificate forgery, essentially) the other endpoint. Given that certificate forgery, how do you know you can trust any signature either?
Ultimately, if you don't manage the endpoint you're using, the game is already over.
Re: (Score:2)
Re: (Score:2)
There is no way to do what you're suggesting without creating new protocols.
You could still use TLS to implement #1 as is done now. You'd need a second layer that doesn't use the CA installed to make #1 work to implement #2
But how ... (Score:2)
NEWSFLASH: TLS (finally) works as designed (Score:3)
Nice angle on the story there /.
So, corporate network traffic is easy pickin' (Score:2)
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.
stealth MITM barrel-rape enablement (Score:2)
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 lay