How GNUTLS-SA-2008-3 was discovered

[Martin von Gagern]

Hi guys!

Simon kindly asked me to share with you how I found this recent issue in
the first place. For those interested, read on. Others may skip it.

Simon Josefsson wrote:
> Martin, btw, how did you find the problem?  It can be useful for me to
> to understand when talking about how GnuTLS security reporting works.

I have a local server authenticated using a CAcert certificate. The
server is an Apache configured to submit its whole chain, which starts
at the CAcert root, includes an intermediate (class 3) certificate from
CAcert and finally arrives at the server certificate.

On that server I have a svn repository, which I recently tried to access
using bzr. The connection failed, and the error message wasn't
particularly useful, openssl s_client had no problems at all, so I
started debugging the code in order to find the cause of this error.

I found out that bzr tried to connect using pycurl, and that my curl
library was using GnuTLS. I'm using Gentoo here, and have most
allications that support GnuTLS use that. Inside the GnuTLS code I
finally got to the actual cause: the class 3 certificate from CAcert was
signed by the root certificate using MD5, which GnuTLS considers broken.

While I stopped to wonder for a moment, I also got worried that this
would affect several other servers I have set up in a similar way. Just
for comparison I connected one of them using the curl command line tool,
and to my surprise found out that it connected without any complaints.

I couldn't fathom the reason for this, and as I had my debugging
environment already set up and knew my way around the GnuTLS
verification code by then, I debugged both connections. I found out that
the problematic MD5-based signature was never actually verified in the
cases where connection succeeded. I found the cause for this in the
broken mechanics of _gnutls_x509_verify_certificate.

With that knowledge, I could finally find the difference in my server
configuration: I had concatenated the chain certificates in the wrong
order, so that the complete list or certificates was 0: server, 1: root,
2: intermediate. Thus on my system, the signature mechanism of the
intermediate certificate caused the error, while on those other systems
with correct setup the root was dropped, and the signature from
intermediate to server certificate was deemed valid, as it uses sha.

Of course once I realized that there was no bug in GnuTLS breaking my
lokal setup, but instead an intentional distrust towards MD5, and that
the other setups only worked because one step wasn't verified at all, I
knew I had found a serious security issue. I performed this model setup
I already wrote about to make sure, and then contacted Simon.

Greetings,
 Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20081111/5c4e9921/attachment.pgp>