Page 1 of 2

SSL "key too small" errors fetching email from imap.sonic.net

Posted: Sat Feb 29, 2020 1:17 pm
by oddhack
I just upgraded from Debian 9 to 10, and fetchmail is now reporting
fetchmail: OpenSSL reported: error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from oddhack@imap.sonic.net
fetchmail: Query status=2 (SOCKET)
This is specific to Sonic; fetchmail still works OK with imap.googlemail.com and outlook.office365.com. Web search turned up someone on Comcast with the same issue, and suggested that the default fetchmail settings were using an old SSL protocol incompatible with modern security settings. They were able to resolve the problem by adding 'ssl sslproto tls1', but that has no effect with Sonic. Any suggestions?

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Sat Feb 29, 2020 2:20 pm
by oddhack
Followup: numerous attempts to tweak the fetchmail config to use other SSL protocols did not help, so following a comment in https://bugs.debian.org/cgi-bin/bugrepo ... bug=907015 I modified /etc/ssl/openssl.cnf to comment out the
CipherString = DEFAULT@SECLEVEL=2
line.

(Update: better than commenting it out is changing to DEFAULT@SECLEVEL=1, which appears to restore the Debian 9 / SSL 1.0 key length requirement).

Fetchmail now works, but this is clearly not a viable long-term solution and it has unknown effects on other aspects of my system security.

Judging from the comments on the link above and others, the real issue here is that imap.sonic.net uses a Diffie-Helman key which is considered too short by modern standards.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Sun Mar 01, 2020 8:09 am
by RWCFiber
oddhack wrote:the real issue here is that imap.sonic.net uses a Diffie-Helman key which is considered too short by modern standards.
Ouch. That is very concerning. I would have thought Sonic would have better security than other ISP email providers.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Mon Mar 02, 2020 3:20 pm
by oddhack
I dug around a bit more and found https://wiki.debian.org/ContinuousInteg ... nssl-1.1.1 , which says in part:
This is caused by the SECLEVEL 2 setting the security level to 112 bit. This means that RSA and DHE keys need to be at least 2048 bit long. SHA-1 is no longer supported for signatures in certificates and you need at least SHA-256. Note that CAs have stopped issuing certificates that didn't meet those requirements in January 2015, and since January 2017 all valid CA certificates should meet those requirements. However there are certificates generated by private CAs or that are in a test suite that do not meet those requirements.

SECLEVEL 1 was the default in previous versions and is at the 80 bit security level, requiring a 1024 bit RSA key.
So this seems pretty likely to be a configuration problem on Sonic's end and they should probably replace their IMAP cert with a current one. Filing a support request to that effect.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Mon Mar 02, 2020 4:34 pm
by kgc
We're looking at this now. We have some concerns around locking older clients and operating systems but hopefully we can increase the DH key size without causing any problems for these users.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Mon Mar 02, 2020 5:00 pm
by gkeller
In regards to the certificate itself, the current one is SHA256. That error does appear to be in reference to the DH key size, which is currently 1024. As Kelsey said, we are looking to increase the length, but balancing compatibility and security has always been harder with mail clients than with web clients.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Mon Mar 02, 2020 5:07 pm
by oddhack
gkeller wrote:In regards to the certificate itself, the current one is SHA256. That error does appear to be in reference to the DH key size, which is currently 1024. As Kelsey said, we are looking to increase the length, but balancing compatibility and security has always been harder with mail clients than with web clients.
Thanks! The most annoying thing here is that there doesn't (seem) to be any way to configure fetchmail to override the system default, so being able to get my email probably weakens other aspects of system security.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Mon Apr 20, 2020 5:44 pm
by oddhack
gkeller wrote:In regards to the certificate itself, the current one is SHA256. That error does appear to be in reference to the DH key size, which is currently 1024. As Kelsey said, we are looking to increase the length, but balancing compatibility and security has always been harder with mail clients than with web clients.
Any updates on whether you'll be able to do this upgrade? Thanks.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Tue Apr 21, 2020 3:55 pm
by gkeller
The recent maintenance windows have been to move the mail service onto more robust network infrastructure. Among other benefits this will allow us to proceed with upgrading the software, so that is my current task. It's hard to give a firm estimate on when this will be complete, so for now I will remain vague and say it should be done in the next couple of weeks.

Re: SSL "key too small" errors fetching email from imap.sonic.net

Posted: Sat Jul 11, 2020 6:11 am
by oddhack
gkeller wrote:The recent maintenance windows have been to move the mail service onto more robust network infrastructure. Among other benefits this will allow us to proceed with upgrading the software, so that is my current task. It's hard to give a firm estimate on when this will be complete, so for now I will remain vague and say it should be done in the next couple of weeks.
Wondering if there are any updates on this? There is a possibility of the fetchmail maintainer adding an app-level configuration which would remove the necessity of weakening system security to get my email, but that wouldn't happen for a while, either.