Re: Thunderbird 3.1 SSL/TLS Renegotiation

  Hi,

I would like to point out that we don't have the TB 3.1 (testing with 
3.1.1) problem here while testing against version 1.19-rc2 (provided 
patch applied or not doesn't matter for us). Here is the SSL part of the 
config we use for Perdition, same config as for our live 1.18 servers 
that do have the problem:

ssl_mode ssl_listen (Actually we use ssl_listen,tls_listen on our 1.18 
servers, but got a ssl_mode error in 1.19 when trying that so guess that 
is not a valid mode after all)
ssl_no_cn_verify
ssl_ca_file /etc/perdition/cacert.crt
ssl_cert_file /etc/perdition/mail.crt
ssl_key_file /etc/perdition/mail.key

Don't know if using ssl_no_cn_verify gives the same fix as you listed 
for ssl_no_client_cert_verify and ssl_no_cert_verify, so that might be 
the case why it's working here on 1.19-rc2 for us.

I would like to hijack this thread a bit and add/ask the following: If 
we use tls_listen for our ssl_mode clients can no longer connect and 
Perdition throws this error:
Jul 27 10:25:59 mail perdition[28962]: Fatal Error reading 
authentication information from client X:58785->Y:994: Exiting child

Shouldn't this work just as with ssl_listen?

Also I would like to point out this warning we have during build:

ssl.c: In function ‘perdition_ssl_ctx’:
ssl.c:522: warning: assignment discards qualifiers from pointer target type

greetings
JS

On 2010-07-27 03:49, Simon Horman wrote:
> On Mon, Jul 26, 2010 at 11:36:56PM +0200, John Feuerstein wrote:
>> Hi List,
>>
>> I've just searched the July 2010 Archives [1] for a problem with Mozilla
>> Thunderbird 3.1 and a TLS connection to Perdition, but
>> am still missing a solution.
>>
>> After connecting to Perdition, Thunderbird 3.1 emits warnings like:
>>
>>> Server "[email protected]" has disconnected.
>>> The server may have gone down or there may be a network problem.
>> Looking into the perdition logs reveals:
>>
>>> perdition[9088]: Connect: 121.121.121.121->123.123.123.123
>>> perdition[9088]: Fatal error establishing TLS connection
>> The same when running perdition in debug mode:
>>
>>> perdition[10304]: Connect: 121.121.121.121->123.123.123.123
>>> perdition[10304]: SELF:   "* OK IMAP4 Ready 121.121.121.121 0001cd8b\r\n"
>>> perdition[10304]: CLIENT: "1 capability\r\n"
>>> perdition[10304]: SELF:   "* CAPABILITY IMAP4 IMAP4REV1 STARTTLS\r\n"
>>> perdition[10304]: SELF:   "1 OK CAPABILITY\r\n"
>>> perdition[10304]: CLIENT: "2 STARTTLS\r\n"
>>> perdition[10304]: SELF:   "2 OK Begin TLS negotiation now\r\n"
>>> perdition[10304]: __perdition_ssl_connection: error:140D9115:SSL routines:SSL_GET_PREV_SESSION:session id context uninitialized
>>> perdition[10304]: __perdition_ssl_connection: SSL_accept
>>> perdition[10304]: __perdition_ssl_connection: no shared ciphers?
>>> perdition[10304]: perdition_ssl_server_connection: perdition_ssl_connection
>>> perdition[10304]: main: perdition_ssl_server_connection TLS
>>> perdition[10304]: Fatal error establishing TLS connection
>> I think the "no shared ciphers" is misleading here, it's the first
>> message that looks b0rked:
>>
>>> perdition[10304]: __perdition_ssl_connection:
>>> error:140D9115:SSL routines:SSL_GET_PREV_SESSION:
>>> session id context uninitialized
>> This could be related to the SSL/TLS renegotiation [2] done by the
>> recent Mozilla stack because of CVE-2009-3555, as pointed to by Thierry
>> Hotelier some days ago [3].
>>
>> There is another mail by Giorgio Paolucci [4] indicating a problem with
>> the ssl/tls session caching (which really matches the error message).
>> Too bad the proposed fix (patch?) did not end up in the mailing list
>> archive. Could someone (Georgio?) please re-post this patch inline so
>> others will find it without being subscribed?
>>
>> After a quick search on openssl-users it looks like this can be fixed
>> using SSL_CTX_set_session_id_context.
>>
>> Any news on this?
> Hi John,
>
> thanks for chasing this up and thanks for pointing out
> SSL_CTX_set_session_id_context(). I agree that is the
> right fix.
>
> Could any of the interested parties test the following patch?
>
> From: Simon Horman<[email protected]>
>
> ssl: Set session_id
>
> This allows session re-negoatiation to work
> in conjunction with the verification of client certificates.
>
> In particular, it allows Thunderbird 3.1 to connect to perdition using TLS.
>
> An alternate work-around is to disable all certificate verification using
> --ssl_no_client_cert_verify or disable client certificate verification
> using --ssl_no_cert_verify (introduced in 1.19-rc1).
>
> This relates to Mozilla Bug #575915
> https://bugzilla.mozilla.org/show_bug.cgi?id=575915
>
> Signed-off-by: Simon Horman<[email protected]>
>
> Index: perdition/perdition/ssl.c
> ===================================================================
> --- perdition.orig/perdition/ssl.c	2010-07-27 10:37:40.000000000 +0900
> +++ perdition/perdition/ssl.c	2010-07-27 10:38:41.000000000 +0900
> @@ -528,6 +528,14 @@ SSL_CTX *perdition_ssl_ctx(const char *c
>   		return NULL;
>   	}
>
> +	/* Set context for session */
> +	if (!SSL_CTX_set_session_id_context(ssl_ctx,
> +					    (unsigned char *)PACKAGE,
> +					    strlen(PACKAGE))) {
> +		VANESSA_LOGGER_DEBUG("SSL_CTX_set_session_id_context");
> +		goto err;
> +	}
> +
>   	/*
>   	 * Set the available ciphers
>   	 */
> ______________________________________________
> Perdition-users mailing list
> [email protected]
> http://lists.vergenet.net/listinfo/perdition-users
>
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users