W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: Jeffrey Walton <noloader@gmail.com>
Date: Mon, 15 Dec 2014 04:29:52 -0500
Message-ID: <CAH8yC8njyrr=V6DgBFivduSVFE=J0bVRs2UJXAZrPO-ggVR5kg@mail.gmail.com>
To: Christian Heutger <christian@heutger.net>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, "blink-dev@chromium.org" <blink-dev@chromium.org>, "security-dev@chromium.org" <security-dev@chromium.org>, "dev-security@lists.mozilla.org" <dev-security@lists.mozilla.org>
On Sat, Dec 13, 2014 at 2:05 PM, Christian Heutger
<christian@heutger.net> wrote:
> I see a big danger in the current trend.

Surely you haven't missed the big danger in plain text traffic. That
traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
Access Operations (TAO). In layman's terms, adversaries are using the
information gathered to gain unauthorized access to systems.

> Expecting everyone having a free
> „secure“ certificate and being in requirement to enable HTTPS it will result
> in nothing won. DV certificates (similar to DANE) do finally say absolute
> nothing about the website operator.

The race to the bottom among CAs is to blame for the quality of
verification by the CAs.

With companies like StartCom, Cacert and Mozilla offering free
certificates, there is no barrier to entry.

Plus, I don't think a certificate needs to say anything about the
operator. They need to ensure the server is authenticated. That is,
the public key bound to the DNS name is authentic.

> They ensure encryption, so I can then be
> phished, be scammed, … encrypted. Big advantage!^^

As I understand it, phishers try to avoid TLS because they count on
the plain text channel to avoid all the browser warnings. Peter
Gutmann discusses this in his Engineering Security book
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

> Pushing real validation
> (e.g. EV with green adressbar and validated details by an independent third
> party, no breakable, spoofable automatism) vs. no validation is much more
> important and should be focussed on.

You should probably read Gutmann's Engineering Security. See his
discussion of "PKI me harder" in Chapter 1 or 6 (IIRC).

> However, this „change“ could come with
> marking HTTP as Non-Secure, but just stating HTTPS as secure is the
> completely wrong sign and will result in more confusion and loosing any
> trust in any kind of browser padlocks than before.

Security engineering studies seem to indicate most users don't
understand the icons. It would probably be better if the browsers did
the right thing, and took the users out of the loop. Gutmann talks
about it in detail (with lots of citations).

> Just a proposal:
>
> Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red padlock or
> sth. similar.

+1. In the browser world, plaintext was (still is?) held in higher
esteem then opportunistic encryption. Why the browsers choose to
indicate things this way is a mystery.

> Mark HTTPS as Secure (and only secure in favor of encrypted) e.g. with a
> yellow padlock or sth. similar
> Mark HTTPS with Extended Validation (encrypted and validated) as it is with
> a green padlock or sth. similar

Why green for EV (or why yellow for DV or DANE)? EV does not add any
technical controls. From a security standpoint, DV and EV are
equivalent.

If DNS is authentic, then DANE provides stronger assurances than DV or
EV since the domain operator published the information and the
veracity does not rely on others like CAs (modulo DBOUND).

Not relying on a CA is a good thing since its usually advantageous to
minimize trust (for some definition of "trust"). Plus, CAs don't
really warrant anything, so its not clear what exactly they are
providing to relying parties (they are providing a a signature for
money to the applicant).

Open question: do you think the browsers will support a model other
than the CA Zoo for rooting trust?
Received on Monday, 15 December 2014 09:30:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC