On Mon, Nov 10, 2014 at 11:50:58PM +0100, Matthias Andree wrote: > > I've also changed the way in which opportunistic TLS works a > > little. It seems to have only done this with TLS1 for the above > > stated reasons which were wrong. > > > > This patch results in the following changes with a server support > > STARTTLS: > > | --ssl | no option | sslproto ssl23| sslproto tls1 > > Old: | TLS 1.2 | TLS1.0 | not working | TLS1.0 > > New: | TLS 1.2 | TLS1.2 | TLS1.2 | TLS1.0 > > > > The "sslproto ssl23" case just send logout, I assume because > > maybe_tls returns false. > > > > This started by making the call to SSLv3_client_method() optional > > in case openssl doesn't support it. > > I am not sure I understand the last two phrases. The next-to-last is > probably a matter of reading code and perhaps debugging (also your later > sslproto "" behaving differently than an omitted sslproto option - this > may have to do with automated repolls for opportunistic TLS).
I just looked at the traffic using either wireshark and/or setting -v. It looks like this in the log file: IMAP< * OK IMAP4 ready IMAP> A0001 CAPABILITY IMAP< * CAPABILITY ACL BINARY CATENATE CHILDREN CONDSTORE ENABLE ESEARCH ID IDLE IMAP4rev1 LIST-EXTENDED LITERAL+ MULTIAPPEND NAMESPACE QRESYNC QUOTA RIGHTS=ektx SASL-IR SEARCHRES UIDPLUS UNSELECT WITHIN ESORT I18NLEVEL=1 SORT THREAD=ORDEREDSUBJECT LIST-STATUS XLIST STARTTLS LOGINDISABLED IMAP< A0001 OK completed Authorization failure on XXXX For help, see http://www.fetchmail.info/fetchmail-FAQ.html#R15 IMAP> A0002 LOGOUT IMAP< * BYE Zimbra IMAP server terminating connection IMAP< A0002 OK completed It should just continue with LOGIN instead of LOGOUT. This is the behaviour I see with sslproto set to either ssl23 or "", it's not what I'm expecting. I didn't wait for it to try again. The thing about SSLv3_client_method(): I've dropped SSLv3 support in Debian's openssl by compiling with no-ssl3. However the SSLv3_client_method() still exists so you can still create a SSLv3 connection. I want to remove the existence of that SSLv3_client_method() which is what I started with. And then I noticed all the other things and just wanted to fix that. You should always use SSLv23_client_method() and set the options you want instead, like SSL_OP_NO_SSLv2 or SSL_OP_NO_TLSv1_2. > I am rather loathe to propose/endorse/support changing option semantics > for a stable release; we'd probably need to add new switches. I think I haven't changed the behaviour that much. The changes are: - By default it now does opportunistic TLS with all supported version instead of only supporting TLS 1.0, and I get TLS 1.2 instead of 1.0. This might actually cause problems for people who try to connect to a broken server that is intolerant to TLS 1.2. When using -ssl it was already doing that, it now just also does it when using opportunistic TLS. (That's the "tls1" to ctl->sslproto change in the SSLOpen() calls.) - Change the madatory upgrade using STARTTLS from == "tls1" to != "". (That's the change in tls.c) > Please have a look at the current state of fetchmail's "master" (note: > it is non-default, so you'll need to "git checkout master" after > cloning) branch in Git, either here > <https://gitorious.org/fetchmail/fetchmail/source/master:> or here: > <http://sourceforge.net/p/fetchmail/git/ci/master/tree/> I'll try to take a look at this tomorrow. Kurt -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
