27 Jul
2010
27 Jul
'10
2:44 p.m.
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 <horms(a)verge.net.au>
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 <horms(a)verge.net.au>
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 \"foo(a)bar.com\"
\"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: "foo(a)bar.com {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="foo(a)bar.com"
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