Re: [TLS] Deployment ... Re: This working group has failed

[Andy Lutomirski <[e-mail]>]

On Wed, Nov 27, 2013 at 1:22 PM, Yoav Nir <[e-mail]> wrote:
> On Nov 27, 2013, at 9:55 PM, Andy Lutomirski <[e-mail]>
>  wrote:
>>>> Not at all.  I didn't say "bundled set of trust roots;" I said
>>>> "explicitly chosen".  This would ban, for example:
>>>>
>>>>  - stunnel in client mode with verify = 0 or verify = 1
>>>>  - OpenSSL's SSL_VERIFY_NONE mode
>>>>  - The default behavior of Python's urllib2 module
>>>>
>>>> etc.  If an implementation wanted to offer a scary opt-in way to say
>>>> "make me completely insecure", I have no problem with that.  It's
>>>> unacceptable, though, that the default behavior of a lot of libraries
>>>> is to skip verification.
>>>>
>>>> I personally use TLS with private trust roots -- lots of people do
>>>> this.  The problem is when people use TLS with no trust roots at all.
>>> If by "lots" you mean too many to get them all together for beer night
>>> -- yes. But the kind of technical know-how is in short supply, and
>>> caring about this even among those with technical know-how is also thin
>>> on the ground.
>>>
>>> I'm sure there are thousands of people who use TLS with private trust
>>> roots, as well as thousands of companies. But that's a small portion of
>>> people and companies, and the rest of us also need stuff that works.
>>
>> Do you mean that the rest of us need to write mobile apps that appear to
>> work but are, in fact, insecure?
>
> No. Those of us who write mobile apps need the know-how, and can and should get it. And they should be able to configure a common library to be secure according to their needs. That does not mean that this library should not have any other modes.

Empirically they don't.

Note that I changed my straw-man language to allow an insecure mode.
But I still think that, in any sane TLS implementation, it must be
crystal clear that, by turning off verification, you are doing
something completely insecure.  Insecure-by-default is crap and should
end.

>>
>> I think that the rest of us actually need a TLS library that doesn't
>> suck and an easy and foolproof way to create and use a CA key, CA cert,
>> and server keypair.
>
> OpenSSL scripts are a Google search away. XCA is free and available for all platforms. The more irritating part is dealing with revocation.

XCA looks decent.  The OpenSSL scripts that are a Google search away
AFAICT mostly suck or are at the very least written by people who
don't know what they're talking about.

--Andy