On 02/07/15 19:03, Ruediger Pluem wrote:
<snip>
Just to be sure I don't miss anything. This is not about disabling OCSP, its
about disabling OCSP stapling by default.
Maybe I have a wrong understanding of OCSP stapling, but to me stapling only
provides performance improvements, not
security improvements for the client as the client still could connect to the
OCSP URL given in the cert directly and
get the answer from there. If the response is stabled it does not need to (with
the same level of security) and saves
itself a roundtrip to the OCSP server of the CA and the OCSP server of the CA a
request to process.
Yes, the client _could_ connect to the OCSP URL given in the cert
directly and get the answer from there. However, at least one major
browser (Chrome) no longer does this, but it does process stapled OCSP
responses.
Even if we could ignore Chrome...
There will always be some clients that cannot reach the CA's OCSP
responder directly (due to connectivity issues at the client side),
whereas the TLS servers that those clients connect to may well have
better connectivity (and thus be able to staple OCSP responses that the
client cannot obtain by any other means).
Also, this isn't just about performance. If a client contacts an OCSP
responder directly, it reveals to the CA that it is interested in a
particular certificate. That's a far worse privacy leak than a TLS
server contacting a CA's OCSP responder and revealing that it's
interested in the status of its own certificate!!
These are the same organization whose management are often those targeted by
malware anyways. It's on them if they
choose to ignore what few security measures are available to the less savvy end
user.
Again I don't get what this has to do with malware attacks on these
organizations, but maybe my understanding of OCSP
stapling is entirely wrong.
Regards
Rüdiger
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
