Re: What will incentivize deployment of explicit proxies?

On Mon, Dec 9, 2013 at 6:37 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> 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.)

I think the answers are all in the bug listed above. If it's still
unclear, please say what's unclear. In your example, when we know
you're not talking to Google, we show an error. We disable this error
in certain situations
(https://www.imperialviolet.org/2011/05/04/pinning.html):

"""
What about MITM proxies, Fiddler etc?

There are a number of cases where HTTPS connections are intercepted by
using local, ephemeral certificates. These certificates are signed by
a root certificate that has to be manually installed on the client.
Corporate MITM proxies may do this, several anti-virus/parental
control products do this and debugging tools like Fiddler can also do
this. Since we cannot break in these situations, user installed root
CAs are given the authority to override pins. We don't believe that
there will be any incompatibility issues.
"""

>
>> 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:47:58 UTC