Gordon Messmer writes:
Sam Varshavchik wrote:Gordon Messmer writes:The point that I tried to illustrate, after doing the testing, was that there's no point to that setting. Nothing can be made better by changing it.I disagree. One of the reasons -- not the only one, but one of the factors -- that precipitated this whole discussion is because someone had made a reasonable argument that, for policy reasons, they wanted to disable SSL2. Additionally, it is a reasonable position to have a policy that, for example, allowed only DH-based ciphers. As such, access to the underlying SSL knobs is needed.Sure, I agree, and we've established that this can be done using TLS_CIPHER_LIST. The TLS_PROTOCOL setting, on the other hand, will only create situations where most connections won't work. When set to TLS1 or SSL3, only an identically configured client will connect. For whatever reason, even courierd using SSL23, which should be compatible in theory, won't connect to an smtpd that's using SSL3 as its protocol setting.
The only thing is that TLS_PROTOCOL is a mandatory setting. It's not optional, in the OpenSSL context. If it's unset, Courier just uses the default setting.
This is NOT an optional setting. This setting control which function creates the initial OpenSSL SSL context structure. This setting controls whether SSLv23_method(), TLSv1_method(), or SSLv3_method() creates a new SSL context structure. That's a mandatory step in initializing an SSL session. I do see now where the confusion comes from. I'm fairly sure that at some point in the past, OpenSSL's docs indicates that SSLv23_method() just sets up the SSL context for SSL 2 and SSL 3, period. The current version's documentation now says that it also adds TLS 1. So there.
The wayback machine is currently down :-( so I can't confirm if I remember it right.
That being the case, the setting is useless unless someone wants to establish a tunnel between two courier servers, and those servers aren't going to connect to anything except each other. That's hardly a good enough reason to keep that setting. Even less so since admins can use TLS_CIPHER_LIST to accomplish their goal. TLS_PROTOCOL is just extra cruft that will cause headache for the people who set it, and needlessly adds to the code base.I'm afraid that most of my daylight hours are spent doing things that allow me to spend only a few hours a day answering my mail. Those are the facts of life, that's simply just the way things are. It's not that I do not appreciate you taking the time to do some research here -- it is very much appreciated -- it's just that a concise, capsule summary of your findings would've worked better for me.The summary is: Three days ago, I thought the TLS_PROTOCOL setting was a good idea, and useful toward getting rid of SSL2, and its security deficiencies. After actually looking at the effects of using it, I've reversed that opinion. It's the wrong manner in which to disable SSL2 support. It breaks interoperability with clients that have reasonable SSL configurations.The only thing that remains unclear is what should be the defaults on the client side. There are two distinct cases here: protocol-over-SSL, and STARTTLS-after-protocol, that might require different default settings.Do you mean "courierd->courieresmtp" client, or imap clients? My first guess would be that they'd work with the same settings: SSL23 method, secure cipher list. I haven't gotten around to that set of tests, though.
I mean courieresmtp. As a data point, I have no problems sending mail to Sourceforge. From one of my recent headers:
Received: from www.courier-mta.com ([216.254.115.190]) by mail.sourceforge.net
with esmtps (SSLv3:AES256-SHA:256) (Exim 4.44) id 1JZDuV-0008Af-LZ
for [email protected]; Tue, 11 Mar 2008 16:29:34
-0700
I have TLS_PROTOCOL=SSL3 set in courierd, the setting that takes effect for
courieresmtp connection. … But, I just checked, and I'm currently running a
GnuTLS-based build, so that may be a completely different issue.
pgpJaYKdSgB8u.pgp
Description: PGP signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
