Re: What will incentivize deployment of explicit proxies?

On 12/10/2013 02:12 AM, Mark Nottingham wrote:
> 
> On 10 Dec 2013, at 11:50 am, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
> 
>> 
>> 
>> On 12/10/2013 12:44 AM, Mark Nottingham wrote:
>>> Sure. I'm thinking in terms of changes in browser behaviour
>>> (along the lines that some have already explored), not changing
>>> TLS, or even certs, necessarily.
>> 
>> But there is a problem here - as I understand it many root stores
>> have no controls over the protocols with which the roots can be
>> used so if you insert a new root then you will also have affects on
>> non-HTTP protocols that use TLS.
> 
> Yes, that's already happening today. Such controls would indeed be
> nice.
> 
> <https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf> is a
> nice writeup, and lists a few products that do this at the end. There
> are others; e.g., <http://wiki.squid-cache.org/Features/SslBump>.
> 
> The problem is that installing a new CA is *extremely* common; 

Do we have any numbers on that? Extremely common wouldn't match
my impression but I've nothing much on which to base that.

> try
> searching for "install CA certificate" and you'll see many, many
> results like
> <http://community.web.cern.ch/faq/certificate-installation-android>
> <-- note that it's even happening where the Web started!

Well that's pretty different isn't it - the cern one seems to be a
new CA for an SSO system and not for a MITM system. It could do
both I guess, but it looks like eduroam and local SSO. If its not
a MITM then that is what installing a new root is supposed to be
for. That is, there are no fake certificates involved.

> Those CAs then have unlimited power to MITM communication (whether
> that's their intent or not), and cannot easily be detected when doing
> so.

Yes. Mpodulo things like NameConstraints and other application layer
constraints, none of which are widely done. But a lot of those more
complex PKI things could be done if desired. I also don't see any
interest in going down that road though.

>> What I've not seen is anyone who's proposing such changes (that do
>> affect TLS) volunteering to do that analysis. I'd say its not an
>> easy piece of work but absolutely necessary and it might well turn
>> up a conclusion that this is a bad idea globally.
> 
> AIUI we're already there -- i.e., people think it's a bad idea, but
> it's happening.
> 
> To be crystal clear -- I'm not talking about making it easier to
> install CAs in browsers. I'm wondering if we can *constrain* the
> current practice in a meaningful way, so as to limit the damage of
> this already-widespread practice.
> 
> We may not be able to (either because it's too hard, or because the
> IETF isn't the right place to do it), but it's worth talking about.
> One interesting discussion that's related: 
> https://code.google.com/p/chromium/issues/detail?id=81623  (CLOSED
> WONTFIX)

Yeah. Its not my code but I'd have to say that its an ongoing
surprise for me that even when browsers know for sure that they're
not talking to https://example.com that they don't tell the user.
(E.g. if example==google, some of 'em do know and for sure, and
there are some such names for all browsers I think.)

> What I don't want to do is spend months-to-years developing a new
> kind of explicit proxy in HTTP in the *hope* that it'll somehow
> magically supplant these devices, without some sort of evidence that
> it has a chance of doing so.

Fully agree. If people set up with irreconcilable requirements
and aren't willing to change then the outcome will be the same
kind of scenario we have now. There's not much value in thrashing
about for ages before discovering that. (And before you ask, I'm
already clearly willing to discuss anathema decrypting proxies of
the HTTP variety:-)

>From my purely personal pov -  I figure that one of CT or DANE
or mucking about with JS will eventually ferret out the TLS MITM
attack boxes anyway so the do-nothing scenario isn't necessarily
that terrible in the medium term. I'd have thought the MITM folk
would be more keen to move into the daylight though, but if
they're not, they're not.

S.

> 
> Cheers,
> 
> 
> -- Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> 
>

Received on Tuesday, 10 December 2013 02:38:15 UTC