>> Just to clarify any possible confusion, whether or not a piece of software >> actively uses the heartbeat makes no difference to the bug, you are still >> vulnerable simply by virtue of the feature being there. Make sure that if >> you are using an effected version of openssl, you patch openssl. > > I understood Hanno's question like this: > Why the hell is everybody forced to deploy half-baken code in security > sensitive systems which is only needed in 0.000001% use-case niches like DTLS? A lot of folks have been asking that.
> This is related to the > why-gets-TLS-more-and-more-bloated-and-how-should-implementors-ever-get-this-right > discussions on ietf-tls mailing list. There are a lot of opinions on it. I think the thread of iterest (or the one I've been following) is: "[TLS] Heartbleed / protocol complexity", http://www.ietf.org/mail-archive/web/tls/current/msg11891.html > A clarifying note especially to OpenSSL developers: > Many thanks for your work and I feel your pain these days. +1. > But maybe it's the right time to think about putting two feet on the brake > pedal against the feature bloat. I think something helpful would be a SSL_OP_NO_* for heartbleed and other less used features. I'm not sure how to do it since it appears all the masks are already allocated, though (the most recent addition, SSL_OP_SAFARI_ECDHE_ECDSA_BUG, reused a previous value). At minimum, a good enumeration of the various -DOPENSSL_NO_*. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
