[Fetchmail-devel] TLS and SSL changes in fetchmail's Git repository

[Matthias A. <mat...@gm...>]

Greetings,

I have hacked a bit on the SSL/TLS configuration options in the Git
repository's master branch (that the 7.0.0-alpha previews get snapshot
from).  This is a bleeding-edge preview for skilled users who have
developer toolchains (recent GNU autoconf/automake/gettext, C99 or C++
compiler, git, openssl) installed and are comfortable with trying out
bleeding edge versions and providing technical feedback and can get the
usual quirks solved.

Note: I will not educate users on how this all works - this is an early
preview, we will have formal -alpha snapshots as tarballs later on in
the process, once things stabilize a bit and I have addressed some of
the FIXME's in code.  Contribution welcome, and to be discussed on the
fetchmail-devel@ mailing list.

I have also made my life easy and now the fetchmail 7.0.0-development
branch requires that OpenSSL 1.0.1 be used so that TLS v1.2 is
available.  Ubuntu 12.04LTS, Fedora 20, FreeBSD 9.3 are fine, Ubuntu
10.04LTS is too old.


Changes are:

SSL/TLS options are changed in incompatible ways (names changed,
semantics changed). They are now more independent of one another. The
configuration of the SSL/TLS protocol version no longer implies wrapped
versus STARTTLS mode, so you can now combine STARTTLS with SSLv3, or,
more importantly, TLSv1 or newer with SSL-wrapped mode.  Omitting the
sslproto should now do the right thing by default.

There is a new --sslmode option to pick the mode.

sslcertck is now on by default.

SSLv2 is now forbidden altogether, with no way for users to enable it in
fetchmail.

SSLv3 is now forbidden by default, meaning fetchmail will not
automatically negotiate SSLv3, unless the user explicitly forces it with
the (revised) --sslprotocolversion SSLv3 option.

I should also like to disable TLSv1 and require 1.1+ be used, but that
would seem to be premature and lock out too many sites.

fetchmail's cipher lists can be configured through an environment
variable (for now, meant to become a formal option later on), so for
instance,

env FETCHMAIL_SSL_CIPHERS='ALL:!EXPORT:!LOW:+RC4:@STRENGTH' \
  fetchmail -vv --other --options

If you want to tighten this up a bit more and can get away without RC4
and all your upstream servers permit TLSv1.2, you may want to try this
instead:

env FETCHMAIL_SSL_CIPHERS='ALL:!EXPORT:!LOW:!MEDIUM:@STRENGTH' \
  fetchmail -vv --sslprotocolversion TLSv1.2 --other --options

For me, half of the sites can no longer be polled with these options
(for instance, Microsoft's freemailers no longer work).


If this all seems worth the hassle, I have two Git repositories on
public sites, you can pick either one to clone from:

https://gitorious.org/fetchmail
(Norway)

http://sourceforge.net/p/fetchmail/git/ci/master/tree/
(USA)

Both contain the same data, so pick the one you're more comfortable with.

Quickstart to try fetchmail from Git (I do not offer support for this,
but I'm happy to receive your feedback, or answer questions that give a
strong hint that you are in fact a programmer):

- install requisites (you must find the packages out by yourself,
  I do NOT support this)
- git clone from one of the two Git repositories
- run: git checkout master  # the default checkout goes onto legacy_63
- run: autoreconf -isvf
- mkdir build && cd build && ../configure -C && make check
- in doubt, make sure you use GNU make for the build
  (called gmake on some systems)
  Some of the auto-maintenance in automake output does not work on
  non-GNU make implementations.

The output will then be in build/fetchmail.