--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
> You are almost certainly far better qualified to make this decision than most
> administrators.
Not sure who the "you" is. Me, openssl, or the original poster :)
> Nevertheless, if upgrading OpenSSL from version X to version
> Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE,
> there are going to be angry phone calls from users whose browser or
> application has stopped working. It is the administrator who is going to get
> those phone calls, not you
I am more concerned about the case where a common crypto type is broken, and
zillions (a technical term :) of websites are now at-risk because there wasn't
an immediate OpenSSL update that added the broken crypto to the VULNERABLE
list, and everyone didn't update immediately.
Policy and configuration should be on a separate, arguably faster, distribution
pattern than code. Which is why I favor a "profile" mechanism in openssl.conf
and not hardwired magic keywords embedded in code.
> So there’s bettercrypto.org and there’s Qualys and there’s this BCP
> document that the UTA working group at the IETF is writing
Perhaps modesty prevented you from posting the link, but it won't stop me
(we're both in the acknowledgements section :)
https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07
_______________________________________________
openssl-dev mailing list
openssl-dev@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
