Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

On 24 Dec 2014 03:53, "Austin William Wright" <aaa@bzfx.net> wrote:
>
> 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!

No, the request for a resource means something. Security is about the
quality of service in delivering said thing.

> HTTP could mean, simply, "I don't care about security".

Then user agents should be free to act on behalf of users to write off
correspondents who do not value the user enough to protect the message in
transit.

You're making claims about what UA's must do from the perspective of
servers; this is a clear agency problem misunderstanding.

We're the user's agent, not the publisher's.

> 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.

The UA could develop different (but also scary) UI for these conditions.

Regardless, we have done a poor job communicating the effective system
model (that content is not tamper-evidentwhen served over HTTP). Steps to
make this clearer aren't the same thing as throwing all distinction
overboard.

> 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.

This sort of argument might have worked in '12. Apologies, but you're
dreadfully late.

> 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 and 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
>>
>> NSA uses Google cookies to pinpoint targets for hacking
>>
>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>>
>> How bad is it to replace adSense code id to ISP's adSense ID on free
Internet?
>>
>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>>
>> Erosion of the moral authority of transparent middleboxes
>>
>> Transitioning The Web To HTTPS
>>
>>
>> We know that people do not generally perceive the absence of a warning
sign. (See e.g. The Emperor's New Security Indicators.) 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:
>>
>>
>>
>>
>>
>>
>> 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:
>>
>>
>> T0 (now): Non-secure origins unmarked
>>
>> T1: Non-secure origins marked as Dubious
>>
>> T2: Non-secure origins marked as Non-secure
>>
>> 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:
>>
>>
>> Secure > 65%: Non-secure origins marked as Dubious
>>
>> Secure > 75%: Non-secure origins marked as Non-secure
>>
>> 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!
>
>
> To unsubscribe from this group and stop receiving emails from it, send an
email to blink-dev+unsubscribe@chromium.org.