wininet: Don't perform revocation checks when verifying a certificate.

[Juan Lang]

On Tue, Dec 11, 2012 at 12:37 PM, Hans Leidekker <hans at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20121211/0ce20235/attachment.html>