From: Matthias A. <mat...@gm...> - 2021-08-15 14:41:02
Attachments:
signature.asc
|
Greetings, all released fetchmail versions to date (up to and including 6.4.21) were found susceptible to some sorts of attacks against STARTTLS (IMAP) or STLS (POP3), which can lead to a session that remains unencrypted even though --sslproto tls1.2+ or similar configurations require encryption, and worst case exposing the user's login credentials and also e-mail when the configuration tells otherwise. The solution in fetchmail code requires thorough reviews and changes that will take more time. Remember that fetchmail is a volunteer spare-time project. The details of the implementation and concept flaws shall be disclosed later in the formal fetchmail security announcement 2021-02 (not yet published). MITIGATING THE IMPACT: Proper configuration for Implicit TLS can mitigate the impact for many users. I am already announcing such configuration changes below: ------------------------------------------------------------------------ Everyone whose server supports "Implicit TLS", meaning TLS on a dedicated imaps port (TCP port 993) or pop3s port (TCP port 995), should reconfigure fetchmail to enable this option (ssl or --ssl) permanently. This can be achieved in two ways, either of which alone is sufficient: - on the command line, add --ssl), which will affect all servers included in the poll (= all poll statements from the rcfile, or all servers mentioned on the same command line). - in the rcfile, by adding the word "ssl" without quotes after each configuration stanza for a user description. After making the change, test your new configuration before enabling unattended operation. Future directions: 1. The Internet Engineering Task Force (IETF) has proposed standards that consider both STARTTLS obsolete (RFC-8314) and deprecate TLS 1.1 and earlier (including all SSL versions) (RFC-8997). 2. I may make Implicit TLS the default in future fetchmail releases, and promise to at least bump the minor version to >= 6.5.0 in that case. ------------------------------------------------------------------------ I will also add an *unrelated* recommendation while we are at it and users are suggested to edit their configurations anyways: I suggest that everyone configures fetchmail to negotiate at least TLS v1.2 if supported by the server, or at least TLS v1.2, which can happen on the command line through --sslproto TLS1.2+ or in the rcfile by adding sslproto TLS1.2+ in each stanza after each user statement. Where possible, meaning server-side support and support by the local OpenSSL library version (for instance, 1.1.1 is good enough), fetchmail can also be configured to require TLS v1.3 or newer instead, in that case, use --sslproto TLS1.3+ on the command line or sslproto TLS1.3+ in the rcfile. future direction: fetchmail 6.5 and newer (not yet released and several weeks to months out) will make TLS 1.2 the minimum required version, and will also require an OpenSSL library that supports TLS 1.3. ------------------------------------------------------------------------ Note that the changes proposed above, when successfully deployed, can remain in place when fetchmail 6.4.22 will be released, so there is no need to wait. |
From: Peter S. <dr...@uc...> - 2021-08-15 19:23:29
|
Dear Matthias, Fedora 34 just upgraded fetchmail for us. Now fetchmail --version shows This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" OpenSSL: OPENSSLDIR: "/etc/pki/tls" Engines: ENGINESDIR: "/usr/lib64/engines-1.1" Since this upgrade my fetchmail logfile is showing the "run-together-lines" behavior, lacking the usual newline chars. This is not a big deal of course, but if there's a way to fix it, let me know. It looks as if you're struggling a bit, so I wish you the best of luck. I really appreciate your depth of knowledge and years and years of dealing with this stuff. fetchmail is so useful. -- Peter ================================================================= On Aug 15, 2021 at 4:40 pm, Matthias Andree <mat...@gm...> wrote: | Greetings, | | all released fetchmail versions to date (up to and including 6.4.21) | were found susceptible to some sorts of attacks against STARTTLS (IMAP) | or STLS (POP3), which can lead to a session that remains unencrypted | even though --sslproto tls1.2+ or similar configurations require | encryption, and worst case exposing the user's login credentials and | also e-mail when the configuration tells otherwise. | | The solution in fetchmail code requires thorough reviews and | changes that will take more time. Remember that fetchmail is | a volunteer spare-time project. | | The details of the implementation and concept flaws shall be disclosed | later in the formal fetchmail security announcement 2021-02 (not yet | published). | | MITIGATING THE IMPACT: | | Proper configuration for Implicit TLS can mitigate the impact for many | users. I am already announcing such configuration changes below: | | ------------------------------------------------------------------------ | Everyone whose server supports "Implicit TLS", meaning TLS on | a dedicated imaps port (TCP port 993) or pop3s port (TCP port 995), | should reconfigure fetchmail to enable this option (ssl or --ssl) | permanently. | This can be achieved in two ways, either of which alone is sufficient: | | - on the command line, add --ssl), which will affect all servers | included in the poll (= all poll statements from the rcfile, or all | servers mentioned on the same command line). | | - in the rcfile, by adding the word "ssl" without quotes after each | configuration stanza for a user description. | | After making the change, test your new configuration before enabling | unattended operation. | | | Future directions: 1. The Internet Engineering Task Force (IETF) has | proposed standards that consider both STARTTLS obsolete (RFC-8314) and | deprecate TLS 1.1 and earlier (including all SSL versions) (RFC-8997). | | 2. I may make Implicit TLS the default in future fetchmail releases, | and promise to at least bump the minor version to >= 6.5.0 in that case. | ------------------------------------------------------------------------ | | I will also add an *unrelated* recommendation while we are at it and | users are suggested to edit their configurations anyways: | | I suggest that everyone configures fetchmail to negotiate at least TLS | v1.2 if supported by the server, or at least TLS v1.2, which can happen | on the command line through --sslproto TLS1.2+ or in the rcfile by | adding sslproto TLS1.2+ in each stanza after each user statement. | | Where possible, meaning server-side support and support by the local | OpenSSL library version (for instance, 1.1.1 is good enough), fetchmail | can also be configured to require TLS v1.3 or newer instead, in that | case, use --sslproto TLS1.3+ on the command line or sslproto TLS1.3+ in | the rcfile. | | | future direction: fetchmail 6.5 and newer (not yet released and several | weeks to months out) will make TLS 1.2 the minimum required version, and | will also require an OpenSSL library that supports TLS 1.3. | ------------------------------------------------------------------------ | | | Note that the changes proposed above, when successfully deployed, can | remain in place when fetchmail 6.4.22 will be released, so there is no | need to wait. | _______________________________________________ | Fetchmail-users mailing list | Fet...@li... | https://lists.sourceforge.net/lists/listinfo/fetchmail-users |
From: Peter P. <ro...@ri...> - 2021-08-15 20:25:08
Attachments:
signature.asc
|
On Sun, Aug 15, 2021 at 11:58:34AM -0700, Peter Scott via Fetchmail-users wrote: > Dear Matthias, > > Fedora 34 just upgraded fetchmail for us. > > Now fetchmail --version shows > > This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > OpenSSL: OPENSSLDIR: "/etc/pki/tls" > Engines: ENGINESDIR: "/usr/lib64/engines-1.1" > > Since this upgrade my fetchmail logfile is showing the > "run-together-lines" behavior, lacking the usual newline chars. I think this bug was fixed in 6.4.21, was it not? So when the Fedora maintainer updates fetchmail to 6.4.21, you will get the fix. G'luck, Peter -- Peter Pentchev ro...@ri... ro...@de... pp...@st... PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 |
From: Matthias A. <mat...@gm...> - 2021-08-16 16:54:54
|
Am 15.08.21 um 22:08 schrieb Peter Pentchev: > On Sun, Aug 15, 2021 at 11:58:34AM -0700, Peter Scott via Fetchmail-users wrote: >> Dear Matthias, >> >> Fedora 34 just upgraded fetchmail for us. >> >> Now fetchmail --version shows >> >> This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. >> Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" >> Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" >> OpenSSL: OPENSSLDIR: "/etc/pki/tls" >> Engines: ENGINESDIR: "/usr/lib64/engines-1.1" >> >> Since this upgrade my fetchmail logfile is showing the >> "run-together-lines" behavior, lacking the usual newline chars. > I think this bug was fixed in 6.4.21, was it not? So when the Fedora > maintainer updates fetchmail to 6.4.21, you will get the fix. Peter, correct, the --syslog and --logfile I broke in 6.4.20 were fixed in 6.4.21. The Fedora package maintainer wrote me this morning that he updated things earlier today, but the builds will take a few days to propagate. My addition is that the daring may check <https://koji.fedoraproject.org/koji/packageinfo?packageID=1046> and grab their RPM individually and test, but I am not affiliated with Fedora and cannot help or support this - but feel free to share your findings on Fedora's Bodhi if it works for you (it did not for me), or here, if you try. Regards, Matthias |
From: Matthias A. <mat...@gm...> - 2021-08-15 22:14:09
|
Am 15.08.21 um 20:58 schrieb Peter Scott via Fetchmail-users: > Dear Matthias, > > Fedora 34 just upgraded fetchmail for us. > > Now fetchmail --version shows > > This is fetchmail release 6.4.20+GSS+RPA+NTLM+SDPS+SSL-SSLv2-SSLv3+NLS+KRB5. > Compiled with SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > Run-time uses SSL library 0x101010bf "OpenSSL 1.1.1k FIPS 25 Mar 2021" > OpenSSL: OPENSSLDIR: "/etc/pki/tls" > Engines: ENGINESDIR: "/usr/lib64/engines-1.1" > > Since this upgrade my fetchmail logfile is showing the > "run-together-lines" behavior, lacking the usual newline chars. > > This is not a big deal of course, but if there's a way to fix it, > let me know. Dear Peter, yes they did, same for Fedora 33. Unfortunately, the --logfile option and also --syslog are broken in 6.4.20, truncating log messages. While syslog does not run the lines together, it still misses log message pieces. The workaround for 6.4.20 would be to disable or remove the logfile option, add -N for "nodetach" (meaning fetchmail will stick to the console, and nodetach has a side effect of making log output unbuffered, sidestepping the issue if and only if the output goes to console directly) and then redirect its output to the log file, for instance with: fetchmail --nodetach >>mylogfile.txt (add your other options, if any) or, if you want a copy of the log printed to console: fetchmail --nodetach (your other options here) | tee -a mylogfile.txt > It looks as if you're struggling a bit, so I wish you the best of > luck. I really appreciate your depth of knowledge and years and > years of dealing with this stuff. fetchmail is so useful. Oh, I am not struggling, but thanks for your wishes - it's just a somewhat unlucky timing. First the security issue, then the logging bug in fixing it and then I receive word of the STARTTLS issue... I figured this requires lots of code review, and some rewriting, and some more review. Ideally, all this would have been part of one perfect release, but alas that's not how things worked out. Kind regards, Matthias |