[pkg-fetchmail-maint] Bug#768843: fetchmail: Improved TLS support

[Kurt Roeckx]

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