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

[Marsh Ray <[e-mail]>]

On 07/03/2010 02:09 AM, Peter Gutmann wrote:
> [Just a general note, if people think this is off-topic and want it moved to
>   private mail I'd be happy to do that, but I think it's an interesting
>   discussion, TLS is more than just getting the bits on the wire right, it's
>   also a matter of applying it effectively]

Agreed, but any suggestions where?

> Marsh Ray<[e-mail]>  writes:
>
>> 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.
>
> If browsers implemented credential security properly (client-side password
> deversification and failsafe mutual auth) then the only one on that list
> that'd still be a threat is man-in-the-browser attacks, and for that one, once
> your machine is 0wned it's pretty much game over anyway.  So there are things
> that can be fixed, they're just not getting fixed.

May I propose that we abandon this new term "MitB" if what we're really 
talking about is just an old compromised endpoint? It seems kind of like 
jargon to make the situation of the "owned PC" sound more sophisticated 
and complicated than it really is. But maybe I'm missing some aspect of 
its meaning that gives it utility.

>> 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.
>
> Uhh, going back to the list of studies again, there's been study after study
> after study showing they are ineffective - they have next to no effect on user
> behaviour.

Note I did not say that browser warnings were effective, I said that 
this was not evidence that they were ineffective.

> because the title sprung to mind when you mentioned "browser warnings".  These
> things don't work.
>
>> 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.
>
> My interest is in keeping real-world users secure.

Me too, but I think it's useful to split the problem into two parts:

1. Is TLS an effective and secure cryptographic protocol primitive? Does 
it deliver on the stated and implied guarantees given by its RFCs?

2. What's the best policy and UI design for web browsers to maximize the 
effective security given the human, commercial, and political factors 
involved?

I like discussing both these issues. But I think it's very useful to 
keep them separate because one of these is a solvable engineering 
problem appropriate for the [TLS] list and the other is probably not. 
Also, TLS is useful independent of web browsers and even PKI.

> If I'm providing security
> tools that don't do that then I'm not doing my job properly.  It's not the
> user's job to learn whatever geeky stuff I think they need to know, it's my
> job to give them something that keeps them secure (or at least as secure as
> possible under the circumstances, I can't do much about an 0wned PC).  So I
> think it is very valid to discuss it in terms of lowest-common-denominator
> users, because that's who'll be using our tools.

Considering the LCD is certainly important. I think it's also important 
that those with the more stringent requirements (and who are willing to 
invest the time to deploy stuff properly) don't get fairly represented 
in the design process due because of our low expectations of the LCD.

But the good news is that TLS has evolved to be flexible enough to cover 
everyone's needs without having to trade off one group against each 
other. The web browser user would scarcely notice a difference between 
modern TLS and the original SSLv2, but most of us would agree that that 
one is a huge improvement over the other.

>> 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.
>
> Uhh, but what does that have to do with protecting users going to bank and
> online shopping web sites?

That's my point: there's other (critically important) stuff that uses 
TLS besides web shopping.

> (Two points in response to this: (1) if you control the environment then you
> can push out pretty much anything you want as your security system, including
> nothing at all (geographic entitlement, to authenticate yourself you have to
> enter the room where the equipment is and plug in an ethernet cable), so this
> isn't really a major feat,

Agreed, securing communications between systems in well-managed 
datacenters is much easier. It's also a huge and really important market.

> and (2) compared to the Internet at large there are
> close to zero attacks on these sorts of systems (and in the odd exceptions
> when SCADA-type stuff has been attacked in the past it's been found to be
> swiss cheese), so "successfully using TLS" really means "we got data from A to
> B", not "it's been proven resistant to a concerted attack").

You're right - it may be claiming too much to say anyone is 
"successfully using TLS".

It turned out that for a long time all my datacenter systems were 
vulnerable to the renegotiation bug.But so were most of the web 
shoppers' connections, too. So we factor that out and all that remains 
for my claim is that I have deployed TLS communications between 
datacenter systems that:
- reliably transfer lots of data
- aren't susceptible to any publicly-known vulnerabilities
- protect against some trivial attacks that a web browser operated by a 
user willing to click past a cert error does not.

As you point out, that's no great feat.

>> 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.
>
> Uh... I thought it was to protect Joe Sixpack from having his credit card
> stolen?

That's a good goal too, of course, but it's not exactly the kind of 
system I work on at work.

I also object to online shopping CC security being used as some sort of 
"gold standard" use case for TLS. Sure SSL was originally cooked up at 
Netscape to convince people it was safe for them to give out their CC 
online and it's still obviously a majorly important case.

But today https is just as likely to be used to secure webmail, software 
auto-updates, SOAP web services, you name it. SMTP runs over TLS for 
goodness sake. Personal privacy is a whole new dimension for web 
security that was little considered in the original design of SSL.

The battle of the CC numbers is all but lost. The bad guys have more CCs 
than they know what to do with, they get them by the tens of thousands 
from imperfectly secured merchants (and even processing centers). But 
they were not lost due to TLS (we believe, in most cases).

> Professional sysadmins are the last person you want to worry about
> optimising for, any sysadmin worth his salt will be able to secure their data
> given no more than chewing gumm and rubber bands.

Perhaps, but I think he'd get more consistent results with a well 
engineered secure socket protocol in his toolbox.

>  It's the 1.7-billion or so
> global population of users who aren't professional sysadmins that I'm
> interested in helping, not a handful of sysadmins somewhere.

I'd like to help them too. But I don't see how they would be helped by a 
solution that involves weakening the theoretical maximum security of 
TLS, https, or web browsers.

>> * 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.
>
> Umm... I better not reply to a statement like this, because the response would
> be... inflammatory.

Nah, won't bother me. We might take it off list though.

>> * 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.
>
> Steffen, you've won your prize :-).
>
> (For people who don't get the ref, it's:
>
>   "Now comes the part where somebody replies that this is all solved by client
>   certificates and the discussion is closed 'til next time...)"

I didn't say it was all solved by client certs, I tried to say there was 
this one specific, under-appreciated limitation of the usual https that 
they addressed. Originally I had that sentence at the end of the bullet 
before it, I don't remember why I separated it out. It was pretty late 
when I wrote that, I plead insanity. :-)

Regards,

- Marsh