Re: Draft finding - "Transitioning the Web to HTTPS"

Hey Henri,

> On 16 Jan 2015, at 12:58 am, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> 
> On Tue, Jan 13, 2015 at 8:59 PM, Chris Palmer <palmer@google.com> wrote:
>> As discussed earlier in this thread, HTTPS requires clients to
>> knowingly opt in to caching, transforming, or spying proxies. But such
>> proxies are still possible. HTTPS makes them prove some value.
> 
> While that's technically true, what you say assumes that users aren't
> given an informed choice to make about the value. It's way too easy to
> make up some excuse why the user needs to run an installer in order
> for the Internet connection to "work" and such an installer could add
> root certs so that browsers treat them as trusted root certs.
> 
> I think the TAG finding shouldn't suggest that MITMing https might be
> OK in some circumstances, because then those who want to MITM could be
> emboldened to MITM and to claim that whatever they do is endorsed by
> the W3C--all without giving users an opportunity to make an informed
> choice and without actually matching the circumstances that the TAG
> might have had in mind.

The draft currently says:

> Adopting "https://" has the side effect of disallowing shared HTTP caching [RFC7234]. Shared caching has a limited role on the Web today; many high traffic sites either discourage caching with metadata, or disallow it by already using "https://". However, shared caching is still considered desirable by some (e.g., in limited networks); in some cases, it might be so desirable that networks require users to accept TLS Man-in-the-Middle -- which is a bad outcome for Web security overall. Therefore, we encourage exploration of alternative mechanisms that preserve security more robustly, such as certain uses of Subresource Integrity [SRI].

Is that adequate, and if not, can you suggest edits?

From my standpoint, I think we need to walk the line between acknowledging that when someone (e.g., your employer) owns the machine, they can and sometimes do MITM, while not condoning that as a desirable outcome. That's why the draft encourages work on browser extension APIs, improving PKI UX, etc.

To the latter point -- I still find it remarkable that this is extremely common practice:
   http://ist.mit.edu/certificates
... and the OS/browser UX doesn't warn the user of the power granted by doing so (last I checked).

Cheers,



> For example, to stick with the place that
> inspired TimBL's remarks, Great Britain is not really a *remote*
> island for connectivity purposes, but it reportedly turned into a
> massive captive portal lately
> (http://arstechnica.com/tech-policy/2014/12/bt-sky-and-virgin-hijacking-browsers-to-push-porn-blocks/),
> so there's a pressure to MITM without "remoteness" in the network
> topology.
> 
>> Overall, TBL seems to be saying that people shouldn't spy on the net,
>> so that we can enjoy many social goods. Among those goods, he seems to
>> place the ability to not have to adopt HTTPS. Unfortunately, we don't
>> like in so innocent a world, and HTTPS is the bare minimum protection
>> against tampering and spying.
> 
> Yeah. The notion that https should be avoided on performance grounds
> and the would-be snoopers be asked not to snoop seems unrealistic both
> on the point of badness of the effect on performance and on the
> effectiveness of just asking the would-be snoops not to.
> 
> -- 
> Henri Sivonen
> hsivonen@hsivonen.fi
> https://hsivonen.fi/

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 19 January 2015 05:53:58 UTC