On Tue, Dec 11, 2012 at 12:37 PM, Hans Leidekker <span dir="ltr"><<a href="mailto:hans@codeweavers.com" target="_blank">hans@codeweavers.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Tue, 2012-12-11 at 11:52 -0800, Juan Lang wrote:<br>
> On Tue, Dec 11, 2012 at 6:10 AM, Hans Leidekker <<a href="mailto:hans@codeweavers.com">hans@codeweavers.com</a>> wrote:<br>
>         On Tue, 2012-12-11 at 14:52 +0100, Jacek Caban wrote:<br>
>         > On 12/11/12 09:45, Hans Leidekker wrote:<br>
>         > > <a href="https://testbot.winehq.org/JobDetails.pl?Key=23300" target="_blank">https://testbot.winehq.org/JobDetails.pl?Key=23300</a> is a test which shows that<br>
>         > > revocation checks fail for the certificate on <a href="http://outlook.com" target="_blank">outlook.com</a> when passed straight<br>
>         > > to CertVerifyRevocation. The reason is that a CRL link specified in the<br>
>         > > certificate does not resolve.<br>
>         > ><br>
>         > > <a href="https://testbot.winehq.org/JobDetails.pl?Key=23301" target="_blank">https://testbot.winehq.org/JobDetails.pl?Key=23301</a> is a test which makes<br>
>         > > a secure connection to <a href="http://outlook.com" target="_blank">outlook.com</a> from wininet and shows that this succeeds.<br>
>         > ><br>
>         > > My conclusion is that native wininet doesn't perform revocation checks.<br>
>         ><br>
>         > Your tests prove that we should relax our verification on<br>
>         > CERT_TRUST_IS_OFFLINE_REVOCATION or something similar. To prove that<br>
>         > revocation checks are not made, a test with truly revoked cert would be<br>
>         > needed.<br>
><br>
><br>
>         True, though to perform the revocation check the CRL has to be retrieved and my<br>
>         tests with wireshark didn't show any signs of that.<br>
><br>
><br>
> Would adding to the tests as part of this patch be a bad thing?<br>
<br>
</div></div>I thought about that but I am hesitant to use a random site that's not under our<br>
control.<br>
<br>
The alternative is to setup our own site with a certificate that only fails the<br>
revocation check, which I think means that we need to have it signed by a trusted<br>
root and then revoked. I'm not sure we have the means to do that currently.<br>
<br>
Do you have any suggestions? <br></blockquote></div><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">Returning revocation is straightforward enough, assuming you have a server under your control.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Now, the server: is it possible to have another <a href="http://foo.winehq.org">foo.winehq.org</a> provisioned that returns an arbitrary cert?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra">
--Juan</div>