[openssl-users] FIPS certification for openssl

[Michael Wojcik]

> From: Jordan Brown [mailto:openssl at jordan.maileater.net] 
> Sent: Friday, December 01, 2017 17:18

> On 11/30/2017 5:41 AM, Michael Wojcik wrote:

> > There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break 
> > many applications - and so it's likely those applications would stop updating their OpenSSL builds.

> Yes, compatibility is a concern.  So make the "default to secure" options be new functions.

That's certainly better than what you proposed in your previous messages. It's still not where I'd want to see the core OpenSSL developers spending their time, though.

Of course, anyone's free to write their own API on top of what OpenSSL provides, and even make a pull request to contribute it to the project.

> > If the application is well-written, the user doesn't need the application source now. If the application isn't well-written,
> > being able to change "settings" is not one of your bigger problems.

> You really think that most applications handle all this stuff right?  See below.

No. That's not what I wrote.

> > > Looking at it another way:  browsers manage to do it...
> > Manage to do what, exactly? And how are browsers a good model for the vast range of OpenSSL applications? They're
> >  just one type of client that nearly always uses a very particular PKI model.

> Manage to make reasonably secure connections with a minimum of user hassle.

Still just one type of client.

> Is it really right that a basic client (from the O'Reilly book) is over 300 lines long?  (client3.c, common.c, reentrant.c)

As I said: nothing is stopping anyone from wrapping that up in an API.

> But the really dangerous thing is that if you miss a step, what you get is a silently insecure connection rather than a
>  failure.

Depends on what step you miss.

Look, I'm well aware this is a problem. I just gave an internal presentation to a roomful of developers on this very subject in October. But I don't think changing OpenSSL to consult "per-user or system-wide configuration files" by default - which is what you appeared to propose in the note I was responding to - is the right solution. Nor, as I said above, do I think it's where the OpenSSL Project developers should be focussing their efforts at this time. If someone else wants to, fine - though I think it's a much harder problem than you're making it out to be.

> Do you really like having OpenSSL featured in papers like this?
> The most dangerous code in the world: validating SSL certificates in non-browser software

Better than being omitted. And I'm well aware of that paper (an old [well, since 2012] favorite); I discussed it in the talk I mentioned above.

Frankly, what I'd like is fewer people using OpenSSL at all. Not necessarily fewer applications, but fewer *people*. Cryptography and security are inherently difficult; TLS is particularly bad, because of its history, configurability, interoperability demands, and horrendously broken PKI. It's an area for experts. I'd like the barrier to entry to be *higher*, so we'd see fewer people posting messages like "I tried to write a server using OpenSSL but I don't understand cipher suites".

Hell, as the "Most Dangerous Code" paper itself points out at some length, JSSE tried for "secure by default", but many JSSE-based applications use the wrong APIs and unwittingly bypass certificate validation. Secure-by-default is extremely difficult with TLS.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus