[openssl-users] FIPS certification for openssl

[Jordan Brown]

On 12/2/2017 6:35 AM, Michael Wojcik wrote:
> My personal priority list for OpenSSL is bug fixes and code cleanup
> (static and dynamic analysis of the 1.1.x codebase would be good, and
> one of these days I'll get around to doing it myself), and continuing
> the TLSv1.3 implementation until that standard finally settles down.
> (I'm not much of a TLSv1.3 fan, but customers will demand it.) If
> there's spare time, the docs always need work. PKCS#12 support could
> be improved (though maybe it's better in 1.1.x). 

I would never, ever, object to putting bug fixes at the top of the list.

But at the same time we're talking about trying to prevent bugs in the
callers, and that's valuable too.

> A better question might be "why are the common cases common at all?". Why are so many people writing code that calls the OpenSSL API?

Because they know they need a secure connection, and they know that that
means TLS/SSL, and they know that the leading library for TLS/SSL is
OpenSSL, and nothing says "you should be using libFOO instead".  You
look for the key under the street light, because that's where the light is.

> [Emulating a browser is] fine for some things, but it doesn't help
> with servers and it falls over for non-interactive use (or even
> interactive but non-GUI), or for anything where PKI gets more
> complicated. 

And yet it's probably better than 95% of what you'll get from
non-experts rolling their own.

My work is almost entirely non-interactive during production.  So far,
I've been pretty happy with a model that says "emulate a browser during
initial interactive configuration, then use those settings during
production and light a yellow light when anything goes wrong".

(And yes, of course browsers aren't servers... there I'd say "Emulate
Apache httpd".)

>> What should they use instead [of OpenSSL]?
> Libraries and programs written by people who *do* understand cryptography.

It seems like our only disagreement is in who should supply those
libraries, whether OpenSSL should supply one or should leave it to others.

> Why do programmers need to be in control of so much of their own software stacks?

Totally agreed, they shouldn't.  They need to be guided into doing the
right thing.  It should be hard to do the wrong thing.  Everybody will
be happier.

>> Why should they need to know any more than "there are multiple algorithms, and new algorithms are introduced
>> occasionally, and old algorithms are defeated occasionally, but you may need old algorithms for interoperability, so
>> you need to have a way to select which algorithms you accept"?  That's pretty much the limits of my mental model;
>> what am I missing?
> Urgh. I don't really have room (or permission) to post all of Ivan Ristic's /Bulletproof TLS/ book here.
>
> Let's try this. "The C language has various operators and standard library functions, and new functions are introduced occasionally, and old functions are deprecated occasionally, but you may have code that uses old functions, so you need to pick what functions you'll use." Is that a good mental model for writing C programs?

I have a simplistic viewpoint, but the operators in C are mostly
distinct and do different things, while the cipher suites all do the
same things, differing only internally.  I don't know, nor do I want to
know, how algorithm X is different from algorithm Y, or what key lengths
are considered adequate this week.  If I write my application to
incorporate any of that knowledge, it will be wrong next year.  My
application needs to not care which algorithms it's using, and to be
trivially adaptable (preferably at runtime) as the situation changes
over the years.  Anything that I know about the actual algorithms will
probably make that picture worse, not better.  As you say, those
decisions need to be made by people who *do* understand these things...
which excludes 99% of developers.

Thanks for the thoughtful discussion.  I really appreciate it.

-- 
Jordan Brown, Oracle Solaris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20171202/249601bc/attachment.html>