Re: Proposal: Marking HTTP As Non-Secure

My interest in this is I study and design HTTP servers and content
management systems professionally, including HTTPS website deployment for a
Certificate Authority.

I would first like to note that there is a very high cost to implementing
HTTPS. For individuals, they have to verify ownership of a domain name
and/or business entity, install a TLS certificate, and then figure out why
their embeds and scripts stopped working. For enterprise, we have to figure
out how to mint and revoke large numbers of certificates, and store large
numbers of private keys securely (a database with ten thousand private TLS
keys is a very precious target indeed!).

If someone uses HTTPS, they do so because they anticipate they need the
security. Especially considering someone took on a not-insignificant cost
to ensure that their users would have that security. The request for
security means something!

HTTP could mean, simply, "I don't care about security". A TLS failure means
"Security is _required_ by the other party, but couldn't be set up and
verified. Abort! Abort!"

Purporting that plaintext and HTTPS failure is the same would be
conditioning users to be less worried about HTTPS failures, where there's a
known _requirement_ for confidentiality.

There may be some value in saying "as with many network requests,
request/submission is being sent in the clear. Anyone on your network will
be able to read this!". But big scary warnings are most certainly bad. No
matter what, before I claim anything for sure, I would like to see a
double-blind study, and not change for the sake of change.

There are alternatives. Security should be a boolean: you either have it or
you don't, BUT different people have different criteria for what meets the
standard of "secure".

If I'm connecting to my bank, or conducting business, I want an EV
certificate signed by a mutually trusted third party verifying legal
corporate ownership of the domain name (after all, I might have mistyped
it!).

If I'm embedding a cat video on my website, the end-user doesn't care who
the owner is, a chain of trust is satisfactory: If the end-user can trust
me with their passwords, they can trust me to say "that cat picture I'm
embedding from that other site is OK, here's how you can verify their
authenticity."

Traditionally, this is done with TLS which has to meet the same standards
as a user-facing website, that the website is signed by a mutually trusted
third party Certificate Authority. This need not be the only way.

This could also be done with embedding TLS certificates in the user-facing
website, embedding TLS certificates in DNS records as DANE specifies, or
embedding integrity hashes, as Subresource Integrity does.

Support for these methods, in Web browsers and in future generations of
Webservers and content management applications, would reduce the cost of
security, and make it more accessible.

Saying all these alternatives are the same to everyone will HURT security
by making it more costly to deploy (i.e. the value of the next best
(insecure) alternative goes up, in economist terms).

So, let's not treat different "levels" (methods) of security as the same
(plaintext, TLS failure, TLS revoked certificate, SRI, DANE, TLS
self-signed, TLS CA signed, EV, ...). They're all (boolean) secure or
insecure depending on context, and much of this context is known and usable
by the user agent. (Some isn't: loading cat pictures might be secure enough
for most people to not warrant any failure, even over plaintext; but
performing any write actions (like logging in, posting a comment) on said
website would be a failure. Currently, unfortunately, there is no
technology/vocabulary that would let us distinguish between these two
cases. In other cases, what constitutes "secure" is negotiated: I might not
want to reveal to my employer I'm browsing cat pictures, ever; but I am
fine with my coffee shop knowing this, especially if it means more ads for
funny cats.)

Instead, let's deploy more options for securing content. DANE is designed
for this. If there's a problem with DANE the spec, then let's fix that; but
there's NO good reason to require that all requests in all cases must be
CA-verified. If I want a secure connection with "me.example" -- just the
server -- why wouldn't a TLSA record be acceptable, but a signature from
any one of a few hundred CAs would be?

Finally, let's remember this problem exists for other protocols too (CoAP,
email, DNS, NTP). A solution, if it indeed is a solution, will be
deployable to these protocols. (I particularly think security of NTP is
underrated, considering it plays a huge role in security now: It sets
system dates used in PKI, and even finances with peer-to-peer block chains
like Bitcoin.)

Austin Wright.

On Fri, Dec 12, 2014 at 5:46 PM, Chris Palmer <palmer@google.com> wrote:

> Hi everyone,
>
> Apologies to those of you who are about to get this more than once, due to
> the cross-posting. I'd like to get feedback from a wide variety of people:
> UA developers, web developers, and users. The canonical location for this
> proposal is:
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> .
>
> Proposal
>
> We, the Chrome Security Team, propose that user agents (UAs) gradually
> change their UX to display non-secure origins as affirmatively non-secure.
> We intend to devise and begin deploying a transition plan for Chrome in
> 2015.
>
> The goal of this proposal is to more clearly display to users that HTTP
> provides no data security.
>
> Request
>
> We’d like to hear everyone’s thoughts on this proposal, and to discuss
> with the web community about how different transition plans might serve
> users.
>
> Background
>
> We all need data communication on the web to be secure (private,
> authenticated, untampered). When there is no data security, the UA should
> explicitly display that, so users can make informed decisions about how to
> interact with an origin.
>
> Roughly speaking, there are three basic transport layer security states
> for web origins:
>
>
>    -
>
>    Secure (valid HTTPS, other origins like (*, localhost, *));
>    -
>
>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>    with minor TLS errors); and
>    -
>
>    Non-secure (broken HTTPS, HTTP).
>
>
> For more precise definitions of secure and non-secure, see Requirements
> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
> Content <http://www.w3.org/TR/mixed-content/>.
>
> We know that active tampering and surveillance attacks, as well as passive
> surveillance attacks, are not theoretical but are in fact commonplace on
> the web.
>
> RFC 7258: Pervasive Monitoring Is an Attack
> <https://tools.ietf.org/html/rfc7258>
>
> NSA uses Google cookies to pinpoint targets for hacking
> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>
> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>
> How bad is it to replace adSense code id to ISP's adSense ID on free
> Internet?
> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>
> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>
> Erosion of the moral authority of transparent middleboxes
> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>
> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>
> We know that people do not generally perceive the absence of a warning
> sign. (See e.g. The Emperor's New Security Indicators
> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
> Yet the only situation in which web browsers are guaranteed not to warn
> users is precisely when there is no chance of security: when the origin is
> transported via HTTP. Here are screenshots of the status quo for non-secure
> domains in Chrome, Safari, Firefox, and Internet Explorer:
>
> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>
> [image: ie-non-secure.png]
>
> Particulars
>
> UA vendors who agree with this proposal should decide how best to phase in
> the UX changes given the needs of their users and their product design
> constraints. Generally, we suggest a phased approach to marking non-secure
> origins as non-secure. For example, a UA vendor might decide that in the
> medium term, they will represent non-secure origins in the same way that
> they represent Dubious origins. Then, in the long term, the vendor might
> decide to represent non-secure origins in the same way that they represent
> Bad origins.
>
> Ultimately, we can even imagine a long term in which secure origins are so
> widely deployed that we can leave them unmarked (as HTTP is today), and
> mark only the rare non-secure origins.
>
> There are several ways vendors might decide to transition from one phase
> to the next. For example, the transition plan could be time-based:
>
>
>    1.
>
>    T0 (now): Non-secure origins unmarked
>    2.
>
>    T1: Non-secure origins marked as Dubious
>    3.
>
>    T2: Non-secure origins marked as Non-secure
>    4.
>
>    T3: Secure origins unmarked
>
>
> Or, vendors might set thresholds based on telemetry that measures the
> ratios of user interaction with secure origins vs. non-secure. Consider
> this strawman proposal:
>
>
>    1.
>
>    Secure > 65%: Non-secure origins marked as Dubious
>    2.
>
>    Secure > 75%: Non-secure origins marked as Non-secure
>    3.
>
>    Secure > 85%: Secure origins unmarked
>
>
> The particular thresholds or transition dates are very much up for
> discussion. Additionally, how to define “ratios of user interaction” is
> also up for discussion; ideas include the ratio of secure to non-secure
> page loads, the ratio of secure to non-secure resource loads, or the ratio
> of total time spent interacting with secure vs. non-secure origins.
>
> We’d love to hear what UA vendors, web developers, and users think. Thanks
> for reading!
>