Bug 114003

Summary: Evolution fails to recognise a valid SSL/TLS server certificate
Product: [Retired] Red Hat Linux Reporter: Jon Warbrick <jw35>
Component: evolutionAssignee: Dave Malcolm <dmalcolm>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: benl, bressers, rbulling, rousseau
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: FC4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-22 00:08:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 171511    

Description Jon Warbrick 2004-01-21 10:12:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
Attempting to contact imap.hermes.cam.ac.uk using IMAP and SSL results
in a warning message form Evolution:

-- cut --
Bad certificate from imap.hermes.cam.ac.uk

Issuer:   /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Server
CA/emailAddress=server-certs
Subject:   /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting
cc/OU=Certification Services Division/CN=Thawte Server
CA/emailAddress=server-certs
Fingerprint:  68:19:dc:c1:2b:ae:12:cc:9b:84:22:08:d7:15:34:a7
Signature:     BAD

Unable to get issuer's certificate locally
-- cut --

imap.hermes does have a valid certificate, issued by Thawte, and this
works find in all other known IMAPS clients. 

The message suggests that Evolution is failing to find its local copy
of Thawte's root certificate which it needs to validate the signature
on imap.hermes's certificate. I would expect that Evolution, like most
SSL/TLS clients, would be pre-configured with the root certificates
from the well known CAs. I can't investigate this since Evolution does
not to provide any way to find out which root root certificates it
knows about. 

Version-Release number of selected component (if applicable):
evolution-1.2.2-5

How reproducible:
Always

Steps to Reproduce:
1. Attempt to opne an IMAPS connection as above
2.
3.
    

Actual Results:  Warning message about bad signature, as above

Expected Results:  Connection with no warning

Additional info:

I've clasified this as a security issue since in general it encourages
users to ignore what is being reported as an SSL certificate error.
Doing so undermines much of the security provided by SSL/TLS.

Comment 1 Dave Malcolm 2004-09-01 18:21:31 UTC
Evolution 1.2.2 is a relatively old version, these days.  Do similar
problems occur for Evolution 1.4.* or later versions?  In Evolution
1.5.93 I can select Tools->Settings->Certificates and view Evolution's
known certificates that way.

Comment 2 Jon Warbrick 2004-09-02 08:50:52 UTC
Well, Evolution 1.2.2 was the version from RH9 that had the problem.
The demise of RH9 and the change to licencing and release arrangements
mean that I'm no longer using Red Hat (nor Fedora) for this
application so I'm not in a position to test anything more current.

One of my colleagues investigated a similar problem with Evolution
1.4.4 and 1.4.6 in the distribution we are now using. In this case the
problem was that Evolution's OpenSSL code was not calling 

  SSL_CTX_set_default_verify_paths(ssl_ctx);

to select use of OpenSSL's default certificate path. He submitted a
patch to the Evolution project but they have declined to include it
since the current 1.5 uses a different crypto library be default
(though the broken OpenSSL code is still provided, just not built). So
it may well be that the problem is fixed in 1.5.

Comment 3 Richard Bullington-McGuire 2005-03-22 15:18:22 UTC
This is still a problem in Evolution 1.4.6, as shipped with Fedora Core 2. I
hope Fedora chooses to fix this issue in a security errata. Jon Warbrick hit
this one on the head. Fedora Core 3 and above avoid this bug by using the
Mozilla NSS SSL cert code instead of the unsupported OpenSSL code. However, it
would still be worth fixing this, since the problem is well-understood and
Fedora Core 2 is still supported. 

Here is a patch to the spec file that fixes the problem (also see below for the
patch referenced in the spec file):

--- evolution.spec.dist 2005-03-22 10:02:40.085564332 -0500
+++ evolution.spec      2005-03-22 10:02:44.244035041 -0500
@@ -22,7 +22,7 @@
  
 Name: evolution
 Version: 1.4.6
-Release: 2
+Release: 2.1.PKR
 License: GPL
 BuildRoot: %{_tmppath}/%{name}-%{version}-root
 URL: http://www.ximian.com/
@@ -60,6 +60,12 @@
 # evolution-wombat but it does work to fix the problem
 Patch500: evolution-wombat-sm.patch
  
+# Fixes openssl certificate negotiation, ximian rejected patch due
+# to unsupported state of openssl in evolution.
+# http://lists.ximian.com/archives/public/evolution-hackers/2004-August/004222.html
+Patch600: evolution-1.4.6-openssl-verify-cert.patch
+
+
 Summary: GNOME's next-generation groupware suite
 Group: Applications/Productivity
  
@@ -162,6 +168,8 @@
  
 #patch500 -p0 -b .wombatsm
  
+%patch600 -p1 -b .openssl-verify-cert
+
 mkdir -p krb5-fakeprefix/include
 mkdir -p krb5-fakeprefix/lib
 mkdir -p krb5-fakeprefix/%{_lib}


This patch should be put in the file "evolution-1.4.6-openssl-verify-cert.patch":

diff -urNp -urNp evolution-1.4.6.old/camel/camel-tcp-stream-openssl.c
evolution-1.4.6/camel/camel-tcp-stream-openssl.c
--- evolution-1.4.6.old/camel/camel-tcp-stream-openssl.c        2003-03-03
22:53:15.000000000 +0000
+++ evolution-1.4.6/camel/camel-tcp-stream-openssl.c    2004-08-18
15:20:09.282083003 +0100
@@ -735,6 +735,7 @@ open_ssl_connection (CamelService *servi
        ssl_ctx = SSL_CTX_new (SSLv23_client_method ());
        g_return_val_if_fail (ssl_ctx != NULL, NULL);
  
+       SSL_CTX_set_default_verify_paths(ssl_ctx);
        SSL_CTX_set_verify (ssl_ctx, SSL_VERIFY_PEER, &ssl_verify);
        ssl = SSL_new (ssl_ctx);
        SSL_set_fd (ssl, sockfd);

Comment 10 Dave Malcolm 2005-10-22 00:08:57 UTC
Cleanup of bugzilla: resolving this bug as the issue is fixed in current release
(FC4), and does not affect FC3.