|
On 11/30/2017 5:41 AM, Michael Wojcik
wrote:
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. Yes, compatibility is a concern. So make the "default to secure" options be new functions. 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. You really think that most applications handle all this stuff right? See below. 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. Is it really right that a basic client (from the O'Reilly book) is over 300 lines long? (client3.c, common.c, reentrant.c) But the really dangerous thing is that if you miss a step, what you get is a silently insecure connection rather than a failure. Do you really like having OpenSSL featured in papers like this? The most dangerous code in the world: validating SSL certificates in non-browser software -- Jordan Brown, Oracle Solaris |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
