Re: Fwd (TAG): Draft finding - "Transitioning the Web to HTTPS"

Other responses on this thread (and in particular links from Domenic and Chris) might give more info than I can provide, but I’ll try to answer briefly a couple of these questions.

On Dec 19, 2014, at 2:32 PM, Eric J. Bowman <eric@bisonsystems.net> wrote:
>> 
>> To summarize, sites are still exposing information about their users
>> when they force visitors to use HTTP, even if there are no
>> authentication cookies. In particular, the user’s reading habits are
>> exposed (which page on your site are they reading? does that page
>> contain words of political interest?). Non-authentication cookies are
>> used to surveil users or identify them for more invasive attack [0].
>> 
> 
> Sorry, but is this problem actually solved by HTTPS in an era of super-
> cookies? HTTPS doesn't hide the visited site IP from network admins. So
> I still believe (until convinced otherwise, but I'm a hard audience) w3c
> should come up with something better instead of copping out to using
> ubiquitous HTTPS despite its known problems.

Super-cookies and browser fingerprinting do create privacy issues for Web users. But I’m not sure why we would conclude from that that HTTPS won’t be helpful. In particular, HTTPS provides improvements in confidentiality from network attackers (passive or active) not from the site you’re communicating with. (That’s rather the point: you want to communicate with the site you’re communicating with!) That sites can use persistent identifiers to re-identify you is an orthogonal problem, but we at least wouldn’t want to provide visibility into all of those identifiers to a passive adversary on the network.

HTTPS is also not a silver bullet, as all agree. But users can benefit from the network adversary not knowing all the details of the pages they visit even if the destination IP address is revealed.

>> Also, without integrity guarantees, HTTP sites expose their users to
>> the risk of running any script the attacker wishes to introduce,
>> including potentially asking for access to sensitive device APIs.
>> Network attackers can also introduce identifiers or modify content
>> for HTTP browsing. That is, integrity also helps with confidentiality
>> and other privacy concerns [1].
> 
> But still, why HTTPS? When I can solve those problems using HTTP Digest
> and auth-int? To solve a problem nobody I know has ever come across in
> the first place? So many of the reasons to not use HTTP come across as
> FUD when I delve deeper -- theoretical problems pale in comparison to
> actual problems, there are enough of those to go around without
> resorting to scare tactics.

Among the documented security issues with HTTP Digest is that it’s vulnerable to a man-in-the-middle network adversary. This is not at all just a theoretical problem. For example, see the lists in Chris Palmer’s email in this thread, or the list in the Chromium FAQ referred to earlier:

http://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0062.html <http://lists.w3.org/Archives/Public/public-privacy/2014OctDec/0062.html>
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/education/tls?pli=1#TOC-What-security-properties-does-TLS-give-me- <https://sites.google.com/a/chromium.org/dev/Home/chromium-security/education/tls?pli=1#TOC-What-security-properties-does-TLS-give-me->

(It’s also intended for user authentication, not for authenticating the site. It isn’t intended to provide any measure of confidentiality. As RFC 2617 points out, message integrity is not provided against a man-in-the-middle attacker.)

Hope this helps,
Nick