Some information was posted to openssl-dev that might be useful: <http://www.mail-archive.com/openssl-dev@openssl.org/msg11212.html>. Also, the thread at <http://groups.google.com/group/comp.mail.imap/browse_thread/thread/6beaf5beda99700c/1334ec809d56bc42?hl=en#1334ec809d56bc42> says:

"The OpenSSL error message from UW imapd that you reported is exactly what
happens when a client negotiates the SSLv23 client method to a server
using the TLSv1 server method.  The SSLv23 client method is correct for
SSL (port 993) IMAP sessions.  It is not correct for TLS (port 143 +
STARTTLS command) sessions."

So I guess Evolution just doesn't know how to talk TLS.

Hi Sam, thanks for taking the time to report this.

Under "Edit > Preferences > Mail Accounts > Edit > Receiving Email", what is your "Server Type"? Please do not use "IMAP4rev1" as it's experimental, use plain "IMAP" instead.

Under "Edit > Preferences > Mail Accounts > Edit > Receiving Email", "Use Secure connection" is set to "TLS", right?

Whiche Evolution version is this exactly?

Server type is IMAP
Secure connection is TLS
Evolution version 2.6.2

various people have reported this problem but I cannot find how this could possibly happen because, as you can see from the code, Evolution doesn't even TRY SSLv23 when a TLS connection has been requested:

#define SSL_PORT_FLAGS (CAMEL_TCP_STREAM_SSL_ENABLE_SSL2 | CAMEL_TCP_STREAM_SSL_ENABLE_SSL3)
#define STARTTLS_FLAGS (CAMEL_TCP_STREAM_SSL_ENABLE_TLS)

static gboolean
connect_to_server (CamelService *service, struct addrinfo *ai, int ssl_mode, CamelException *ex)
{
	CamelImapStore *store = (CamelImapStore *) service;
	CamelImapResponse *response;
	CamelStream *tcp_stream;
	CamelSockOptData sockopt;
	gboolean force_imap4 = FALSE;
	gboolean clean_quit = TRUE;
	char *buf;
	
	if (ssl_mode != MODE_CLEAR) {
#ifdef HAVE_SSL
		if (ssl_mode == MODE_TLS) {
			tcp_stream = camel_tcp_stream_ssl_new_raw (service->session, service->url->host, STARTTLS_FLAGS);
		} else {
			tcp_stream = camel_tcp_stream_ssl_new (service->session, service->url->host, SSL_PORT_FLAGS);
		}
#else
		camel_exception_setv (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
				      _("Could not connect to %s: %s"),
				      service->url->host, _("SSL unavailable"));
		
		return FALSE;
#endif /* HAVE_SSL */
	} else {
		tcp_stream = camel_tcp_stream_raw_new ();
	}

...

static PRFileDesc *
enable_ssl (CamelTcpStreamSSL *ssl, PRFileDesc *fd)
{
	PRFileDesc *ssl_fd;
	
	ssl_fd = SSL_ImportFD (NULL, fd ? fd : ssl->priv->sockfd);
	if (!ssl_fd)
		return NULL;
	
	SSL_OptionSet (ssl_fd, SSL_SECURITY, PR_TRUE);
	if (ssl->priv->flags & CAMEL_TCP_STREAM_SSL_ENABLE_SSL2)
		SSL_OptionSet (ssl_fd, SSL_ENABLE_SSL2, PR_TRUE);
	else
		SSL_OptionSet (ssl_fd, SSL_ENABLE_SSL2, PR_FALSE);
	if (ssl->priv->flags & CAMEL_TCP_STREAM_SSL_ENABLE_SSL3)
		SSL_OptionSet (ssl_fd, SSL_ENABLE_SSL3, PR_TRUE);
	else
		SSL_OptionSet (ssl_fd, SSL_ENABLE_SSL3, PR_FALSE);
	if (ssl->priv->flags & CAMEL_TCP_STREAM_SSL_ENABLE_TLS)
		SSL_OptionSet (ssl_fd, SSL_ENABLE_TLS, PR_TRUE);
	else
		SSL_OptionSet (ssl_fd, SSL_ENABLE_TLS, PR_FALSE);
	
	SSL_SetURL (ssl_fd, ssl->priv->expected_host);
	
	/*SSL_GetClientAuthDataHook (sslSocket, ssl_get_client_auth, (void *) certNickname);*/
	/*SSL_AuthCertificateHook (ssl_fd, ssl_auth_cert, (void *) CERT_GetDefaultCertDB ());*/
	SSL_BadCertHook (ssl_fd, ssl_bad_cert, ssl);
	
	ssl->priv->ssl_mode = TRUE;
	
	return ssl_fd;
}


maybe there's a bug in the SSL library we're using? I have no clue... works fine testing it on my machine.

Perhaps TLS is only available if you have a certain version of Mozilla? (when I say "version" I mean "American version" vs "international version" and not 1.5.1 or whatever - e.g. perhaps there are export regulations on TLS and so TLS won't work for people in certain countries? Not sure...)

I am using a Debian system, in which Evolution is copmiled against xulrunner. Are there any strings, compile options, or similar that I can look for in libnss3-0d to make this determination?

BTW, did you test it against the server I was trying to connect to? If not then feel free to try it...

I wish I knew how to check if TLS is supported by the lib... it was only a guess, I have no idea if it could be the case or not. I was just throwing ideas out there :)

hmmm, nope... just tried against your server and I also get the SSL negotiations failed message, but I don't for my own mail server which is also TLS.

*boggle*

Created attachment 67972 [details]
TCP conection transcript

Here is a transcript of the communication between Evolution and the IMAP server.

Created attachment 67973 [details]
ssldump

And here's the same filtered through ssldump. Perhaps this isn't the same issue as the one discussed in those mailing list postings, after all; we never even reach the client key exchange state.

sadly I don't know the details of the SSL protocol (or the handshake, in this case) - hence why I used Mozilla's SSL library instead of writing my own :)

looks to me tho that the client is sending the data it's supposed to, all of its TLS cipher modes, and the server is just dying?

what does a similar ssldump look like from a working client?

Created attachment 68035 [details]
ssldump of a sucessful TLS negotiation

Here's the result of running ssldump while connecting to the same server with mutt.

The server is definatly tearing down the connection. It's not just dieing randomly, because of the 'wrong version number' error. My money is on evolution trying to handshake with some parameters that the server (which uses OpenSSL) rejects.

Ok, I found an option in /etc/courier/imapd-ssl called TLS_STARTTLS_PROTOCOL. It appears to set the minimum require protocol version; by default it is set to TLS1. If I set it to SSL3 then Evolution can connect with TLS! So it seems Evolution is trying to negotiate an SSL3 connection after all.

*** Bug 356927 has been marked as a duplicate of this bug. ***

Perhaps it would be worth getting someone who is more familiar with NSS to look at this issue, such as a Mozilla developer? i.e., open a bug in Mozilla's bug tracking system, since it seems to be NSS that is screwing up here.

Created attachment 95919 [details] [review]
Disable SSLv2 compatible HELLO on ssl stream when SSLv2 is disabled

CCing matthew to get a review ;)

Niels posted a similar patch to evolution-patches [1] shortly after posting here.  The patch on the mailing list is slightly more verbose and I think I prefer it to this one.  Jeff Stedfast signed off on it and it looks pretty straight forward to me, despite my lack of SSL expertise.  Approving.

Committed to trunk (revision 8192) and gnome-2-20 branch (revision 8193).

[1] http://mail.gnome.org/archives/evolution-patches/2007-September/msg00000.html

yea, his patch on the list should be committed.

Niels: thanks so much for digging into this and finding a fix.