26 Jul
2010
26 Jul
'10
9:36 p.m.
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?
Thanks.
[1]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/thread.html
[2] https://wiki.mozilla.org/Security:Renegotiation
[3]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/002336.html
[4]
http://lists.vergenet.net/pipermail/perdition-users/2010-July/002341.html
27 Jul
27 Jul
1:49 a.m.
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:
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
*/
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? 
8:56 a.m.
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:
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
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?
9:40 a.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
Hi Joachim,
On Tue, Jul 27, 2010 at 10:56:36AM +0200, Joachim Sehlstedt wrote:
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.
Are you sure that you can connect a second time from
the same thunderbird session? I don't have a ca_file handy
to test with, but with the rest of the optoins set I see the problem.
I would like to hijack this thread a bit and add/ask
the following:
It would make my inbox management a lot saner if you started a new thread.
I've changed the subject accordingly.
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?
No.
Due to a lack of understanding on my part when I added SSL support to
perdition, SSL and TLS do not have their normal meanings
in relation to the parameters to ssl_mode :-(
In a nutshell
* ssl_* means use SSL/TLS (i.e. port 993, 995, ...)
That is, the starts an SSL/TLS negotiation on connect
* tls_* means use STARTTLS, STLS...
That is, the user can upgrade a session from plantext tos
encrypted (using SSL/TLS) after connecting.
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
Is that this line?
ssl_method = SSLv23_method();
I'm not seeing the warniing here.
Which version of gcc and libssl do you have?
Alternatively, do you know what the problem is?
Lastly, taking a stab in the dark, does this help?
Index: perdition/perdition/ssl.c
===================================================================
--- perdition.orig/perdition/ssl.c 2010-07-27 18:35:15.000000000 +0900
+++ perdition/perdition/ssl.c 2010-07-27 18:35:44.000000000 +0900
@@ -492,7 +492,6 @@ SSL_CTX *perdition_ssl_ctx(const char *c
const char *cert, const char *privkey,
const char *ca_chain_file, const char *ciphers, flag_t flag)
{
- SSL_METHOD *ssl_method;
SSL_CTX *ssl_ctx, *out = NULL;
const char *use_ca_file = NULL;
const char *use_ca_path = NULL;
@@ -519,10 +518,9 @@ SSL_CTX *perdition_ssl_ctx(const char *c
* Initialise an SSL context
*/
SSLeay_add_ssl_algorithms();
- ssl_method = SSLv23_method();
SSL_load_error_strings();
- ssl_ctx = SSL_CTX_new(ssl_method);
+ ssl_ctx = SSL_CTX_new(SSLv23_method());
if (!ssl_ctx) {
PERDITION_DEBUG_SSL_ERR("SSL_CTX_new");
return NULL;
1:48 p.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
Hi,
Are you sure that you can connect a second time from
the same thunderbird session? I don't have a ca_file handy
to test with, but with the rest of the optoins set I see the problem.
Well there
still is something wrong it seems. Here is what I get in the
log when I start TB and it tries to connect:
Jul 27 15:19:49 mail perdition[31439]: Fatal Error reading
authentication information from client X:59820->Y:994: Exiting child
However directly followed by that error I get valid logins in Cyrus imap:
Jul 27 15:19:49 mail imap[29007]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:19:55 mail imap[29127]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:19:56 mail imap[29011]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Jul 27 15:20:25 mail imap[31196]: login: localhost [127.0.0.1] u0001
plaintext User logged in
Process list
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
nobody 31434 0.0 0.0 6008 1288 ? S 15:19 0:00
perdition: daemon
nobody 31438 0.0 0.0 6144 2228 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31441 0.0 0.0 6144 2048 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31443 0.0 0.0 6144 2048 ? S 15:19 0:00 \_
perdition: connect (u0001)
nobody 31445 0.0 0.0 6144 2048 ? S 15:20 0:00 \_
perdition: connect (u0001)
And when I close TB I get logs for each of the processes saying Closing
session: X:59809->Y:994 authorisation_id=NONE authentication_id="u0001"
received=XX sent=XX
But on the client side I don't notice anything wrong and I can switch
between folders and read mail without any problems, in version 1.18 I
would get the SSL error by just switching to a new imap folder. I'll
switch to run perdition in debug mode to see if I can give you anything
better to work with.
I however wonder if Mozilla changed something to get around the error
seeing as TB using 4 sessions all of a sudden, or is that a change in
Perdition?
No.
Due to a lack of understanding on my part when I added SSL support to
perdition, SSL and TLS do not have their normal meanings
in relation to the parameters to ssl_mode :-(
In a nutshell
* ssl_* means use SSL/TLS (i.e. port 993, 995, ...)
That is, the starts an SSL/TLS negotiation on connect
* tls_* means use STARTTLS, STLS...
That is, the user can upgrade a session from plantext tos
encrypted (using SSL/TLS) after connecting.
Thank you for the clarification :)
Is that this line?
ssl_method = SSLv23_method();
Yes it is, should have included that for you.
I'm not seeing the warniing here.
Which version of gcc and libssl do you have?
Alternatively, do you know what the problem is?
Running gcc 4.3.3 here and OpenSSL
1.0.0a.
Lastly, taking a stab in the dark, does this help?
Index: perdition/perdition/ssl.c
===================================================================
--- perdition.orig/perdition/ssl.c 2010-07-27 18:35:15.000000000 +0900
+++ perdition/perdition/ssl.c 2010-07-27 18:35:44.000000000 +0900
@@ -492,7 +492,6 @@ SSL_CTX *perdition_ssl_ctx(const char *c
const char *cert, const char *privkey,
const char *ca_chain_file, const char *ciphers, flag_t flag)
{
- SSL_METHOD *ssl_method;
SSL_CTX *ssl_ctx, *out = NULL;
const char *use_ca_file = NULL;
const char *use_ca_path = NULL;
@@ -519,10 +518,9 @@ SSL_CTX *perdition_ssl_ctx(const char *c
* Initialise an SSL context
*/
SSLeay_add_ssl_algorithms();
- ssl_method = SSLv23_method();
SSL_load_error_strings();
- ssl_ctx = SSL_CTX_new(ssl_method);
+ ssl_ctx = SSL_CTX_new(SSLv23_method());
if (!ssl_ctx) {
PERDITION_DEBUG_SSL_ERR("SSL_CTX_new");
return NULL;
Not only does it take away the build warning, it also removes the error
I get on the first connect I listed above.
greetings
JS
30 Jul
30 Jul
3:01 a.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
On Tue, Jul 27, 2010 at 03:48:29PM +0200, Joachim Sehlstedt wrote:
[snip]
Curious. Thanks for the feedback.
The new code seems obviously correct (although the old code isn't obviously
wrong to me) so I will push this into the tree. Sorry that I didn't do it
for rc3.
Is that this
line?
ssl_method = SSLv23_method();
Yes it is, should have included that for you.
I'm not seeing the warniing here.
Which version of gcc and libssl do you have?
Alternatively, do you know what the problem is?
Running gcc 4.3.3 here and OpenSSL
1.0.0a.
Lastly, taking a stab in the dark, does this
help?
Index: perdition/perdition/ssl.c
===================================================================
--- perdition.orig/perdition/ssl.c 2010-07-27 18:35:15.000000000 +0900
+++ perdition/perdition/ssl.c 2010-07-27 18:35:44.000000000 +0900
@@ -492,7 +492,6 @@ SSL_CTX *perdition_ssl_ctx(const char *c
const char *cert, const char *privkey,
const char *ca_chain_file, const char *ciphers, flag_t flag)
{
- SSL_METHOD *ssl_method;
SSL_CTX *ssl_ctx, *out = NULL;
const char *use_ca_file = NULL;
const char *use_ca_path = NULL;
@@ -519,10 +518,9 @@ SSL_CTX *perdition_ssl_ctx(const char *c
* Initialise an SSL context
*/
SSLeay_add_ssl_algorithms();
- ssl_method = SSLv23_method();
SSL_load_error_strings();
- ssl_ctx = SSL_CTX_new(ssl_method);
+ ssl_ctx = SSL_CTX_new(SSLv23_method());
if (!ssl_ctx) {
PERDITION_DEBUG_SSL_ERR("SSL_CTX_new");
return NULL;
Not only does it take away the build warning, it also removes the error
I get on the first connect I listed above.
3:12 a.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
On Fri, Jul 30, 2010 at 12:01:46PM +0900, Simon Horman wrote:
On Tue, Jul 27, 2010 at 03:48:29PM +0200, Joachim
Sehlstedt wrote:
[snip]
Curious. Thanks for the feedback.
The new code seems obviously correct (although the old code isn't obviously
wrong to me) so I will push this into the tree. Sorry that I didn't do it
for rc3.
I have merged the change, and it is changeset 1718ccb586e9 in my tree.
Can you let me know if you have any outstanding issues as of that revision?
http://hg.vergenet.net/perdition/perdition/rev/1718ccb586e9
4:05 a.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
Hi,
Was looking at some other applications to see how they handle it and it
seems most does it the way your patch do it. This is from Postfix and
Cyrus IMAP for an example:
client_ctx = SSL_CTX_new(SSLv23_client_method())
and
s_ctx = SSL_CTX_new(SSLv23_server_method());
greetings
JS
On 2010-07-30 05:01, Simon Horman wrote:
On Tue, Jul 27, 2010 at 03:48:29PM +0200, Joachim
Sehlstedt wrote:
[snip]
Curious. Thanks for the feedback.
The new code seems obviously correct (although the old code isn't obviously
wrong to me) so I will push this into the tree. Sorry that I didn't do it
for rc3.
Is that
this line?
ssl_method = SSLv23_method();
Yes it is, should have included that for you.
I'm not seeing the warniing here.
Which version of gcc and libssl do you have?
Alternatively, do you know what the problem is?
Running gcc 4.3.3 here and OpenSSL
1.0.0a.
Lastly, taking a stab in the dark, does this
help?
Index: perdition/perdition/ssl.c
===================================================================
--- perdition.orig/perdition/ssl.c 2010-07-27 18:35:15.000000000 +0900
+++ perdition/perdition/ssl.c 2010-07-27 18:35:44.000000000 +0900
@@ -492,7 +492,6 @@ SSL_CTX *perdition_ssl_ctx(const char *c
const char *cert, const char *privkey,
const char *ca_chain_file, const char *ciphers, flag_t flag)
{
- SSL_METHOD *ssl_method;
SSL_CTX *ssl_ctx, *out = NULL;
const char *use_ca_file = NULL;
const char *use_ca_path = NULL;
@@ -519,10 +518,9 @@ SSL_CTX *perdition_ssl_ctx(const char *c
* Initialise an SSL context
*/
SSLeay_add_ssl_algorithms();
- ssl_method = SSLv23_method();
SSL_load_error_strings();
- ssl_ctx = SSL_CTX_new(ssl_method);
+ ssl_ctx = SSL_CTX_new(SSLv23_method());
if (!ssl_ctx) {
PERDITION_DEBUG_SSL_ERR("SSL_CTX_new");
return NULL;
Not only does it take away the build warning, it also removes
the error
I get on the first connect I listed above.
6:13 a.m.
New subject: tls_listen vs ssl_listen (Was: Thunderbird 3.1 SSL/TLS Renegotiation)
On Fri, Jul 30, 2010 at 06:05:27AM +0200, Joachim Sehlstedt wrote:
Hi,
Was looking at some other applications to see how they handle it and it
seems most does it the way your patch do it. This is from Postfix and
Cyrus IMAP for an example:
client_ctx = SSL_CTX_new(SSLv23_client_method())
and
s_ctx = SSL_CTX_new(SSLv23_server_method());
Thanks, I appreciate that.
27 Jul
27 Jul
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
28 Jul
28 Jul
1:28 a.m.
On Tue, Jul 27, 2010 at 04:44:45PM +0200, John Feuerstein wrote:
Hello Simon,
thanks for the quick response. The given patch works fine for me!
Could you create another -rc or bugfix release including this?
Yes.
I'm waiting for a few other fixes to be confirmed.
And assuming nothing else arises in the meantime I will
try and get rc3 out very soon now.
[ I will answer the other portion of this email/thread separately ]
12:15 p.m.
On Tue, Jul 27, 2010 at 04:44:45PM +0200, John Feuerstein wrote:
[snip]
Hi John,
I agree with your analysis.
What seems to be happening is that Thunderbird is closing
a connection without issuing a LOGOUT, command and perdition is complaining
about that.
I think that is is worth fixing perdition so that it doesn't complain here.
But the fix is non-trival, so I think it is post 1.19 material.
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...) 
2 Aug
2 Aug
5:17 p.m.
In regard to: Re: [PERDITION-USERS] Thunderbird 3.1 SSL/TLS Renegotiation,...:
I've been thinking about this, and as much as I appreciate software that
is accepting of other software's faults, I think it would be better if
Thunderbird were fixed to actually follow the IMAP protocol. I mean, how
hard is it for it to do things correctly and just issue an
a### LOGOUT
before it drops the connection?
Tim
--
Tim Mooney mooney(a)dogbert.cc.ndsu.NoDak.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
... 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...)
Hi John,
I agree with your analysis.
What seems to be happening is that Thunderbird is closing
a connection without issuing a LOGOUT, command and perdition is complaining
about that.
I think that is is worth fixing perdition so that it doesn't complain here.
But the fix is non-trival, so I think it is post 1.19 material.
3 Aug
3 Aug
12:52 a.m.
On Mon, Aug 02, 2010 at 12:17:24PM -0500, Tim Mooney wrote:
In regard to: Re: [PERDITION-USERS] Thunderbird 3.1
SSL/TLS Renegotiation,...:
I've been thinking about this, and as much as I appreciate software that
is accepting of other software's faults, I think it would be better if
Thunderbird were fixed to actually follow the IMAP protocol. I mean, how
hard is it for it to do things correctly and just issue an
a### LOGOUT
before it drops the connection?
I agree. But its probably also fair to say that perdition is
being a little bit overly verbose about the situation.
... 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...)
Hi John,
I agree with your analysis.
What seems to be happening is that Thunderbird is closing
a connection without issuing a LOGOUT, command and perdition is complaining
about that.
I think that is is worth fixing perdition so that it doesn't complain here.
But the fix is non-trival, so I think it is post 1.19 material.
1:17 a.m.
Hi,
Yes this should be handled in Perdition. Just take the example of a port
scan. Or someone wanting to flood your logs, maybe it will even fill
your disk space if you are low. True that Thunderbird should behave more
nice but you can't go around hoping that all software out there will do
things according to specs.
greetings
JS
On 2010-08-03 02:52, Simon Horman wrote:
On Mon, Aug 02, 2010 at 12:17:24PM -0500, Tim Mooney
wrote:
In regard to: Re: [PERDITION-USERS] Thunderbird
3.1 SSL/TLS Renegotiation,...:
I've been thinking about this, and as much as I appreciate software that
is accepting of other software's faults, I think it would be better if
Thunderbird were fixed to actually follow the IMAP protocol. I mean, how
hard is it for it to do things correctly and just issue an
a### LOGOUT
before it drops the connection?
I agree. But its probably also fair to say that perdition is
being a little bit overly verbose about the situation.
______________________________________________
Perdition-users mailing list
Perdition-users(a)vergenet.net
http://lists.vergenet.net/listinfo/perdition-users
... 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...)
Hi John,
I agree with your analysis.
What seems to be happening is that Thunderbird is closing
a connection without issuing a LOGOUT, command and perdition is complaining
about that.
I think that is is worth fixing perdition so that it doesn't complain here.
But the fix is non-trival, so I think it is post 1.19 material.
5022
days inactive
5030
days old
14 comments
4 participants
participants (4)
-
Joachim Sehlstedt -
John Feuerstein -
Simon Horman -
Tim Mooney