3 ms·

if i understand correctly this one is relevant to certificate issuers that publish certificate revocation lists via the OCSP protocol; could be used for denial

if i understand correctly this one is relevant to certificate issuers that publish certificate revocation lists via the OCSP protocol; could be used for denial of service but not for hacking into the certificate issue, is that correct? Also most bugs in OpenSSL seem to be during renegotiation of protocol zzzz defined by some obscure RFC that nobody really understands how to implement, is that correct? Why can't they simplify these protocols, do we really need these fancy renegotiation features? Actually Daniel Bernstein says that over-complicating the protocols is a clever way to make sure that software infrastructure remains insecure. https://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf https://cr.yp.to/talks/2014.10.18/slides-djb-20141018-a4.pdf

pfg 10y ago
AIUI this affects the code that handles the TLS extension with which a client tells the server that it supports OCSP stapling, so any server with an affected openssl version would be vulnerable.
AlyssaRowan 10y ago
Simplifying the protocol, making it easier to analyse (and prove) and especially removing legacy things we know are troublesome is the main goal of the draft TLS 1.3: now already live and rolled out across CloudFlare and Chrome, and which removes such things as renegotiation, all non-AEAD ciphersuites, MD5, SHA-1, static RSA, and many of the other classic TLS bugbears which keep bearing interesting vulnerabilities. Which isn't to say the optional (but usefully fast) 0-RTT mode might not introduce a few more, for those lackadaisical devs who inevitably ignore all dire warnings and abuse it for non-idempotent requests like POSTs (or GETs that do something - bad idea!). But even if it's not how I would have designed it afresh (the Noise Protocol Framework from Trevor Perrin is how I would have designed a new connection protocol now) it's still a big improvement over previous TLS/SSL iterations and a drastic enough change it probably deserves to be called TLS 2.0.

pfg 10y ago

AIUI this affects the code that handles the TLS extension with which a client tells the server that it supports OCSP stapling, so any server with an affected openssl version would be vulnerable.

AlyssaRowan 10y ago

Simplifying the protocol, making it easier to analyse (and prove) and especially removing legacy things we know are troublesome is the main goal of the draft TLS 1.3: now already live and rolled out across CloudFlare and Chrome, and which removes such things as renegotiation, all non-AEAD ciphersuites, MD5, SHA-1, static RSA, and many of the other classic TLS bugbears which keep bearing interesting vulnerabilities. Which isn't to say the optional (but usefully fast) 0-RTT mode might not introduce a few more, for those lackadaisical devs who inevitably ignore all dire warnings and abuse it for non-idempotent requests like POSTs (or GETs that do something - bad idea!). But even if it's not how I would have designed it afresh (the Noise Protocol Framework from Trevor Perrin is how I would have designed a new connection protocol now) it's still a big improvement over previous TLS/SSL iterations and a drastic enough change it probably deserves to be called TLS 2.0.