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

On Wed, Dec 24, 2014 at 3:43 PM, Alex Russell <slightlyoff@google.com>
wrote:

>
> 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.
>
Specifically, I refer to privacy and authentication (which seems to be what
"security" means here). There's many components to security, and they're
not all going to be desired at the same level for every request, sometimes
even at odds with each other. Deniability is a particularly expensive one
to implement, often at significant monetary and performance cost to the
user. Deniability is simply not implemented by any website (or more
accurately, any authority) indexed by the major search engines.

It's difficult to claim that deniability, though, is about "quality of
service", but it is nonetheless considered something _very_ important by
Tor, and by users of it.


> > 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.
>
When a user navigates to an https:// resource, or hits the checkbox for
STARTTLS, or selects "Require encryption" from a drop-down, they, the user,
are *demanding* a secure connection (for someone's definition of secure;
traditionally this means privacy and authentication but need not include
deniability).

If we want to talk about the perspective of servers, the server has options
to demand a secure connection too; it simply has to deny plaintext requests
(it could redirect, but this risks the user-agent sending sensitive
information including request-uri that'll just be ignored), and TLS can
specifically ask for or require a client TLS certificate for authentication.

The user-agent works for the user, not the other way around. Letting a
user-agent intervene in the case of a plaintext request is imposing a value
on the user: It prioritizes privacy over "DO NOT BREAK USERSPACE!" which is
not *necessarily* true.

If TLS were free or very cheap to implement, however, this would be a
non-issue. Hence my treatment of ways to do this.

Even if the http-as-non-secure proposal fully worked; it still increases
the cost of publishing content and barriers to entry. I recall Tim
Berners-Lee recollecting that requiring users mint a long-lived URI was
concerning cost; but there was no other way to design a decentralized Web.
(In the end, the biggest barrier to entry has been acquisition of a domain
name and hosting.)

Of course, if efficiency and security are at odds, then we prefer security.
However, I see making TLS implementation cheaper as a viable alternative to
this proposal, and so is far more appealing.

> > 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.
>
I am specifically referring to the part of the proposal that, in the long
term, specifies no UI difference between plaintext and failed-TLS.

Would you care to make an alternate proposal with this change?

> 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.
>
I'm afraid snark wasn't my first language, so you'll have to refresh my
memory: what are you referring to?

Earlier in my message, I touched on the danger of users dismissing warnings
for their e.g. bank, because users become dismissive of "insecure
connection" warnings found elsewhere.

Now, we might have HSTS (for my bank example), but at that point we're no
longer talking about two tiers of security, but three (insecure-bypassable,
insecure-nonbypassable, secure), which is precisely what the proposal is
advocating moving _away_ from (or, the proposal is not very clear on this
point, and a clarification in its text would be necessary).

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

Received on Saturday, 27 December 2014 01:34:02 UTC