Re: Proposal: Marking HTTP As Non-Secure

On Mon, Dec 15, 2014 at 5:11 PM, Christian Heutger <christian@heutger.net>
wrote:
>
> >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.
>
> With DV (weak validation) it then goes encrypted to them, I don¹t see the
> advantage. The magic bullet TOR to prevent from being monitored also
> showed up, that the expected privacy may be broken. It¹s a good idea but
> therefor stepping back from the value of PKIX is the wrong way in my
> opinion.
>
> >The race to the bottom among CAs is to blame for the quality of
> >verification by the CAs.
>
> Right, so DV need to be deprecated or set to a recognizable lower level,
> clearly stating that it¹s only encryption, nothing else.
>
> >With companies like StartCom, Cacert and Mozilla offering free
> >certificates, there is no barrier to entry.
>
> And no barrier breaking the value of certificate authorities vs.
> self-signed certificates (Cacert is the only good exception, for a good
> reason their approach is different).
>
> >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.
>
> If a certificate doesn¹t tell, what should tell? How should I be sure to
> be on www.onlinebanking.de and not www.onlínebanking.de
> <http://www.xn--onlnebanking-ufb.de> (see the accent)
> by getting spoofed or phished? It¹s the same for Facebook.com or
> Facebo0k.com, ...
>
> >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).
>
> If there is a free certificate for everyone and everything is https, which
> browser warnings should occur?
>
> >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.
>
> That¹s what certificates are for. If we only would want to have
> encryption, there would never be any requirement for certificates.
> Browsers and servers handle cipher suites, handshakes etc., the
> certificate is the digital equivalent to an authorized identity card, and
> there for sure DV and EV are different. Security is about confidentiality,
> integrity and availability. Confidentiality is the encryption, integrity
> is the validation.
>
> >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).
>
> From the pure technical standpoint, yes, from the validation standpoint,
> no. DANE has the hazel of compatibility, but it also struggle with harder
> mandatory realization of restrictions (online or offline key material, key
> sizes, algorithm, debian bug or heart bleed reissue, Š, all the topics,
> which recently arised), for pinning validated (EV) certificates, it¹s the
> best solution vs. pinning or transparency.
>
> >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).
>
> As there is not internet governance, they are the only available
> alternative. Similar to other agencies existing worldwide, they fetch
> money for validation services and warrant for mis-validation. They are
> dictated strict rules on how to do and be audited to proof, they follow
> this rules. That¹s how auditing currently works in many places and
> although it¹s not the optimal system, it¹s the one currently available.
>
> >Open question: do you think the browsers will support a model other than
> >the CA Zoo for rooting trust?
>
> If a reliable, usable and manageable concept will be established, for
> sure. But as e.g. ISO 27001 establish the same model, there is a company
> being paid for stating what they audited is correct and issuing a seal
> (being ISO 27001 certified) which end users should trust in.
>
>
There's a lot of information here that isn't quite correct, but I would
hate to rathole on a discussion of CA security vs the alternatives, which
inevitably arises when one discusses HTTPS in public fora.

I think the discussion here is somewhat orthogonal to the proposal at hand,
and thus might be best if kept to a separate thread.

The question of whether HTTP is equivalent to HTTPS-DV in security or
authenticity is simple - they aren't at all equivalent, an HTTPS-DV
provides vastly superior value over HTTP. So whether or not UAs embrace
HTTPS-EV is separate. But as a UA vendor, I would say HTTPS-DV has far more
appeal for protecting users and providing security than HTTPS-EV, for many
of the reasons you've heard on this thread from others (e.g. the challenges
regarding mixed HTTPS+HTTP is the same as HTTPS-EV + HTTPS-DV).

So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs
communicate to the user the lack of security guarantees from HTTP.