Re: [HACKERS] GnuTLS support

On 05/06/18 00:44, Peter Eisentraut wrote:
> On 6/2/18 16:50, Heikki Linnakangas wrote:
>> On 08/03/18 14:13, Peter Eisentraut wrote:
>>> There are two failures in the SSL tests that I cannot explain. The
>>> tests are for some rather obscure configurations, so the changed
>>> behaviors are not obviously wrong, perhaps legitimate implementation
>>> differences. But someone wrote those tests with a purpose (probably),
>>> so we should have some kind of explanation for the regressions.
>>
>> I applied this over commit 4e0c743c18 (because this doesn't compile
>> against current master, needs rebasing), and ran "make check" in
>> src/test/ssl. All the tests passed. I'm using GnuTLS version 3.5.8. What
>> failures did you see?
>
> The patch adjusts the expected test results so that the tests pass.

Ah, gotcha.

> Look for the tests named
>
> - "connect with server CA cert, without root CA"

So, in this test, the client puts the server's certificate in
sslrootcert, but not the CA cert that the server's certificate was
signed with. OpenSSL doesn't accept that, but apparently GnuTLS is OK
with it.

I think the GnuTLS behavior is reasonable, I was actually surprised that
OpenSSL is so strict about that. If the user explicitly lists a server's
certificate as trusted, by putting it in sslrootcert, it seems
reasonable to accept it even if the CA cert is missing.

> - "CRL belonging to a different CA"

Hmm. So in OpenSSL, when we load the CRL, we call
X509_STORE_set_flags(cvstore, X509_V_FLAG_CRL_CHECK |
X509_V_FLAG_CRL_CHECK_ALL). With that option, if a CRL for the server CA
cannot be found (in this case, because the CRL is for a different CA),
OpenSSL throws an error. Apparently, GnuTLS is more lenient. At a quick
glance, I don't see an option in GnuTLS to change that behavior. But I
think we can live with it, it's not wrong per se, just different.

- Heikki