Re: SSL/TLS everywhere fail

Hiya,

On 05/12/15 00:41, Mark Nottingham wrote:
> 
>> On 5 Dec 2015, at 2:08 am, Jacob Appelbaum <jacob@appelbaum.net>
>> wrote:
>> 
>>> But SSL/TLS is just about the worst encryption you can bring to 
>>> that fight, because it is *so* trivial and routine to MiTM that
>>> you can find the list-price for the necessary equipment on
>>> Google.
>> 
>> This is where we diverge, I suspect. None of that equipment is
>> going to work against PayPal or Google or even Tor Project's
>> website when a user uses a modern browser as those sites are TLS
>> with cert pinning.
> 
> Last I checked, browsers don't enforce pins when a MiTM CA is
> installed locally, and they don't intend to in the foreseeable
> future.

So if the Kazakh situation were to pan out as feared, then
that would I think create a fine reason to re-open some of
the tricky questions around disregarding pins. RFC 7469, in
section 2.6 [1] says:

   It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).

A situation where a govt forces or pressures end users at
home to install a root was not one that was considered when
that was thrashed out iirc. (If I'm remembering badly, then
pointers to the websec archive appreciated.) My reading of
the above (FWIW, me not being a browser implementer) would
be that coercing someone at home into installing a root
doesn't pass muster as something that's ok to ignore as it
is not a local policy for the person using the browser who
is the relevant policy authority.

Now, that'd be moot except in a situation where the world
was loudly told "here's the public key that folks <here>
had better install or else" in which case it could be feasible
for implementers to blacklist that key from being used
as a root. Technically, that's not very different from not
allowing someone to use the debian weak keys.

And indeed, if web sites were to know for sure that the
connections they see from such-and-such a TCP client are
in fact almost always MitM'd then those sites arguably ought
consider treating that connection differently, e.g. maybe
display a warning, or not allowing password reset perhaps,
if that could be done in a meaningful manner.

So interesting questions would arise in that "we're just
gonna force you member of the public to accept this MitM"
situation.

But, all of the above is still premature, (as is most of
this thread), as we don't yet really know what the actual
situation may end up being.

S.

[1] https://tools.ietf.org/html/rfc7469#section-2.6

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

Received on Saturday, 5 December 2015 02:32:46 UTC