cryptnet(2/2): Treat CRL retrieval errors as non-errors in certificate revocation checking.
juan.lang at gmail.com
Sat Feb 18 21:43:45 CST 2012
This is part two to fix bug 29902.
The trouble starts with the certificate that's being checked. It
contains the following CRL distribution point:
http://corppki/crl/Microsoft Secure Server Authority(8).crl
Yup, MS put a non-qualified domain name in the certificate. Beauty.
So obviously retrieving this fails from anywhere, except, presumably,
Microsoft. I have to assume that native treats such errors as
non-fatal, and indeed, others have shown that appears to be the
case. I'd like to write a test to verify that, but I haven't.
Chalk it up to laziness if you like.
By masking CRL retrieval errors, it's possible for an adversary to
cause a revoked certificate to continue to be used after it's been
revoked, by blocking access to the CRL distribution point. However,
as others have noted, CRL distribution points aren't necessarily known
for their ability to stay up at all times, so CRL checking is
probably not depended on in general to protect against this sort of
attack. Furthermore, cryptnet still doesn't support OCSP checking, so
it's hard to argue that in practice this makes users much more
vulnerable than they already are.
Hence this change. I really hope users who are sensitive to attackers
who can carry out SSL/TLS man-in-the-middle attacks don't use Wine for
their sensitive communications: I wrote this code for my own
interest, not necessarily to protect users' data confidentiality. If
you are, talk to me in another forum! I can try to direct you to
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1055 bytes
Desc: not available
More information about the wine-patches