[SM-imapproxy] [PATCH] TLS improvements

[Emmanuel Dreyfus]

Hi

This short patch adds a few improvement to imapproxy SSL client
- TLSv1.2 support if OpenSSL supports it
- ECDHE ciphers support if OpenSSL support it
- configurable cipher suite, with added tls_ciphers option
- server cert validation, with added tls_verify_server

ftp://ftp.espci.fr/shadow/manu/imapproxy2.patch

[Emmanuel Dreyfus]

Post by Emmanuel Dreyfus
This short patch adds a few improvement to imapproxy SSL client
- TLSv1.2 support if OpenSSL supports it

I realize that part is broken for the general case:
TLSv1_2_client_method() only negociate TLSv1.2 and will fail if server
does not support it.

The right way seems to use SSLv23_client_method(), which negociate the
highest available version, which includes TLSv1.2, despite what the
method name suggest. That page makes it clear (even if it does not talk
about 1.2): http://www.openssl.org/docs/ssl/SSL_CTX_new.html

II will post a new patch that uses SSLv23_client_method(). TLS version
can still be controlled by SSL_CTX_set_options() with
SSL_OP_NO_(SSLv2|SSLv3|TLSv1|TLSv1_1|TLSv1_2). Do we want an option to
control the protocol version, or just picking the best is just good
enough?

If we do not provide an option, I think we want to disable SSLv2, which
is well known to be insecure, and SSLv3, which was not supported by
imapproxy before. Feedback is welcome.

[Brad Smith]

Post by Emmanuel Dreyfus

Post by Emmanuel Dreyfus
This short patch adds a few improvement to imapproxy SSL client
- TLSv1.2 support if OpenSSL supports it

TLSv1_2_client_method() only negociate TLSv1.2 and will fail if server
does not support it.
The right way seems to use SSLv23_client_method(), which negociate the
highest available version, which includes TLSv1.2, despite what the
method name suggest. That page makes it clear (even if it does not talk
about 1.2): http://www.openssl.org/docs/ssl/SSL_CTX_new.html
II will post a new patch that uses SSLv23_client_method(). TLS version
can still be controlled by SSL_CTX_set_options() with
SSL_OP_NO_(SSLv2|SSLv3|TLSv1|TLSv1_1|TLSv1_2). Do we want an option to
control the protocol version, or just picking the best is just good
enough?

Personally I'd like to see an option to be able to control which
versions are enabled.

Post by Emmanuel Dreyfus
If we do not provide an option, I think we want to disable SSLv2, which
is well known to be insecure, and SSLv3, which was not supported by
imapproxy before. Feedback is welcome.

If the OpenSSL being built against supports SSLv2 (Debian / Ubuntu /
OpenBSD's OpenSSL does not support SSLv2) then it should be disabled period.

[Emmanuel Dreyfus]

Post by Emmanuel Dreyfus
II will post a new patch that uses SSLv23_client_method().

Here is it:
http://ftp.espci.fr/shadow/manu/imapproxy3.patch

Summary so far:
- Negociate highest TLS protocol available, up to TLSv1.2
- SSLv2 and SSLv3 are disabled
- use ECDHE ciphers support if OpenSSL support it
- configurable cipher suite, with added tls_ciphers option
- server cert validation, with added tls_verify_server

[Emmanuel Dreyfus]

Post by Brad Smith
Personally I'd like to see an option to be able to control which
versions are enabled.

Using SSLv23_client_method() need to explicitely disable protocol
versions we do not want. But the problem is that we can only disable the
versions we know about.

If we add the option you suggest, it will be unable to exclude TLSv1.3
the day it will come.

What problem do you expect to fix with such an option?

[Emmanuel Dreyfus]

Post by Emmanuel Dreyfus
Using SSLv23_client_method() need to explicitely disable protocol
versions we do not want. But the problem is that we can only disable the
versions we know about.
If we add the option you suggest, it will be unable to exclude TLSv1.3
the day it will come.

We can have this:
tls_disable_tls1.0 false
tls_disable_tls1.1 false
tls_disable_tls1.2 false

And the day TLSv1.3 appears, we update and add a new option.

[Emmanuel Dreyfus]

Post by Brad Smith
Personally I'd like to see an option to be able to control which
versions are enabled.

Here it is:
http://ftp.espci.fr/shadow/manu/imapproxy4.patch

[Paul Lesniewski]

Post by Emmanuel Dreyfus

Post by Brad Smith
Personally I'd like to see an option to be able to control which
versions are enabled.

http://ftp.espci.fr/shadow/manu/imapproxy4.patch

[Emmanuel Dreyfus]

Sincere thanks for this. It is in the repository with some small
changes, particularly the addition of the configuration options to
scripts/imapproxy.conf. Let me know if you find anything amiss.

It seems to work fine. I tested with a wrong CA and imapproxy refused to
startup.

What happens if it hits a wrong CA on reconnection (that is, not on
startup)? I guess it quits, leaving the service down until some
admin restarts it. Perhaps it should loop traying to connect instead?

[Paul Lesniewski]

Post by Emmanuel Dreyfus

Sincere thanks for this. It is in the repository with some small
changes, particularly the addition of the configuration options to
scripts/imapproxy.conf. Let me know if you find anything amiss.

It seems to work fine. I tested with a wrong CA and imapproxy refused to
startup.
What happens if it hits a wrong CA on reconnection (that is, not on
startup)? I guess it quits, leaving the service down until some
admin restarts it. Perhaps it should loop traying to connect instead?

Indeed, but probably should have a sane sleep time in the loop....

[Emmanuel Dreyfus]

Hi

No feedback on that one? If the patch perfect? :-)

Post by Emmanuel Dreyfus
http://ftp.espci.fr/shadow/manu/imapproxy4.patch

[Emmanuel Dreyfus]

Hello

I do not recall that patch was checked in. Is there any improvemet to do
on it? Any comment?

Post by Emmanuel Dreyfus
Hi
No feedback on that one? If the patch perfect? :-)

Post by Emmanuel Dreyfus
http://ftp.espci.fr/shadow/manu/imapproxy4.patch