GNOME Bugzilla – Bug 589323
SSL verification fails due to not setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
Last modified: 2009-07-26 17:47:30 UTC
I've migrated SyncEvolution from libcurl to libsoup as part of integrating it into Moblin. One of the long-standing issues was that SSL verification wasn't enabled due to not setting a CA file: http://bugzilla.moblin.org/show_bug.cgi?id=4220 Now I have the CA file, but it fails to verify https://m.google.com/sync http://bugzilla.moblin.org/show_bug.cgi?id=4551 Google uses a certificate signd by Thawte, which is signed by Verisign. With libcurl-gnutls and in Firefox this peer is accepted. I compiled libsoup 2.26.3 and gnutls 2.4.2 (Ubunty Jaunty) from source and traced it down to this check here:
+ Trace 216567
(gdb) list 263 if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) && 264 !((flags & GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) && issuer_version == 1)) 265 { 266 if (check_if_ca (cert, issuer, flags) == 0) 267 { 268 gnutls_assert (); 269 if (output) 270 *output |= GNUTLS_CERT_SIGNER_NOT_CA | GNUTLS_CERT_INVALID; 271 return 0; 272 } libsoup does not pass any flags, so check_if_ca() is called and fails. libcurl passes flags = 2 = GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT, so this check is skipped. There are some discussions around that flags which might be relevant: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509593 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514807 The Verisign root certificate indeed seems to be version 1, so at first glance everything seems to work as intended... except that this is not particularly useful. As long as Google doesn't get a different certificate from Verisign, the only fallback is using plain http. What is the recommendation for handling this problem? Educate users that SSL with Google is not secure and therefore has to be rejected or somehow set the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT flag? How?
Created attachment 139077 [details] [review] minor fix: check that gnutls_certificate_allocate_credentials() really succeeded
Created attachment 139078 [details] [review] set GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT As discussed with Dan on IRC, setting the flag should be safe because the CA certs file is meant to contain only CA certificates. This patch depends on the other one. Both are against gnome-2-26.
the irc conversation: <danw> the problem they describe with V1 certs shouldn't apply to libsoup, because libsoup only lets you specify CA certs, not host/people certs, so the problem of not being able to distinguish CA certs from host certs can't possibly come up <danw> so it should be safe for us to pass the flag you mentioned <pohly> danw: are you sure? What if the CA certificate file that is passed by the app contains both CA root certificates as well as host/people certs? Isn't that possible with the current API? <pohly> I'm talking about the client here. <pohly> SOUP_SESSION_SSL_CA_FILE <danw> well... the documentation says that the file is supposed to contain CA certs, so if you pass a file containing non-CA certs it's undefined :) <pohly> Fair enough ;-) I'm not going to worry about the possibility of allocate_credentials() failing, because if it fails, then the next glib-based allocation will fail too, and that will cause an abort(). Given that, the other patch didn't apply cleanly, and I didn't want the huge comment in there anyway, so I just replaced it with a reference to this bug. committed and pushed. thanks for the fix.