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

Internet access discussion, including Fusion, IP Broadband, and Gigabit Fiber!
11 posts Page 1 of 2
by oddhack » Sat Feb 29, 2020 1:17 pm
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?
by oddhack » Sat Feb 29, 2020 2:20 pm
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.
by RWCFiber » Sun Mar 01, 2020 8:09 am
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.
by oddhack » Mon Mar 02, 2020 3:20 pm
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.
by kgc » Mon Mar 02, 2020 4:34 pm
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.
Kelsey Cummings
System Architect, Sonic.net, Inc.
by gkeller » Mon Mar 02, 2020 5:00 pm
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.
Grant Keller
Sonic.net System Operations
by oddhack » Mon Mar 02, 2020 5:07 pm
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.
by oddhack » Mon Apr 20, 2020 5:44 pm
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.
by gkeller » Tue Apr 21, 2020 3:55 pm
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.
Grant Keller
Sonic.net System Operations
by oddhack » Sat Jul 11, 2020 6:11 am
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.
11 posts Page 1 of 2

Who is online

In total there are 37 users online :: 0 registered, 0 hidden and 37 guests (based on users active over the past 5 minutes)
Most users ever online was 999 on Mon May 10, 2021 1:02 am

Users browsing this forum: No registered users and 37 guests