diff options
| -rw-r--r-- | NEWS | 18 | ||||
| -rw-r--r-- | README.SSL | 36 | ||||
| -rw-r--r-- | fetchmail-SA-2021-02.txt | 89 | ||||
| -rw-r--r-- | fetchmail.man | 38 |
4 files changed, 94 insertions, 87 deletions
@@ -93,21 +93,19 @@ fetchmail-6.4.22 (not yet released): fetchmail is to enforce TLS, and when the server or an attacker sends a PREAUTH greeting, fetchmail used to continue an unencrypted connection. Now, log the error and abort the connection. - - Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on - a dedicated port (default 993): use --ssl. - - Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why + Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on + a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile. + Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel. The paper did not mention fetchmail. * On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS negotiation. -* On IMAP connections, do not permit to override a server-side LOGINDISABLED - with --auth password any more. +* On IMAP connections, fetchmail does not permit overriding a server-side + LOGINDISABLED with --auth password any more. * On POP3 connections, the possibility for RPA authentication (by probing with an AUTH command without arguments) no longer prevents STARTTLS negotiation. -* For POP3 connections, RPA is only attempted if the authentication type is any. +* For POP3 connections, only attempt RPA if the authentication type is "any". # BUG FIXES: * On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the @@ -138,6 +136,10 @@ fetchmail-6.4.22 (not yet released): * For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option do not match, emit a warning and continue. Closes Gitlab #31. (cherry-picked from 6.5 beta branch "legacy_6x") +* fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997 + recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer, + placing --sslproto tls1.2+ more prominently. + The defaults shall not change between 6.4.X releases for compatibility. -------------------------------------------------------------------------------- fetchmail-6.4.21 (released 2021-08-09, 30042 LoC): @@ -18,9 +18,6 @@ POP3/IMAP4) or is totally SSL-wrapped on a separate port. Also, fetchmail 6.4.0 and newer releases changed some of the semantics as the result of a bug-fix, and will auto-negotiate TLSv1 or newer only. -If your server does not support this, you may have to specify --sslproto -ssl3+. This is in order to prefer the newer TLS protocols, because SSLv2 -and v3 are broken. Finally, due to other defaults changing, and several mail services not supporting in-band negotiation of SSL or TLS by means of STLS or STARTTLS, @@ -40,28 +37,37 @@ In all four examples below, the (--)sslcertck has become redundant since fetchmail v6.4.0 but since fetchmail 6.3 releases will be in circulation for a while, we'll leave it here to be safe. -For use of SSL or TLS with in-band negotiation on the regular service's port, -i. e. with STLS or STARTTLS, use these command line options +For use of SSL or TLS on a separate port (recommended), called Implicit TLS, +the whole TCP connection is SSL-encrypted from the very beginning (SSL- or +TLS-wrapped), use these command line options (in the rcfile, +omit all leading "--"): - --sslproto auto --sslcertck + --ssl --sslproto tls1.2+ --sslcertck or these options in the rcfile (after the respective "user"... options) - sslproto auto sslcertck - + ssl sslproto tls1.2+ sslcertck -Note that some services do not offer STLS or STARTTLS, but most do -offer SSL or TLS on a separate, dedicated, "secure" port: -For use of SSL or TLS on a separate port, if the whole TCP connection is -SSL-encrypted from the very beginning (SSL- or TLS-wrapped), use these -command line options (in the rcfile, omit all leading "--"): +For use of SSL or TLS with in-band negotiation on the regular service's port, +i. e. with STLS or STARTTLS, use these command line options (omitting --ssl or +ssl): - --ssl --sslproto auto --sslcertck + --sslproto tls1.2+ --sslcertck or these options in the rcfile (after the respective "user"... options) - ssl sslproto auto sslcertck + sslproto tls1.2+ sslcertck + + +With up to date OpenSSL libraries (1.1.1 or newer), and with recent +software on the server, you can alternatively configure tls1.3+. + +For some older services, you may need to use tls1.1+ or tls1+ for compatibility +instead of the tls1.2+ above. In such situations, you should ask the service +provider or server operator to upgrade their TLS implementation such that +TLS v1.3 be supported, and once that happens, update your fetchmail configuration +to tls1.3+ or tls1.2+. Background and use (long version :-)) diff --git a/fetchmail-SA-2021-02.txt b/fetchmail-SA-2021-02.txt index ffa2a3d4..b5a9905b 100644 --- a/fetchmail-SA-2021-02.txt +++ b/fetchmail-SA-2021-02.txt @@ -1,21 +1,20 @@ -fetchmail-SA-2021-02: failure to enforce STARTTLS session encryption +fetchmail-SA-2021-02: STARTTLS session encryption bypassing Topics: fetchmail fails to enforce an encrypted connection Author: Matthias Andree -Version: 0.3 -Announced: TBC +Version: 0.9 +Announced: 2021-08-26 Type: failure to enforce configured security policy Impact: fetchmail continues an unencrypted connection, thus reading unauthenticated input and sending - information unencrypted over its transport, - including passwords + information unencrypted over its transport Danger: medium Acknowledgment: Andrew C. Aitchison for reporting this against fetchmail Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian Schinzel for their Usenix Security 21 paper NO STARTTLS -CVE Name: TBC (if any) +CVE Name: CVE-2021-39272 URL: https://www.fetchmail.info/fetchmail-SA-2021-02.txt Project URL: https://www.fetchmail.info/ @@ -23,18 +22,18 @@ Affects: - fetchmail releases up to and including 6.4.21 Not affected: - fetchmail releases 6.4.22 and newer -Corrected in: TBC Git commit hash (both needed) - TBC fetchmail 6.4.21 release tarball +Corrected in: 2021-08-26 fetchmail 6.4.22.rc1 release candidate + TBD fetchmail 6.4.22 release tarball -0. Release history -================== +0. History of this announcement +=============================== -2021-08-10 initial report to maintainer -2021-08-10 0.1 first draft -2021-08-13 0.2 mention --auth ssh defeated STARTTLS -2021-08-14 0.3 mention POP3 RPA defeated STARTTLS, and - make explicit that --auth ssh applied to - IMAP and POP3 alike. +2021-08-10 Andrew C. Aitchison contacts fetchmail maintainer with pointer + to Usenix Security 21 paper by Damian Poddebniak et al. +2021-08-16 a simplified recommendation to configure --ssl where possible + (see section 3b. below) to mitigate impact was sent to the + fetchmail mailing lists +2021-08-26 0.9 initial release along with fetchmail 6.4.22.rc1 1. Background @@ -55,10 +54,13 @@ regular protocol ports. fetchmail permits requiring that an IMAP or POP3 protocol exchange uses a TLS-encrypted transport, in 6.4 by way of an --sslproto auto or similar configuration. + This TLS encryption can be established either as Implicit TLS connection, +which negotiates TLS first, or as a STARTTLS which starts as cleartext +protocol exchange that gets upgraded in the same TCP stream to TLS. -This TLS encryption can be established either as implicit or fully-wrapped -connections on dedicated TCP ports for the "secure" variants, or by initiating -a clear-text protocol exchange and then requesting a TLS negotiation in-band. +Without special configuration, fetchmail would opportunistically try to +upgrade cleartext connections to TLS by STARTTLS, but allow cleartext protocol +exchange, which is documented. IMAP also supports sessions that start in "authenticated state" (PREAUTH). In this latter case, IMAP (RFC-3501) does not permit sending STARTTLS @@ -66,29 +68,32 @@ negotiations, which are only permissible in not-authenticated state. In such a combination of circumstances (1. IMAP protocol in use, 2. the server greets with PREAUTH, announcing authenticated state, 3. the user configured TLS mandatory, 4. the user did not configure "ssl" mode that uses -separate ports for implicit SSL/TLS), fetchmail 6.4.21 and older continues -with the unencrypted connection, rather than reporting and aborting. +separate ports for Implicit SSL/TLS), fetchmail 6.4.21 and older would +not encrypt the session. -A similar situation is encountered for POP3: if the remote name contains -@compuserve.com, the server supports a non-standard "AUTH" command without -mechanism argument and responds with a list that contains "RPA" (also in -mixed or lower case), then fetchmail will not attempt STARTTLS. While the -password itself is then protected by the RPA scheme (which employs MD5 however), -the session as a whole is not protected by TLS. +There was a similar situation for POP3: if the remote name contained +@compuserve.com, and if the server supported a non-standard "AUTH" command +without mechanism argument and if it responded with a list that contained "RPA" +(also in mixed or lower case), then fetchmail would not attempt STARTTLS. +While the password itself is then protected by the RPA scheme (which employs +MD5 however), fetchmail 6.4.21 and older would not encrypt the session. Also, a configuration containing --auth ssh (meaning that fetchmail should not authenticate, on the assumption that the session will be pre-authenticated for instance through SSH running a mail server with --plugin, or TLS client -certificates), will also defeat STARTTLS as result of an implementation defect. +certificates), would also defeat STARTTLS as result of an implementation defect. This affected both POP3 and IMAP. -This can cause e-mail and in the first case, also potentially passwords, to be -exposed to eavesdropping. - 3. Solutions ============ +PREFACE: distributors backporting fixes to old versions are asked to diff the +manual page and review the changes, and the NEWS file, because the manual page +has been updated with newer recommendations. The same backport recommendations +hold for the README.SSL file. + + 3a. Install fetchmail 6.4.22 or newer. The fetchmail source code is available from @@ -99,24 +104,12 @@ https://gitlab.com/fetchmail/fetchmail/-/tree/legacy_64 (primary) https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/ (copy) -3b. Alternatively, where the IMAP or POP3 server supports this form of access, -fetchmail can be configured to "ssl" mode, meaning it will connect to -a dedicated port (default: 993 for IMAP, 995 for POP3) and negotiate TLS -without prior clear-text protocol exchange. +3b. Where the IMAP or POP3 server supports this form of access, +fetchmail can be configured to use Implicit TLS, called "ssl" mode, meaning it +will connect to a dedicated port (default: 993 for IMAP, 995 for POP3) and +negotiate TLS without prior clear-text protocol exchange. Also, --ssl can be given on the command line, which switches all -configured server statements to this ssl mode. - - -Distributors are encouraged to review the NEWS file and move forward to -6.4.22, rather than backport individual security fixes, because doing so -routinely misses other fixes crucial to fetchmail's proper operation, -for which no security announcements are issued, or documentation, -or translation updates. - -Fetchmail 6.4.X releases have been made with a focus on unchanged user and -program interfaces so as to avoid disruptions when upgrading from 6.3.Z or -6.4.X to 6.4.Y with Y > X. Care was taken to not change the interface -incompatibly. +configured server statements to this Implicit TLS mode. A. Copyright, License and Non-Warranty diff --git a/fetchmail.man b/fetchmail.man index 90451f4d..bc85bfd4 100644 --- a/fetchmail.man +++ b/fetchmail.man @@ -69,8 +69,12 @@ language (if supported). However if you are posting to mailing lists, please leave it in. The maintainers do not necessarily understand your language, please use English. - - +.SH TLS (SSL) QUICKSTART +.PP +Your fetchmail distribution should have come with a README.SSL file, which see. +It is recommended to configure all polls with --ssl --sslproto tls1.2+ +if supported by the server, which configures fetchmail along recent IETF +proposed standards and best current practices, RFC-8314, RFC-8996, RFC-8997. .SH CONCEPTS If \fBfetchmail\fP is used with a POP or an IMAP server (but not with @@ -441,10 +445,11 @@ from. The folder information is written only since version 6.3.4. .B \-\-ssl (Keyword: ssl) .br -Causes the connection to the mail server to be encrypted via SSL, by -negotiating SSL directly after connecting (SSL-wrapped mode). -Please see the description of \-\-sslproto below! More information is -available in the \fIREADME.SSL\fP file that ships with fetchmail. +Causes the connection to the mail server to be encrypted via SSL, by +negotiating SSL directly after connecting (called SSL-wrapped mode, or +Implicit TLS by RFC-8314). Please see the description of \-\-sslproto +below! More information is available in the \fIREADME.SSL\fP file that +ships with fetchmail. .IP Note that even if this option is omitted, fetchmail may still negotiate SSL in-band for POP3 or IMAP, through the STLS or STARTTLS feature. You @@ -510,19 +515,22 @@ be opportunistic TLS for POP3 and IMAP, where fetchmail will attempt to upgrade to TLSv1 or newer. .IP Recognized values for \-\-sslproto are given below. You should normally -chose one of the auto-negotiating options, i. e. '\fBauto\fP' or one of -the options ending in a plus (\fB+\fP) character. Note that depending -on OpenSSL library version and configuration, some options cause -run-time errors because the requested SSL or TLS versions are not +chose one of the auto-negotiating options, i. e. '\fBtls1.2+\fP' or +'\fBauto\fP' or one of the other options ending in a plus (\fB+\fP) character. +Note that depending on OpenSSL library version and configuration, some options +cause run-time errors because the requested SSL or TLS versions are not supported by the particular installed OpenSSL library. .RS -.IP "\fB''\fP, the empty string" -Disable STARTTLS. If \-\-ssl is given for the same server, log an error -and pretend that '\fBauto\fP' had been used instead. +.IP '\fBTLS1.2+\fP' +(recommended). Since v6.4.0. Require TLS. Auto-negotiate TLSv1.2 or newer. .IP '\fBauto\fP' -(default). Since v6.4.0. Require TLS. Auto-negotiate TLSv1 or newer, disable SSLv3 downgrade. +(default). Since v6.4.0. Require TLS. Auto-negotiate TLSv1 or newer, disable +SSLv3 downgrade. (fetchmail 6.3.26 and older have auto-negotiated all protocols that their OpenSSL library supported, including the broken SSLv3). +.IP "\fB''\fP, the empty string" +Disable STARTTLS. If \-\-ssl is given for the same server, log an error +and pretend that '\fBauto\fP' had been used instead. .IP \&'\fBSSL23\fP' see '\fBauto\fP'. .IP \&'\fBSSL3\fP' @@ -543,8 +551,6 @@ Since v6.4.0. Require TLS v1.1 exactly. Since v6.4.0. Require TLS. Auto-negotiate TLSv1.1 or newer. .IP \&'\fBTLS1.2\fP' Since v6.4.0. Require TLS v1.2 exactly. -.IP '\fBTLS1.2+\fP' -Since v6.4.0. Require TLS. Auto-negotiate TLSv1.2 or newer. .IP \&'\fBTLS1.3\fP' Since v6.4.0. Require TLS v1.3 exactly. .IP '\fBTLS1.3+\fP' |