[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

CRL and OCSP verification [was: Re: svn commit: r1863018 ...]

From: Branko Čibej <brane_at_apache.org>
Date: Sun, 14 Jul 2019 10:33:23 +0200

On 14.07.2019 00:29, Branko Čibej wrote:
> On 13.07.2019 23:31, kotkov_at_apache.org wrote:
>> Author: kotkov
>> Date: Sat Jul 13 21:31:25 2019
>> New Revision: 1863018
>>
>> URL: http://svn.apache.org/viewvc?rev=1863018&view=rev
>> Log:
>> Win32: tweak the SSL certificate validation override to avoid hitting the wire
>> for URL based objects and revocation checks.
>>
>> The primary purpose of this callback is to resolve SVN_AUTH_SSL_UNKNOWNCA
>> failures using CryptoAPI and Windows local certificate stores. To do so, we
>> should be fine with just using the immediately available data on the local
>> machine.
>>
>> Doing the opposite of that appears to be troublesome, as always connecting
>> to remote CRL and OCSP endpoints can result in spurious errors or significant
>> (user-reported) network stalls caused by timeouts if the endpoints are
>> inaccessible or unreliable.
>>
>> The new approach should also be in par with the default basic behavior of
>> several major browsers, for example:
>> https://chromium.googlesource.com/chromium/src/net/+/3d1dad1c17ae3ff59e7c35841af94b66f4bca1ba/cert/cert_verify_proc_win.cc#919
>
> Uh. I don't think so.
>
> First of all, the reference to Chromium source is a red herring ... that
> code disables CRL/OCSP checks *if some caller required it to*. You'll
> find that browsers do, indeed, check CRL or OCSP info, if it's available.
>
> Your change disables all online verification, regardless, and that seems
> quite wrong.
>
> If the server certificate contains CRL or OCSP information, the client
> SHOULD verify them. If verification services are flaky, users should
> report that to the server admin (who can then report it to the
> certificate issuer). We don't "fix" that by removing validation
> altogether in our client.
>
> So ... -1, please revert and let's discuss this change on the list
> first. It's far more significant than you seem to think.

To start off this discussion, I'll note that we don't currently use CRLs
or OCSP on other platforms. This is probably because Serf 1.3.9 doesn't
give us any support for that (though it does support OCSP stapling).

However, the as yet unreleased Serf 1.4.0 does have support for OCSP
(I'd have to double-check about CRL).

In any case, given what year it is on the calendar, we SHOULD try to add
OCSP verification to the client. The server can already do that for
client certs, since it's only a matter of httpd configuration.

-- Brane

P.S.: Yes, I realize this means getting Serf 1.4.0 out the door first ...
Received on 2019-07-14 10:33:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.