Re: Proposal: Marking HTTP As Non-Secure

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.