Re: Proposal: Marking HTTP As Non-Secure

I adapted Ryan's reply to be a new FAQ answer in the Chromium wiki:

https://sites.google.com/a/chromium.org/dev/Home/chromium-security/education/tls?pli=1#TOC-The-only-security-guarantee-TLS-provides-is-confidentiality.

On Fri, Dec 19, 2014 at 9:10 AM, Ryan Sleevi <rsleevi@chromium.org> wrote:
>
> On Dec 19, 2014 8:52 AM, "Dominick Marciano" <dominickmarciano@gmail.com>
> wrote:
>>
>> Good Afternoon,
>>
>> I have read the proposal regarding marking HTTP as non-secure.  I feel
>> that it is a good step to let users know when their information is not
>> secure, however I also feel that applying this across the board may be too
>> broad of stroke.
>>
>> If users are on sites that are transmitting any personally identifiable
>> information, such as geo-location information, name, address, telephone,
>> etc., to a non-secure site that the user should definitely be informed.
>> However there are also plenty of cases where a site may not employ HTTPS
>> that the user does not necessarily need to be notified about.  Good examples
>> of this may be news sites, blogs, etc., where a user does not need to login
>> or provide any other information.  In these cases (where no data is being
>> transmitted) HTTPS is not necessary and if users are being warned about
>> every site they are going to (that doesn't use HTTPS and doesn't transmit
>> any data), I believe a lot of users will start ignoring the warning (or call
>> their IT company) and then the warning will provide no additional benefit.
>>
>> If possible, I believe this the warning would be better used in cases
>> where a user is on a site not using HTTPS but is still transmitting personal
>> information (location, name, telephone, etc.) in addition to login pages not
>> using HTTPS.  I don't know the feasibility for this, but I strongly feel
>> that the more specific the warning could be (instead of just every HTTP
>> site), the more useful they will and will hopefully users will be more
>> attentive to them when they appear.
>>
>> Thank You,
>>
>> Dominick Marciano
>> Programmer/IT Consultant
>
> While the transmission of data is indeed an active concern, I believe you
> underestimate the risks and attacks posed by the mere passive receipt of
> data.
>
> This could be the viewing of a video that is contrarian to local
> authorities. It could be reading an article on reproductive health or
> religious beliefs that are contrary to local norms. Revealing this
> information could get you in "trouble", for some definition of trouble.
>
> You could be reading the news and using the information as part of your
> investment and long-term planning. An attacker who can modify this can
> convince you that the sky is falling - or that there is a grand new
> investment opportunity.
>
> You could be reading a blog, but which an attacker changes the content to
> suggest the blogger is endorsing or holding views contrary to what they
> really hold.
>
> You could be just browsing the web, and a pervasive passive monitor could
> use this to build a profile of you, to track your related experiences on a
> variety of sites, to cross-reference your interactions, and then declare you
> a "threat" for otherwise benign interactions.
>
> You could be reading a website supported by advertising, but that
> advertising might be rewritten to credit the attacker, rather than the site
> you're reading. Over time, the site you're reading may need to shut down,
> because all of their revenue has been stolen by attackers.
>
> The reality is that the confidentiality, integrity, and authenticity of the
> content matters just as much for the receiver as it does the sender. This is
> not merely being done solely for privacy grounds - but even if it was, that
> goal would only be achievable if the response was as protected as the
> request.
>
> The other reality is that the mere act of an HTTP Request leaks a lot of
> ambient state that is not intuitively associable with a user's action or
> intent. Further, when you consider cookies, any proposal to do it
> heuristically on the request devolves quickly into doing it for
> (effectively) every request. This proposal not only simplifies what is
> expected of developers AND vastly simplifies what is messaged to users, but
> it can provide real protection.
>
> However, even on top of all that, this proposal is not explicitly geared
> towards any of what I said - even though it is all true. It is about
> ensuring user agents do not mislead users about the state of the connection,
> as they have for so long, implying through omission that their connections
> are secure or private. For whatever attacks there may be on HTTPS, whether
> implementation to operation, whatever attacks there may be on the content,
> such as XSS or CSRF, it is unquestionable that HTTP is an insecure transport
> that offers zero confidentiality, zero integrity, and zero authenticity, and
> user agents should appropriately reflect that hard truth.
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev+unsubscribe@chromium.org.

Received on Friday, 19 December 2014 18:53:26 UTC