corporate IT administrators [LWN.net]

corporate IT administrators

Posted Mar 7, 2016 13:04 UTC (Mon) by nim-nim (subscriber, #34454)
In reply to: corporate IT administrators by tialaramex
Parent article: TLS certificate management on Android

Some more disinformation

What corporates insist on is a way to hook browsers on their security gateways (aka proxies). Because they feel the cost of an intrusion is such the pain of those security gateways is more than worth it. And they actually trust their security provider more than any random website (surprise).

Browser authors, on the other hand, refuse to make their products work properly with those equipments except by adding a root CA to the trust store (tialaramex's § 2). And complain all year round how horrific this solution is (tialaramex's § 3 and 4). And offer vaporous alternatives that never actually solve anything when you take 5s to actually consider them¹.

Well, no corporate is in love with the technical solution either, and they'd drop it in a blink if something else was available.

But browser people do *not* make something else available. Because that would allow anyone to delegate the security of their accesses to the entity they, *not* the browser authors, chose. And freedom (when it means making your mind without browser "help"), is badforyourhealth®.

So they intentionally perpetuate an horrific technical solution, that forces impersonating websites, and forces disabling browser TLS checks, so they can attack it from a technical POW. And avoid stating plainly they want to keep their lock on HTTPS accesses. And refuse to help their users delegate the security of accesses to something else than browsers. They will happily relay your traffic right and left (pocket, google ad platforms, etc), but god forbid *you* chose to relay it to the security equipment *you* selected and paid for.

*None* of it is an actual technical requirement. Separating the proxy TLS checks from the browser TLS checks is not rocket science (just put proxy negotiation outside the website http headers). But no one can do it without browser cooperation. And browser people are happy to keep the statu quo ante. And harass proxy users. And complain of CAs that impersonate third parties.

¹ Case in point, you can add all the HSMs you want, browser behaviour will still force you to import the CA and make it impersonate Google & friends to make the proxy work, and they will still crucify you for this impersonation, and still FUD about the un-trustliness of the CA owner.

to post comments

corporate IT administrators

Posted Mar 7, 2016 16:29 UTC (Mon) by josh (subscriber, #17465) [Link] (13 responses)

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.

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.

corporate IT administrators

Posted Mar 9, 2016 15:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

It's not disinformation, I was simply reporting the facts. Facts which you didn't address at all. Because they make your whole stance look as feeble as it actually is. You trust "corporate IT administrators" as proxies for difficult security problems. That's a terrible joke, as I illustrated.

I want to underscore that I wasn't giving a vague example of what might happen, I was describing reality, as it was when I wrote about it, on the ground, at a regulated financial company with a multi-billion dollar market capitalisation.

corporate IT administrators

Posted Mar 10, 2016 9:24 UTC (Thu) by paulj (subscriber, #341) [Link] (13 responses)

You're complaining that the browsers are somehow refusing to reasonably act in providing a MITM vector friendly to corporate proxies to monitor traffic of users' who are contractually (and lawfully) obliged to agree to such monitoring. The problem is there no known way to implement this that doesn't also give bad guys a MITM vector.

Please explain exactly how a browser, acting on behalf of a user, is supposed to distinguish between a MITM proxy that the user /should/ allow and one it should not?

It has to be technically possible and implementable, otherwise you're just howling at the moon.

corporate IT administrators

Posted Mar 10, 2016 13:37 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (12 responses)

How do you recognize anything on the Internet ? You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

And you give him a console to check what he authorized in the past so he can revoke at need.

No different from GPG, ssh, all the other secure systems on earth.

What you do *not* do is decide on behalf of the user. That's *his* data stream *his* decision, not yours.

corporate IT administrators

Posted Mar 10, 2016 19:39 UTC (Thu) by flussence (guest, #85566) [Link]

This far into the circus act I'm beginning to wonder whether you actually have no clue what a corporate network and IT infrastructure is, and why its requirements (legal and technical) require proxies. The other possibility is that you're being paid to misunderstand everything being explained to you, which makes your employer/sponsor look like a bit of an idiot.

corporate IT administrators

Posted Mar 10, 2016 20:59 UTC (Thu) by paulj (subscriber, #341) [Link] (10 responses)

And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

corporate IT administrators

Posted Mar 10, 2016 21:25 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

A permissions dialog is going to pop up on every new connection? It sounds like the net security effect is mostly in making it unusable.

I'd hazard that approximately 100% of network owners wouldn't want this, and 99.9% of network users wouldn't want it either.

corporate IT administrators

Posted Mar 11, 2016 12:13 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (4 responses)

Sure, let's implement it the dumbest way possible, and then remove it because the implementation is dumb.

corporate IT administrators

Posted Mar 13, 2016 3:49 UTC (Sun) by bronson (subscriber, #4806) [Link] (3 responses)

Isn't that exactly what you proposed?

> You show the user the proxy URL, you show the user the proxy cert, and you ask if he authorizes proxying by this entity.

corporate IT administrators

Posted Mar 14, 2016 14:09 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (2 responses)

I never proposed "A permissions dialog is going to pop up on every new connection"

In fact I explicitly wrote about needing an UI to handle revocations, ie the browser remembering the permissions till the user revokes them.

corporate IT administrators

Posted Mar 14, 2016 19:24 UTC (Mon) by bronson (subscriber, #4806) [Link] (1 responses)

Curious then, how else are you going to show the proxy URL and cert, and wait for permission? (Gnome and KDE experience has shown that notifications aren't enough.)

corporate IT administrators

Posted Mar 16, 2016 15:29 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

Sure you need to show the "do you trust xxxx to proxify your traffic" dialog. But once not every time you connect.

I won't say that's trivial, but that's not *that* hard. Browsers do such messages all the time when there is something they don't like (dns, cert, etc).

On an ideal properly integrated desktop that would go on the network connexion widget like wifi passwords and vpns (from a functional POW a proxy is a pure HTTP/s VPN)

corporate IT administrators

Posted Mar 11, 2016 12:10 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (2 responses)

Please, do not discuss security matters if you have no understanding of why making permissions explicit, auditable, and revocable, matters.

corporate IT administrators

Posted Mar 11, 2016 21:52 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

Good way to answer the question...

corporate IT administrators

Posted Mar 14, 2016 14:16 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

"Let's ignore all the content in a (long) thread, and restart from the beginning". Is that really a question?

corporate IT administrators

Posted Mar 22, 2016 17:58 UTC (Tue) by nye (guest, #51576) [Link]

>And how will the net security effect of that approach be any different to the current "install a root cert and let the proxy MITM everything" approach of today?

It would mean that all of the original TLS information is available to the browser, which can verify it and present it to the user in the usual way, rather than being stripped by the proxy and replaced with something else as is currently necessary because the only way to proxy https is nasty MITM shenanigans.