[openssl-users] FIPS certification for openssl
openssl at jordan.maileater.net
Sat Dec 2 00:47:39 UTC 2017
On 12/1/2017 2:57 PM, Michael Wojcik wrote:
>> 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.
Sorry, I wasn't trying to propose any particular concrete interfaces. I
was trying to speak abstractly: "a client should be able to say 'give
me a secure connection to host:port' and have sensible and secure things
happen with a single call. Maybe two, one to create a handle and the
other to actually set up the connection (to allow for intervening calls
that customize the connection)." (OK, yeah, I did get a bit more
concrete later, but I never said "change the existing functions".)
> 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 only I had the time. I do greatly respect the work that people do on
FOSS projects. I just wish more would focus on getting the common cases
to be easy and bulletproof, and less on being all things to all people.
>>>> 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.
Maybe I just don't have a big enough picture, but in my TLS-related work
(mostly client LDAP, but some other stuff) I keep coming back to a
browser as the behavior that I should emulate.
> 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".
What should they use instead?
What *should* core OpenSSL developers be focused on?
And why should callers have to understand cipher suites at any deep
level? 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?
Jordan Brown, Oracle Solaris
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users