Re: wininet: Don't perform revocation checks when verifying a certificate.
Hi Hans, On 12/11/12 09:45, Hans Leidekker wrote:
https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that revocation checks fail for the certificate on outlook.com when passed straight to CertVerifyRevocation. The reason is that a CRL link specified in the certificate does not resolve.
https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes a secure connection to outlook.com from wininet and shows that this succeeds.
My conclusion is that native wininet doesn't perform revocation checks.
Your tests prove that we should relax our verification on CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that revocation checks are not made, a test with truly revoked cert would be needed. Jacek
On Tue, 2012-12-11 at 14:52 +0100, Jacek Caban wrote:
On 12/11/12 09:45, Hans Leidekker wrote:
https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that revocation checks fail for the certificate on outlook.com when passed straight to CertVerifyRevocation. The reason is that a CRL link specified in the certificate does not resolve.
https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes a secure connection to outlook.com from wininet and shows that this succeeds.
My conclusion is that native wininet doesn't perform revocation checks.
Your tests prove that we should relax our verification on CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that revocation checks are not made, a test with truly revoked cert would be needed.
True, though to perform the revocation check the CRL has to be retrieved and my tests with wireshark didn't show any signs of that.
On Tue, Dec 11, 2012 at 6:10 AM, Hans Leidekker <hans(a)codeweavers.com>wrote:
On Tue, 2012-12-11 at 14:52 +0100, Jacek Caban wrote:
On 12/11/12 09:45, Hans Leidekker wrote:
https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that revocation checks fail for the certificate on outlook.com when passed straight to CertVerifyRevocation. The reason is that a CRL link specified in the certificate does not resolve.
https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes a secure connection to outlook.com from wininet and shows that this succeeds.
My conclusion is that native wininet doesn't perform revocation checks.
Your tests prove that we should relax our verification on CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that revocation checks are not made, a test with truly revoked cert would be needed.
True, though to perform the revocation check the CRL has to be retrieved and my tests with wireshark didn't show any signs of that.
Would adding to the tests as part of this patch be a bad thing? --Juan
On Tue, 2012-12-11 at 11:52 -0800, Juan Lang wrote:
On Tue, Dec 11, 2012 at 6:10 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: On Tue, 2012-12-11 at 14:52 +0100, Jacek Caban wrote: > On 12/11/12 09:45, Hans Leidekker wrote: > > https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that > > revocation checks fail for the certificate on outlook.com when passed straight > > to CertVerifyRevocation. The reason is that a CRL link specified in the > > certificate does not resolve. > > > > https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes > > a secure connection to outlook.com from wininet and shows that this succeeds. > > > > My conclusion is that native wininet doesn't perform revocation checks. > > Your tests prove that we should relax our verification on > CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that > revocation checks are not made, a test with truly revoked cert would be > needed.
True, though to perform the revocation check the CRL has to be retrieved and my tests with wireshark didn't show any signs of that.
Would adding to the tests as part of this patch be a bad thing?
I thought about that but I am hesitant to use a random site that's not under our control. The alternative is to setup our own site with a certificate that only fails the revocation check, which I think means that we need to have it signed by a trusted root and then revoked. I'm not sure we have the means to do that currently. Do you have any suggestions?
On Tue, Dec 11, 2012 at 12:37 PM, Hans Leidekker <hans(a)codeweavers.com>wrote:
On Tue, 2012-12-11 at 11:52 -0800, Juan Lang wrote:
On Tue, Dec 11, 2012 at 6:10 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: On Tue, 2012-12-11 at 14:52 +0100, Jacek Caban wrote: > On 12/11/12 09:45, Hans Leidekker wrote: > > https://testbot.winehq.org/JobDetails.pl?Key=23300 is a test which shows that > > revocation checks fail for the certificate on outlook.comwhen passed straight > > to CertVerifyRevocation. The reason is that a CRL link specified in the > > certificate does not resolve. > > > > https://testbot.winehq.org/JobDetails.pl?Key=23301 is a test which makes > > a secure connection to outlook.com from wininet and shows that this succeeds. > > > > My conclusion is that native wininet doesn't perform revocation checks. > > Your tests prove that we should relax our verification on > CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that > revocation checks are not made, a test with truly revoked cert would be > needed.
True, though to perform the revocation check the CRL has to be retrieved and my tests with wireshark didn't show any signs of that.
Would adding to the tests as part of this patch be a bad thing?
I thought about that but I am hesitant to use a random site that's not under our control.
The alternative is to setup our own site with a certificate that only fails the revocation check, which I think means that we need to have it signed by a trusted root and then revoked. I'm not sure we have the means to do that currently.
Do you have any suggestions?
I agree with you that this is a little finicky to test, but I think it's tractable. The desired outcome is a server trusted by the client under test, presenting a valid server cert, under two conditions: where the server cert's revocation can't be tested, and where the server's cert is actually revoked. First the easy bit: testing what happens when the revocation can't be checked involves a valid cert with a CRL distribution point that doesn't respond. Easy, as long as you can create the server cert that the client trusts. Getting the client to trust the server cert can be as easy as ignoring untrusted root errors, if you don't think this impacts the revocation results. Returning revocation is straightforward enough, assuming you have a server under your control. Now, the server: is it possible to have another foo.winehq.org provisioned that returns an arbitrary cert? If not, it's possible to run a server locally, but this is a lot more code overhead, so probably not worth it for this go around. --Juan
On Tue, 2012-12-11 at 12:59 -0800, Juan Lang wrote:
Getting the client to trust the server cert can be as easy as ignoring untrusted root errors, if you don't think this impacts the revocation results.
Returning revocation is straightforward enough, assuming you have a server under your control.
So self-sign the CRL too. I guess that might work if ignoring untrusted root errors extends to verification of the CRL.
On Wed, Dec 12, 2012 at 12:32 AM, Hans Leidekker <hans(a)codeweavers.com>wrote:
On Tue, 2012-12-11 at 12:59 -0800, Juan Lang wrote:
Getting the client to trust the server cert can be as easy as ignoring untrusted root errors, if you don't think this impacts the revocation results.
Returning revocation is straightforward enough, assuming you have a server under your control.
So self-sign the CRL too. I guess that might work if ignoring untrusted root errors extends to verification of the CRL.
Actually, I was thinking a 2-certificate chain, with the root signing the CRL. I don't think a cert that revokes itself has a lot of meaning. --Juan
participants (3)
-
Hans Leidekker -
Jacek Caban -
Juan Lang