NederHost/Sebastiaan Hoogeveen
2015-Dec-02 15:38 UTC
[patch] Fix for bug in TLS/SSL for LMTP with chained certificates
Hi, In case of tl;dr: I fixed a bug in TLS support for LMTP which caused chained certificates not to work, and another one which caused certificate read errors to be ignored; the patches are attached to this email. While testing LMTP with TLS and certificate verification by Postfix I discovered that certificate chains are not exchanged properly when using LMTP, even though everything works fine for POP3 and IMAP (both with or without STARTTLS). On LMTP only the server certificate is included in the TLS handshake, no intermediate certificates are provided by the server. The first problem I fixed is that in lib-ssl-iostream/iostream-openssl-context.c errors from the ssl_ctx_use_certificate_chain function are silently ignored because the function returns 0 for a failure but the caller checks for values smaller than 0. This problem is fixed in the tiny patch dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff. After applying this patch the following error message appears in the logs for LMTP only (IMAP and POP3 still work fine): dovecot: lmtp(20683): Error: SSL context initialization failed, disabling SSL: Can't load SSL certificate: error:0608308E:digital envelope routines:EVP_PKEY_get1_EC_KEY:expecting a ec key It turns out this issue is not related to the reading of the certificate or its associated chain. Somewhere before ssl_ctx_use_certificate_chain is called an error is put in the OpenSSL error queue which is never retrieved. Only after loading the server certificate is the queue checked and because of the previously existing error the chain is not loaded. I think the error is related to setting specific protocol options in ssl_iostream_context_set (which may be different for LMTP than for IMAP or POP3) but I did not investigate this. I made the problem go away by making the following two changes: 1. The ssl_ctx_use_certificate_chain function now empties the OpenSSL error queue before doing its work by calling ERR_get_error() until the queue is empty. 2. The openssl_iostream_error function in a similar fashion empties the queue and returns only the error message for the most recent error (this prevent earlier errors from 'hiding' later/more relevant ones). After applying this second patch LMTP now works properly with certificate chains. Note that this patch makes previously unhandled errors simply 'disappear' from the queue, which may be a Very Bad Thing. I guess there is a more elegant way of handling this "queued error" issue but this works for me now and I'm actually not a C programmer. These two fixes are included in dovecot-2.2.19-lmtp_ssl_bug.diff. I suspect this is the same issue as the one reported by Piotr Rotter to this list on July the 27th. Kind regards, -- Sebastiaan Hoogeveen NederHost https://www.nederhost.nl/ KvK: 34099781 -------------- next part -------------- A non-text attachment was scrubbed... Name: dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff Type: application/octet-stream Size: 683 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20151202/abca2e03/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: dovecot-2.2.19-lmtp_ssl_bug.diff Type: application/octet-stream Size: 1028 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20151202/abca2e03/attachment-0001.obj>
Timo Sirainen
2015-Dec-03 10:24 UTC
[patch] Fix for bug in TLS/SSL for LMTP with chained certificates
On 02 Dec 2015, at 17:38, NederHost/Sebastiaan Hoogeveen <s.hoogeveen at nederhost.nl> wrote:> > Hi, > > In case of tl;dr: I fixed a bug in TLS support for LMTP which caused chained certificates not to work, and another one which caused certificate read errors to be ignored; the patches are attached to this email. > > While testing LMTP with TLS and certificate verification by Postfix I discovered that certificate chains are not exchanged properly when using LMTP, even though everything works fine for POP3 and IMAP (both with or without STARTTLS). On LMTP only the server certificate is included in the TLS handshake, no intermediate certificates are provided by the server. > > The first problem I fixed is that in lib-ssl-iostream/iostream-openssl-context.c errors from the ssl_ctx_use_certificate_chain function are silently ignored because the function returns 0 for a failure but the caller checks for values smaller than 0. This problem is fixed in the tiny patch dovecot-2.2.19-ssl_ctx_certificate_chain_returnvalue.diff.Applied.> After applying this patch the following error message appears in the logs for LMTP only (IMAP and POP3 still work fine): > > dovecot: lmtp(20683): Error: SSL context initialization failed, disabling SSL: Can't load SSL certificate: error:0608308E:digital envelope routines:EVP_PKEY_get1_EC_KEY:expecting a ec key > > It turns out this issue is not related to the reading of the certificate or its associated chain. Somewhere before ssl_ctx_use_certificate_chain is called an error is put in the OpenSSL error queue which is never retrieved. Only after loading the server certificate is the queue checked and because of the previously existing error the chain is not loaded. I think the error is related to setting specific protocol options in ssl_iostream_context_set (which may be different for LMTP than for IMAP or POP3) but I did not investigate this.http://hg.dovecot.org/dovecot-2.2/rev/302c3c7e11f8 should fix it.> I made the problem go away by making the following two changes: > > 1. The ssl_ctx_use_certificate_chain function now empties the OpenSSL error queue before doing its work by calling ERR_get_error() until the queue is empty. > > 2. The openssl_iostream_error function in a similar fashion empties the queue and returns only the error message for the most recent error (this prevent earlier errors from 'hiding' later/more relevant ones). > > After applying this second patch LMTP now works properly with certificate chains. Note that this patch makes previously unhandled errors simply 'disappear' from the queue, which may be a Very Bad Thing. I guess there is a more elegant way of handling this "queued error" issue but this works for me now and I'm actually not a C programmer. These two fixes are included in dovecot-2.2.19-lmtp_ssl_bug.diff.I changed this to work the same in lib-ssl-iostream as it works in login-common/ssl-proxy-openssl.c (I wonder why it didn't originally work the same way..) and also merged more of the error handling code in login-common and lib-ssl-iostream.