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 "foo(a)bar.com" 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<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
*/
______________________________________________
Perdition-users mailing list
Perdition-users(a)vergenet.net
http://lists.vergenet.net/listinfo/perdition-users