Re: [HASMAT] Fwd: [TLS] TLS, PKI, and web security. Was: Eleven out of every ten SSL certs aren't valid

[Adam Barth <[e-mail]>]

Yeah, Strict-Transport-Security is meant to address at least one of
the threats discussed below (namely users who click through TLS error
messages).  FWIW, empirical measurements from the Chrome browser (of
those users who opt in to sharing anonymous usage statistics) show
that users click through approximately 80% of TSL warning screens.
This statistic is not as dispositive as it might seem because it says
nothing about whether clicking through those screens was or was not
the correct security decision at the time.

Some people have the notion that you should focus only on one threat
model, but it seems entirely sensible to design security systems that
provide a protection across a spectrum of threat models.

Lastly, most of the studies about the prevalence of TLS certificate
errors have serious methodological errors.  For example, most would
conclude that E*TRADE has misconfigured TLS certificates because
https://etrade.com/ gives such an error, even though the vast, vast
majority of E*TRADE customers never see that "error."  (E*TRADE uses
https://us.etrade.com/, which does have a valid TLS certificate.)

Adam


On Fri, Jul 2, 2010 at 8:39 AM, Peter Saint-Andre <[e-mail]> wrote:
> Some interesting discussions from the TLS WG list. Marsh's reflections
> on the state of the art have some applicability to the HASMAT effort, I
> think.
>
> /psa
>
> -------- Original Message --------
> Subject: [TLS] TLS, PKI, and web security. Was: Eleven out of every ten
> SSL certs aren't valid
> Date: Fri, 02 Jul 2010 03:47:23 -0500
> From: Marsh Ray <[e-mail]>
> To: Peter Gutmann <[e-mail]>
> CC: [e-mail]
>
> On 07/01/2010 10:54 PM, Peter Gutmann wrote:
>>
>> (I'm dreading someone asking "OK, list all these refs" because then
>> I'll have to go away and spend several hours digging them all up...
>> how many do people want before they say "OK, that's enough"?.
>> Cormac's paper has about eight, and that's barely scratching the
>> surface).
>
> I believe you - surely most people will click through most warnings most
> of the time.
>
>> No, it says that what we're doing doesn't work, has never worked, and
>> as far as anyone can tell will never work (and we have a
>> multibillion(?) dollar global cybercrime indistry to prove it), so
>> lets look for alternatives that do work.
>
> But still, most of those people lost their online banking credentials to
> the global cybercrime industry to a phishing email, because they use the
> same password everywhere, because their endpoint PC is owned by a
> keylogging botnet, or all of the above. They got this way by buying
> downloading commercial application software in brightly colored boxes,
> not keeping it up-to-date, and trusting a UI when it says "this
> executable is signed and has a shield icon, click OK to let it own your
> computer".
>
> They likely did not get owned by a MitM of their SSL/TLS connection
> where they clicked through a scary page.
>
> Some observations:
>
> 1. This is not evidence that "browser warnings are ineffective". If
> anything it shows that HTTPS is categorically better than most other
> parts of this system.
>
> 2. These users are completely incompetent relative to the impossibly
> hard job of keeping a general-purpose computer secure while consuming
> content from the hostile internet. (This is not to say anything bad
> about them, they are probably wiser for not wasting too much personal
> energy on managing data security.) It will be forever impossible to keep
> them "safe online", just like 200 years of experience in postal
> technology has not eliminated mail fraud.
>
> Therefore I strenuously object to this "least-common-denominator users
> confidently spending money online" model being allowed to drive the
> discussion of TLS. It is simply not possible to have a meaningful
> technical discussion about a cryptographic data security protocol unless
> we can agree that both Alice and Bob have a baseline of self-interest
> and competence to secure their endpoints.
>
>>Let's just admit
>> that what users are getting now is effectively unauth'd DH and then
>> try and give them something that actually works.
>
> No! Not this user, and not the systems I help to build and deploy. There
> are all kinds of interesting, embedded, automated, unattended, and
> large-scale systems successfully using TLS for securing critical data
> communications.
>
> More importantly, there _are_ careful and conscientious admins who do a
> totally professional job at maintaining their production systems
> according to recommended best practices. It is the requirements of this
> group that TLS must be optimized to meet. For if the competent
> professional cannot successfully employ the full security of this
> protocol, what chance does that leave for the typical user?
>
> Consider the biggest shift in data processing in decades is cloud
> computing. Cloud management and seemingly every piece of new networking
> gear presents a web-based admin UI for use with your ordinary browser.
> So the security of the apps, documents, servers, VPNs, and even big
> parts of the network itself has been rebuilt atop TCP port 443.
>
> This architecture self-organized due to powerful economic and social
> forces, not because anyone felt it was the best way from a security
> perspective. So we really have no choice but to get our protocol
> primitives nailed down air-tight:
>
> * Users must be informed of the essential role they have in the security
> architecture. They need to know a bit more of the mechanics of PKI in
> order to bring to bear the common sense that people are actually pretty
> good at. I suspect most people will take it seriously and can actually
> do a respectible job of it, just like most people understand not to use
> a hair dryer in the bathtub. Note that that little bit of user education
> cost neither bathtubs nor hair dryers any market share.
>
> * PKI built on the absolute trust of hundreds of omnipotent root certs
> from friend and foe alike just doesn't cut it any more. Vendors of the
> disintegrating status quo need to lead with some real improvements or
> embrace obsolescence.
>
> * Server admins need to be informed that HTTPS does not allow the server
> to prove the nonexistence of a MitM, the protocol relies on the client
> to do a good job of this. Therefore the server ends up having no choice
> but to transitively trust the union of all the sets of trusted root
> certs of all the clients that could be used to access the system.
>
> * TLS client certificate auth can allow the server to disprove the MitM.
> Web clients and servers should implement first-rate support for this
> configuration and provide integrated tools for users and admins to
> manage them.
>
> * A limited, securable subset of this insane layer cake of protocols we
> currently call "the web" needs to be precisely defined and adopted. Its
> use must become accepted as required best practice in security critical
> contexts, much like https has. It must include a browser security model
> with well-defined and strong boundaries.
>
> * Much as we once thought security would result naturally from a
> thorough analysis of functional requirements, current designs sometimes
> meet stated security goals yet have undesirable properties relating to
> expectations of privacy. Mechanisms for identifying and metadata tagging
> relevant information (as we may sometimes retain character data encoding
> information) and implementing data handling policies (much like database
> integrity constraints) should be standardized.
>
> * The identities of all parties contributing content, script, and
> cookies affecting the current page need to be prominently displayed and
> greatly restricted for secure systems. There may yet still be time to
> prevent your firewall's admin page from hosting web bugs for advertisers
> and participating in social networking mashups.
>
> Anyway, just some thoughts on things that could use improving. It seems
> like TLS itself is decent shape and is in a good position to expand its
> role in support of some larger goals.
>
> - Marsh
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> HASMAT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hasmat
>
>