Re: Thunderbird 3.1 SSL/TLS Renegotiation

Hello Simon,

thanks for the quick response. The given patch works fine for me!
Could you create another -rc or bugfix release including this?

> 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
>  	 */


Regarding the other problem described by Joachim:
(please don't hijack threads... hard to follow for others reading the
archives!)

> Fatal Error reading authentication information from client
> 192.168.10.100:34680->192.168.10.100:143: Exiting child

... I also get this on each login using Thunderbird 3.1.1.
However, this doesn't seem "fatal" to the real IMAP session.
It seems like TB opens an additional connection to the server to check
capatibilities, then closes it without sending any authentication. The
authentication is then done on the initial connection (probably after
STARTTLS...) instead.

The debug log confirms this (PID 6245 is this mysterious connection that
just sends nothing (EOF?) after capability, while PID 6243 is the
initial connection that continues just fine...):

> perdition.imap4[6243]: Connect:  192.168.10.100:34679->192.168.10.100:143·
> perdition.imap4[6243]: SELF:   "* OK [CAPABILITY IMAP4 IMAP4REV1 STARTTLS] perdition ready on 0N\030\303\377\177 000297fe\r\n"·
> perdition.imap4[6245]: Connect:  192.168.10.100:34680->192.168.10.100:143·
> perdition.imap4[6245]: SELF:   "* OK [CAPABILITY IMAP4 IMAP4REV1 STARTTLS] perdition ready on 0N\030\303\377\177 000297fe\r\n"·
> perdition.imap4[6245]: CLIENT: "1 STARTTLS\r\n"·
> perdition.imap4[6245]: SELF:   "1 OK Begin TLS negotiation now\r\n"·
> perdition.imap4[6243]: CLIENT: "1 STARTTLS\r\n"·
> perdition.imap4[6243]: SELF:   "1 OK Begin TLS negotiation now\r\n"·
> perdition.imap4[6243]: SSL connection using CAMELLIA256-SHA·
> perdition.imap4[6245]: SSL connection using CAMELLIA256-SHA·
> perdition.imap4[6243]: CLIENT: "2 capability\r\n"·
> perdition.imap4[6243]: SELF:   "* CAPABILITY IMAP4 IMAP4REV1\r\n"·
> perdition.imap4[6243]: SELF:   "2 OK CAPABILITY\r\n"·
> perdition.imap4[6245]: CLIENT: "2 capability\r\n"·
> perdition.imap4[6245]: SELF:   "* CAPABILITY IMAP4 IMAP4REV1\r\n"·
> perdition.imap4[6245]: SELF:   "2 OK CAPABILITY\r\n"·
> perdition.imap4[6243]: CLIENT: "4 login \"[email protected]\" \"foobar\"\r\n"·
> perdition.imap4[6243]: username_add_domain: username_add_domain 0 1·
> perdition.imap4[6243]: username_add_domain: username_add_domain 0 4·
> perdition.imap4[6245]: CLIENT: ""·
> perdition.imap4[6245]: token_read: token_fill_buffer·
> perdition.imap4[6245]: read_line: token_read·
> perdition.imap4[6245]: imap4_in_get_auth: read_imap4_line 1·
> perdition.imap4[6245]: main: protocol->in_get_auth·
> perdition.imap4[6245]: Fatal Error reading authentication information from client 192.168.10.100:34680->192.168.10.100:143: Exiting child·
> perdition.imap4[6243]: REAL:   "* OK IMAP4 Ready 10.10.4.4 0001ce47\r\n"·
> perdition.imap4[6243]: SELF:   "flim07 CAPABILITY\r\n"·
> perdition.imap4[6243]: REAL:   "* CAPABILITY IMAP4 IMAP4REV1 STARTTLS\r\n"·
> perdition.imap4[6243]: REAL:   "flim07 OK CAPABILITY\r\n"·
> perdition.imap4[6243]: SELF:   "flim08 LOGIN {15}\r\n"·
> perdition.imap4[6243]: REAL:   "+ OK ready for additional input\r\n"·
> perdition.imap4[6243]: SELF:   "[email protected] {10}\r\n"·
> perdition.imap4[6243]: REAL:   "+ OK ready for additional input\r\n"·
> perdition.imap4[6243]: SELF:   "foobar\r\n"·
> perdition.imap4[6243]: REAL:   "flim08 OK SUCCESS - REAL MAIL SERVICE\r\n"·
> perdition.imap4[6243]: SELF:   "4 OK SUCCESS - PROXY\r\n"·
> perdition.imap4[6243]: Auth: 192.168.10.100:34679->192.168.10.100:143 client-secure=starttls authorisation_id=NONE authentication_id="[email protected]" server="127.0.0.1:10143" protocol=IMAP4 server-secure=plaintext status="ok"·
> ...

... so perhaps you can catch this in imap4_in_get_auth() or just leave
it this way. (After all, it's just TB trying to be smart...)

Best regards,
John
______________________________________________
Perdition-users mailing list
[email protected]
http://lists.vergenet.net/listinfo/perdition-users