> From: Jordan Brown [mailto:open...@jordan.maileater.net] > Sent: Friday, December 01, 2017 19:48
> On 12/1/2017 2:57 PM, Michael Wojcik wrote: > > 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. Well, I suppose this is the core of our disagreement. I don't think that should be at the top of the priority list, or indeed high enough to make it likely to happen any time soon. 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). Reasonable people can of course disagree. I don't think your position is indefensible; I just don't agree with it. As I said, I recognize the utility ofa simple client library. I wrote one that does secure-by-default myself. It's in a commercial product and I don't control the IP, so it's not open source - but it really wasn't that difficult or time-consuming. Which is probably why a bunch of other people have done it too: libcurl, OpenLDAP (OK, OpenLDAP is a shambling horror), TLS modules for various languages and frameworks, ... And for the server side, the best answer is often "use an existing server". Sure, there are plenty of use cases where that's not feasible, but I also see a fair bit of people writing server-side TLS code when they could simply hang their application off an existing server. 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? > 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. Yes, I'd have to call that a pretty limited use case. It doesn't cover the server side at all. It doesn't do much for client certificates (which browsers do not handle well). For that matter, browsers don't do a very good job with PKI; they basically say "hey, we've decided to trust this collection of public, commercial CAs, and for anything beyond that you're either going to have to know something about X.509 hierarchical PKI, or someone who does will have to hold your hand". They require user interaction when anything out of the ordinary happens, and the UX and UIM for that interaction has historically been a disaster (basically training users to click through warnings). Of late browsers have moved to failling safe with override provisions, but it's still not great UIM. That's 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. > > 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? Libraries and programs written by people who *do* understand cryptography. There are plenty of car manufacturers who don't design and build their own engines. House builders rarely mill their own wood or construct their own windows and doors. Surgeons aren't responsible for building their own X-ray machines or even sharpening their own scalpels. Few authors build their own computers or write their own word processors. Why do programmers need to be in control of so much of their own software stacks? > And why should callers have to understand cipher suites at any deep level? For the same reason electricians need to understand electricity. I don't know how long you've been reading openssl-users. I've been subscribed to it since 2000. I've read a lot of messages from people who understood very little about SSL/TLS. They didn't understand what cipher suites *are* (I'm not asking for any "deep" understanding of the ciphers themselves - though familiarity with known vulnerabilities should be required). They didn't understand the SSL/TLS protocols. They didn't understand X.509 and the hierarchical PKI that's nearly always used with TLS. Often, they didn't understand TCP, which is itself a problem. They weren't keeping up with TLS-related news, which is a *big* problem, and even if they did, they wouldn't know enough to understand it. Those people should not have been using OpenSSL. Those are all correctable problems, of course; most of those people were, presumably, completely capable of learning those things. But they didn't, probably because they didn't understand that it's a necessary part of the job if you want to write code that calls OpenSSL. Or if they did, they weren't given the resources to do so. Or they were lazy, human nature being what it is. > 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? TLS is hard. The OpenSSL API is hard. Making (relatively small) parts of TLS and OpenSSL easier by wrapping them in a client API or hosting applications in a third-party server is entirely possible, since many people (including me) have done it. But I don't see a lot of value in pushing that Easy Mode into OpenSSL itself. That's not where it belongs - layer abstractions and separate concerns. And it encourages the wrong behavior, which is using the OpenSSL API in the first place. That should be left to people who have the luxury (and exercise it) of studying the subject at length. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
