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