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

[Peter Saint-Andre <[e-mail]>]

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