Re: Proposal: Marking HTTP As Non-Secure

On Dec 15, 2014 1:29 AM, "Jeffrey Walton" <noloader@gmail.com> wrote:
>
> 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.
>

>From an SOP point of view, this is true.
However, it is increasingly less true if you're willing to ignore the (near
cataclysmic) SOP failure, as EV gains technical controls such as
certificate transparency and pontentially mandatory stronger security
settings (e.g. secure ciphersuites in modern TLS, OCSP stapling, etc).
Additionally, there are other technical controls (validity periods, key
processing) that do offer distinction.

That is, it is not all procedural changes, and UAs can detect and
differentiate. While the hope is that these will be able to apply to all
sites in the future, any change of this scale takes time.

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

Chromium has no plans for this, particularly those based on DNS/DANE, which
are empirically less secure and more operationally fraught with peril. I
would neither take it as foregone that the CA system cannot improve nor am
I confident that any of the known alternatives are either practical or
comparable in security to CAs, let alone superior.