corporate IT administrators [LWN.net]

corporate IT administrators

Posted Mar 10, 2016 13:37 UTC (Thu) by nim-nim (subscriber, #34454)
In reply to: corporate IT administrators by paulj
Parent article: TLS certificate management on Android

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 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.