> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf Of Jordan Brown > Sent: Thursday, November 30, 2017 00:34 > On 11/29/2017 6:13 PM, Salz, Rich via openssl-users wrote: > > I agree with you, but a problem is that “safe and secure” changes over time when new crypto and other new features > > are added. And then users get upset when their connections no longer work. That, and many applications will reasonably disagree on what an appropriate default is. > Still, I'd rather have compatibility problems - as long as there's a way to explicitly request the less-secure option - than > silently be insecure. But some other people would not prefer compatibility problems. There are a great many OpenSSL consumers. Making radical changes to the default behavior of the API would break many applications - and so it's likely those applications would stop updating their OpenSSL builds. > Having per-user or system-wide configuration files that are consulted under the covers would help, For many applications, no, it really wouldn't. It would be a huge mess. > since then the user could revert to less-secure settings without needing the application source. If the application is well-written, the user doesn't need the application source now. If the application isn't well-written, being able to change "settings" is not one of your bigger problems. > Maybe have the "create handle" function take an application name as an argument, so that individual applications > could be managed separately. And we have another namespace problem. No thanks. > 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. Not all the world's a VAX. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
