corporate IT administrators [LWN.net]

corporate IT administrators

Posted Mar 7, 2016 16:29 UTC (Mon) by josh (subscriber, #17465)
In reply to: corporate IT administrators by nim-nim
Parent article: TLS certificate management on Android

I don't see anything wrong with making it possible to trust a proxy's certificate separate from that of the traffic passing through the proxy; that seems like a good thing. That would secure traffic to the proxy itself, which does seem useful if authenticating to the proxy. But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

If anything, browsers need to make MITM attacks harder: when they see a site with a pinned certificate using a different certificate that's in the browser trust store, they should make that MITM visible to the user.

This isn't about browsers ceding their own control; this is about browsers keeping the user safe and in control.

For that matter, browsers have a long history of targeting the end user, not the corporate IT department; many people have fond memories of installing Firefox (or Mozilla before that) on systems that were "supposed" to run IE.

to post comments

corporate IT administrators

Posted Mar 7, 2016 16:43 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (4 responses)

If you want to make sure your malware proxy is not modifying traffic you need integrity, ie digital signatures. Hiding the traffic from the malware checker defeats its purpose.

corporate IT administrators

Posted Mar 7, 2016 19:22 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

That's an interesting concept that I haven't seen brought up in such discussions before. While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring. That could be useful in an environment with regulatory compliance issues, and it'd be somewhat less problematic than allowing MITM.

That said, while such an approach might get some of the existing IT departments running MITM proxies to switch, it might also get IT departments that currently *don't* break HTTPS to try to use that interception mechanism when they would otherwise have had no such option. So I'm not entirely convinced that such an option would be a net positive.

corporate IT administrators

Posted Mar 8, 2016 2:17 UTC (Tue) by flussence (guest, #85566) [Link] (2 responses)

>While I'd still never want to use such a network myself, it'd certainly be *interesting* to have a protocol that could support integrity protection that prevents MITM modification, while still allowing monitoring.

SSL/TLS itself is already capable of that: the command `openssl ciphers -v 'eNULL:!aNULL'` will give you a list of cipher suites (including one in TLS 1.2) which send the data in clear text but cryptographically signed. Naturally, this won't work in a browser.

corporate IT administrators

Posted Mar 8, 2016 6:12 UTC (Tue) by josh (subscriber, #17465) [Link] (1 responses)

That would make it cleartext end-to-end, rather than encrypted from the site to the proxy and the proxy to the browser, and only cleartext-with-integrity-protection to the proxy itself.

corporate IT administrators

Posted Mar 8, 2016 17:59 UTC (Tue) by nybble41 (subscriber, #55106) [Link]

It should still be possible to implement cleartext-with-integrity-protection without changing TLS per se, though you would need an out-of-band protocol for communication between the client and the proxy. The client just needs to give the proxy the decryption key which it derives from the DH master secret. If it keeps the corresponding HMAC secret to itself then the proxy can decrypt the traffic, but not tamper with it; end-to-end authenticity would thus be preserved.

corporate IT administrators

Posted Mar 8, 2016 16:26 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

> But I don't think browsers should do *anything* to make it easier to MITM HTTPS traffic; no matter the path to the proxy, the proxy itself should continue using CONNECT or similar to pass through HTTPS traffic unmodified.

The purpose of the proxy is to inspect the cleartext to block malware, or network usage that violates the policy of the owner, when the same administrative entity owns the network and edge equipment. The problem is that anything which makes it easier to MITM for legitimate security reasons, also can be used by bad actors to transparently intercept traffic in ways that are difficult to detect for the average person. The browser vendors are making the policy decision that protecting people from repressive governments or criminal organizations is more important than enabling inspection by admin policy.

corporate IT administrators

Posted Mar 8, 2016 18:01 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (4 responses)

Actually, they're not protecting anyone. It's easier to grandstand publicly than actually cut proxies and deal with the backlash of all their users. So they end up supporting the worst kind of MITM officiously, instead of working to make it as safe as possible and under user control.

And yes like any useful tech it can be used for evil purposes. Let's kill mail to put an end to spammers.

corporate IT administrators

Posted Mar 8, 2016 18:38 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

> Actually, they're not protecting anyone. It's easier to grandstand publicly than actually

If you can't even understand or acknowledge the perspective of the people you are arguing with, how do you expect to effectively communicate your point? Changing minds requires a dialog not a monologue.

corporate IT administrators

Posted Mar 8, 2016 22:19 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (2 responses)

I'm sorry, but what exactly are you taking offense at?

Did I write anything but the truth?

Am I wrong when I state that despite vehement public opposition to the idea, browser people make sure year after year that it is possible to MITM connexions by importing CAs in their certificate stores? That is a fact and easily checked by consulting browser changelogs.

Am I wrong when I state that making standard communication with proxies obsolete, by refusing to overhaul it with the rest of the web stack, only pushed corporations and security providers to convert massively to the worst and most dangerous kind of MITM? Who targets anything else nowadays?

Am I wrong when I state the people browsers claim to "protect", actually use the tech browsers want to ban (proxies), to protect themselves (for example to bypass the great firewall of China)? That this technology is by no means as one-sided as the browser discourse wants you to believe?

Am I wrong when I state that refusing to give browser users the interfaces to check whom they are giving access to, only results in having this access taken without control?

What, exactly, is accomplished by continuing to push for an ideal state, while enabling its exact reverse year after year, since society is not ready for this ideal state today (will it ever be?) Would it be such a defeat to give browser users a middle ground solution now, instead of waiting for a complete victory that refused to happen for at least a decade?

And, BTW, I do not mean ideal in the positive sense. I mean ideal in the imaginary sense. We've left the point, when one could imagine connecting to the Internet, without firewalls and other security tools, a long time ago. Refusing to secure the network, because browsers have their own security, is irresponsible (first, all connexions are not made via browsers, and second, even if they were, why should we trust browsers absolutely?)

corporate IT administrators

Posted Mar 9, 2016 1:57 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

I wsnt taking any offence, I was providing advice on how to better communicate your point, which you seem to have completely missed, and kind of underlines what I was saying.

corporate IT administrators

Posted Mar 9, 2016 18:33 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Please realise, that taking the higher moral ground ("protecting people from repressive governments or criminal organizations") while refusing to discuss facts that contradict this manichean view, is highly inflammatory in itself.

corporate IT administrators

Posted Mar 9, 2016 16:46 UTC (Wed) by raven667 (subscriber, #5198) [Link] (1 responses)

> browsers need to make MITM attacks harder

I actually wanted to take another stab at this one, if the same entity owns the network, proxy and end-point host then they aren't a MITM, they are the owner, so funneling all traffic through a proxy to inspect the clear text is _not_ a MITM attack, it's a way for the owner of the machine to centralize security policy rather than requiring a plugin or extension to be run on every instance of the browser.

This kind of thing is only a problem when the middle box and end-point host are not owned by the same entity, in the case of a network allowing guest access or an ISP these kinds of technologies would be highly unethical, but the context does matter.

Maybe the real problem is in implementation, centralized middleboxes are the past and distributed software with centralized configuration management the future, and the best way to handle this kind of security problem is with centrally managed browser extensions that perform the same function as the malware scanning middle boxes. No matter what system you choose to do scanning you require a high level of administrative access on the end-point hosts, if you don't have that then you probably shouldn't be attempting this kind of inspection.

corporate IT administrators

Posted Mar 9, 2016 18:41 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Good luck deploying your distributed software on all the nodes that do https today. Starting with all the iot stuff.

Centralized middleboxes exist because any generalized deployment on a non-trivial network parc is harder than hell. gmail, facebook, all the current web giants, exploit the economies of scale of centralizing processing.