SSL_write problems
Trey A Mujakporue
I recently posted a message to the list with details of a problem i am
experiencing with Qpopper ver 4.04 with SSL/TLS enabled using Openssl
version 0.9.6e It seems like this probelm has been ongoing for the past 2
years but there has been no fix. From my investigations it appears that the
the problem may exist in the qpopper implementation of the SSL libraries,
hence my posting to both lists, Im kinda desperate now so any help would be
apreciated!
details as follows.
When downloading files with SSL enabled, we get this error in the logs
This is not a chunky write problem as my qpopper configuration file is made
up of the following
set tls-support = alternate-port
set tls-server-cert-file = /etc/mail/certs/cert.pem
set chunky-writes = always
Various people on the qpopper mailing list seem to have experienced this
problem
http://www.pensive.org/Mailing_Lists/Archives/Qpopper/Archive-2001-12-20.htm
l#[20]
and
http://www.pensive.org/mailing_lists/Archives/qpopper/Archive-2002-05-30.htm
l#[45]
But there doesnt seem to be any fix available or explanation as to causes
it. Neither is this problem acknowledged in the current Qpopper Faq
Aug 15 14:22:52 dogbert qpopper[6684]: I/O Error
Aug 15 14:22:52 dogbert qpopper[6684]: Error writing to client
Aug 15 14:22:52 dogbert qpopper[6684]: user at m119-mp1.cvx1-a.dialup.com
(192.168.1.0): -ERR SIGHUP or SIGPIPE flagged
Aug 15 14:22:52 dogbert qpopper[6684]: OpenSSL Error during write
Aug 15 14:22:52 dogbert qpopper[6684]: ...SSL error: error:1409F07F:SSL
routines:SSL3_WRITE_PENDING:bad write retry
After looking through the archives, i found this
When SSL_write is called again after another function, SSL_ERROR_WANT_...,
it must get exactly the same buffer because parts of the buffer contents may
already have been encrypted and wait in interal buffers while others may not
yet have been looked at. What's really important is that buffer *contents*
stay the same, but as a sanity check to avoid application bugs the OpenSSL
library checks whether the buffer *address* is not changed. This check can
be disabled by setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER for that SSL
object, using SSL_set_mode (or SSL_CTX_set_mode
on the SSL_CTX before SSL_new is called).
Not being a programmer of any kind i am unable to implement this fix help
from you guys would be greatly appreciated
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Steven Michaud
your problems:
***** patch file begins on next line *****
diff -c -r popper.old/pop_tls_openssl.c
popper/pop_tls_openssl.c *** popper.old/pop_tls_openssl.c Tue Sep 10
14:48:20 2002 --- popper/pop_tls_openssl.c Tue Sep 10 14:51:25 2002
*************** *** 339,344 **** --- 339,347 ----
log_openssl_err ( pPOP, HERE, "Unable to allocate SSL_CTX" );
goto Done;
}
+ /* Enable all of OpenSSL's bug fixes -- this lets the Eudora/Qpopper */
+ /* combination work with recent versions of OpenSSL. */
+ SSL_CTX_set_options (pTLS->m_OpenSSLctx, SSL_OP_ALL);
/*
* Establish the certificate for our server cert.
***** patch file ends on previous line *****
When your SSL/TLS-enabled server allocates a new SSL context (for
example in preparation for using it with a new connection), OpenSSL
has long made it possible to incorporate a bunch of workarounds for
bugs commonly found in clients you'll be talking to. You can enable
each workaround individually, or you can enable all of them at once by
calling SSL_CTX_set_options() with its "options" parameter set to
"SSL_OP_ALL".
In principle this might make your server more vulnerable to attacks,
but it is common practice -- recent versions of the UW IMAP and Cyrus
servers both do so. For some reason Qpopper doesn't.
This doesn't cause trouble until you link Qpopper with OpenSSL version
0.9.6d or later.
That version of OpenSSL included a new countermeasure against a
vulnerability in "CBC ciphersuites". Here's a quote from the OpenSSL
0.9.6d change log:
*) Implement a countermeasure against a vulnerability recently found
in CBC ciphersuites in SSL 3.0/TLS 1.0: Send an empty fragment
before application data chunks to avoid the use of known IVs
with data potentially chosen by the attacker.
[Bodo Moeller]
But Eudora (even the most recent versions) apparently has this
vulnerability. And linking against OpenSSL 0.9.6d caused servers
(notably UW IMAP and Cyrus) to stop working with Eudora as a client.
The OpenSSL authors noticed this, and included a new workaround in
0.9.6e, called SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. This option was
(and is still) included in SSL_OP_ALL.
Linking against OpenSSL 0.9.6e (and later) "fixed" UW IMAP and Cyrus
-- which both set the SSL "options" to SSL_OP_ALL. But it didn't help
Qpopper (without my patch, that is).
I'm not an expert in encryption or in OpenSSL, so I can't really
evaluate the risk involved in applying my patch (that is in making
Qpopper use SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS and all of OpenSSL's
other workarounds). But I'm willing to trust the judgement of the
authors of OpenSSL, UW IMAP and Cyrus, all of whom seem to think the
risk is outweighed by the convenience of working with semi-broken
clients like Eudora.