Security implications of (not using) GNUTLS_VERIFY_DO_NOT_ALLOW_SAME

[Nikos Mavrogiannopoulos]

Lars Noschinski wrote:

>>>> Ok. But in this case, the behaviour I observed seems to be indeed a bug
>>>> in gnutls, as my certificate list did not contain the server's
>>>> certificate, but only the CA certificates.
>>> Then please send me something I can reproduce (such as the smallest
>>> possible list that I can use to verify the problem and how I can
>>> verify it).
> 
> For the certificate list, see
> 
>     http://avalon.hoffentlich.net/~cebewee/debug/gnutls/cacert.crt
> 
> (containing the CAcert.org root certificates).
> 
> Now,
> 
>     $ gnutls-cli jabberd.jabber.ccc.de --x509cafile cacert.crt
> 
> trusts the server certificate [0]. Now apply the patch [1] to cli.c
> and run the patched binary. Now

Hi,
 Thank you. I've checked the issue and although it sounds strange this
quirk of the flag has some logic here. Check what is the output of
certtool -e to the list sent by jabberd:

> Certificate[0]: C=DE,ST=Hamburg,L=Hamburg,O=Chaos Computer Club e.V.,CN=jabber.ccc.de
>         Issued by: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root
>         Verifying against certificate[1].
>         Verification output: Verified.
> 
> Certificate[1]: O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root
>         Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org
>         Verifying against certificate[2].
>         Verification output: Not verified, Insecure algorithm.
> 
> Certificate[2]: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org
>         Issued by: O=Root CA,OU=http://www.cacert.org,CN=CA Cert Signing Authority,EMAIL=support at cacert.org
>         Verification output: Verified.
> 
> Chain verification output: Not verified, Insecure algorithm.

The Certificate[1] is signed using an insecure algorithm.

Here you can see that normally gnutls should reject that certificate
list. However if the DO_NOT_ALLOW_SAME flag is not set (default), gnutls
will keep for verification only Certificate[0] and will verify it
against the trusted list and thus passes. However if you set the flag
then the list is verified as is and the last certificate in the list
is checked against the trusted list. That is the reason for the
different result.

I have commited a fix in master to have the same result for both methods
by allowing the shortening of the list even if the DO_NOT_ALLOW_SAME
flag is set except for the 1st certificate (which is the certificate
that the flag refers to).


You can avoid the problem by having the server only send the first
certificate. Sending the whole chain does not help any client who must
anyway trust Certificate[1] explicitly since it is signed with insecure
algorithm.

regards,
Nikos