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 <http://crypto.stanford.edu/%7Edabo/pubs/abstracts/ssl-client-bugs.html> -- Jordan Brown, Oracle Solaris
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
