|
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 |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
