I’m trying to fetch mail from a server which (obviously) has old crypto settings. When running fetchmail it fails with
error:141A318A:SSL routines:tls_process_ske_dhe:dh key too small
As an experiment, I am able to connect to this site if I change to SECLEVEL=1 in /etc/crypto-policies/back-ends/opensslcnf.config. But that file is generated, and it would anyway change things globally which of course I don’t want. Anyone knows how to do this only for a particular fetchmail invocation?
The error seems to say that the server admin uses a 1024-bit DHE key. This is insecure as that key is way too small and can likely be brute-.forced with enough resources! See https://weakdh.org, which is a vulnerability based on that that is a few years old, so given computing resources rise, breaking such things gets easier and easier…
Even Debian requires 2048-bit apparently.
Well, if I had any control over the server I would certainly fix it. But I don’t, and I have to read mails arriving to this server. Currently the only alternative I have is to use non-encrypted IMAP! That feels significantly worse than even a bad crypto, wouldn’t you agree?
It is also not quite that bad since the server is not world accessible.
Do you know how it could be done?
How do you infer from the message it is exactly 1024 bit key it is using?
I belive I did. Prompted by your question I tried again and also retried the other possible values for --sslproto. It didn’t make any difference. (Well, except that when I tried e.g SSL2 it wasn’t supported, but anyway.)
While doing that however, I mistakenly ran fetchmail once without the --ssl flag, and only --sslproto. That actually worked. It seems to have the effect of starting TLS using the regular imap port and STARTTLS rather than using the separate imaps port. I’m a little suprised that makes a difference when it comes to key lengths, but apparently it does.
Reading through the fetchmail options once more, I belive --sslcertck might be the flag I actually want.