SECURITY: POP3: changes for --auth ssh and RPA

These no longer defeat STARTTLS negotiation,
and RPA is only attempted with --auth any.

1 files changed, 21 insertions, 11 deletions

diff --git a/fetchmail-SA-2021-02.txt b/fetchmail-SA-2021-02.txt
index c660b4aa..ffa2a3d4 100644
--- a/fetchmail-SA-2021-02.txt
+++ b/fetchmail-SA-2021-02.txt
@@ -3,7 +3,7 @@ fetchmail-SA-2021-02: failure to enforce STARTTLS session encryption
 Topics:		fetchmail fails to enforce an encrypted connection
 
 Author:		Matthias Andree
-Version:	0.2
+Version:	0.3
 Announced:	TBC
 Type:		failure to enforce configured security policy
 Impact:		fetchmail continues an unencrypted connection,
@@ -32,6 +32,9 @@ Corrected in:	TBC	Git commit hash (both needed)
 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.
 
 
 1. Background
@@ -60,17 +63,24 @@ a clear-text protocol exchange and then requesting a TLS negotiation in-band.
 IMAP also supports sessions that start in "authenticated state" (PREAUTH).
 In this latter case, IMAP (RFC-3501) does not permit sending STARTTLS 
 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 flagging the situation and aborting.
+  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.
+
+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.
 
 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 PREAUTH mail server with --plugin, or TLS client 
+instance through SSH running a mail server with --plugin, or TLS client 
 certificates), will 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.
@@ -89,10 +99,10 @@ 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 server supports this form of access,
+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) and negotiate TLS without
-prior clear-text protocol exchange.
+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.