Evolution uses weak encryption for SSL/TLS

Confirmed. Evolution does not even propose EAS as a valid ciphersuite when connecting. The following is the output of a ssldump from a Evolution connection to GMAIL at port 995:

3 1 0.1265 (0.1265) C>S SSLv2 compatible client hello
  Version 3.0
  cipher suites
  SSL2_CK_RC4
  SSL2_CK_RC2
  SSL2_CK_3DES
  SSL2_CK_DES
  SSL2_CK_RC4_EXPORT40
  SSL2_CK_RC2_EXPORT40
  SSL_RSA_WITH_RC4_128_MD5
  Unknown value 0xfeff
  SSL_RSA_WITH_3DES_EDE_CBC_SHA
  Unknown value 0xfefe
  SSL_RSA_WITH_DES_CBC_SHA
  SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
  SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
  SSL_RSA_EXPORT_WITH_RC4_40_MD5
  SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
2 2 0.2113 (0.0665) S>C Handshake

I do not know what ciphersuites are represented by 0xfeff and 0xfefe, since they are (theoretically) reserved and private, respectively.

Thank you for your bug. No need to open upstream bug on launchpad, if you do that though could you give a pointer to the upstream bug you opened? The upstream bug for that one is http://bugzilla.gnome.org/show_bug.cgi?id=402925

An additional comment on this: I would really like to be able to select a series of ciphersuites to be used. I guess this would be an advanced option, but would still allow me to at least to deselect those ciphersuites I really do not want to use -- for example, the *EXPORT* ones.

Of course, doing that also depends on what the server accepts, and how the server selects from the list.

Sorry for forgetting to add the upstream bugid.
As hggdh's ssldump shows, Evolution uses weak ciphers by it's own choice.
I guess the upstream-reply is going to be "we do this for compatibility", but I don't see a single cipher that could be considered strong. Neither Blowfish nor Twofish or AES, this is really bad.

it really looks like Evolution is letting the factory defaults for NSS take over -- which means that, although permitted, most of the high-end encryption suites are not enabled.

I am assuming the ubuntu release of Evolution is using libnss (at least this is what is marked). I have not looked at Evolution with OpenSSL.

In camel.c @ camel_init(), Evolution sets up the use of domestic encryption via a call to NSS_SetDomesticPolicy(), but does not set up the (by default) not enabled ciphersuites, which the Mozilla documentation state as required. This would require calls to SSL_CipherPrefSetDefault() globally, or SSL_CipherPrefSet() on each socket. I cannot find any such calls in the code.

So... it looks that Evolution does need a patch in order to allow high-end ciphersuites to be used. It is missing the necessary setup.

c.f. http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1214758

Of course, I may be completely wrong, but I do not think so.

tentative patch below. All SSLV2 ciphersuites are enabled by default, so I do not go on calling SSL_CipherPrefSetDefault() on them. For simplicity, we could.

--- camel.c 2007-01-03 08:56:19.000000000 -0600
+++ camel.c.new 2007-02-05 17:19:20.000000000 -0600
@@ -90,6 +90,7 @@
 #ifdef HAVE_NSS
        if (nss_init) {
                char *nss_configdir;
+ PRUint16 indx;

                PR_Init (PR_SYSTEM_THREAD, PR_PRIORITY_NORMAL, 10);

@@ -108,6 +109,11 @@
                }

                NSS_SetDomesticPolicy ();
+ /* we must enable all ciphersuites */
+ for (indx = 0; indx < SSL_NumImplementedCiphers; indx++) {
+ if (!SSL_IS_SSL2_CIPHER(SSL_ImplementedCiphers[indx]))
+ SSL_CipherPrefSetDefault (SSL_ImplementedCiphers[indx], PR_TRUE);
+ }

                SSL_OptionSetDefault (SSL_ENABLE_SSL2, PR_TRUE);
                SSL_OptionSetDefault (SSL_ENABLE_SSL3, PR_TRUE);

Thank you for your work on that. We will likely wait from upstream comments about that before using the patch though

Yes, I fully agree on waiting for upstream comments -- they will know much more than I do about Evolution.

Meanwhile, I tested my patch here, and sniffed some traffic to GMail. As I expected, Evolution is now sending out a SSL Client Hello with all ciphersuites enabled:

(cut off wireshark's output)

Secure Socket Layer
    SSLv2 Record Layer: Client Hello
        Length: 112
        Handshake Message Type: Client Hello (1)
        Version: SSL 3.0 (0x0300)
        Cipher Spec Length: 87
        Session ID Length: 0
        Challenge Length: 16
        Cipher Specs (29 specs)
            Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080)
            Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080)
            Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
            Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040)
            Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)
            Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080)
            Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039)
            Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038)
            Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035)
            Cipher Spec: TLS_DHE_DSS_WITH_RC4_128_SHA (0x000066)
            Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033)
            Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032)
            Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
            Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
            Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f)
            Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016)
            Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
            Cipher Spec: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0x00feff)
            Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
            Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015)
            Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012)
            Cipher Spec: SSL_RSA_FIPS_WITH_DES_CBC_SHA (0x00fefe)
            Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009)
            Cipher Spec: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x000064)
            Cipher Spec: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x000062)
            Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003)
            Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006)
            Cipher Spec: TLS_RSA_WITH_NULL_SHA (0x000002)
            Cipher Spec: TLS_RSA_WITH_NULL_MD5 (0x000001)
        Challenge

So it is working.

But... a bit to my surprise, gmail still selected the same ciphersuite as before the patch -- TLS_RSA_WITH_RC4_128_MD5. This is not actually unexpected, and was one of the reasons I stated earlier that I would like to be able to select the ciphersuites to be tried on the SSL/TLS session.

Fridtjof -- One thing to be kept in mind is that it is the server that will select a ciphersuite (from the set of common suites). Offering more options will not necessarily result in stronger ciphers being selected by the server. In other words, your mileage may vary among your email servers.

Well, no comment from upstream so far. I still consider this a security-issue as evolution uses a quite weak cipher by default (I can live with RC4-MD5 as fallback, but not as a default).

@Fridtjorf:

I agree, this is, probably, a security concern. But there are some mitigations: RC4-128 is not that weak at all, and there are other safeguards that can be deployed -- like encrypting the e-mail before sending. What I am trying to say is this is not a critical issue, and there is really no need to go fast here.

On the patch I proposed: it only deals with an e-d-s compiled against libnss3, and does not address openSSL at all. So it is certainly not complete. Also, as I stated earlier, I would rather have upstream look at it, since I may very well have done something wrong (this is my first patch against e-d-s, ever).

proposed my patch upstream.

The bug has been fixed upstream applying the patch from hggdh.

the bug is fixed in gutsy