Bug 1235056

This should be viewed as a security issue and fixed asynchronously as the default parameters should be at least 1024 bits otherwise they are insecure.

Thanks much for the alternate workaround. Mr. Google (heh) also says (e.g. https://www.freebsd.org/security/advisories/FreeBSD-EN-15:08.sendmail.asc) that

define(`confDH_PARAMETERS', `1')dnl

in sendmail.mc should work, bypassing the need to generate an extra file by hand yourself. (Any parameter beginning with 1 is interpreted as 1024.) I haven't tried that yet.

Well, now I've tried it, both

define(`confDH_PARAMETERS', `1024')dnl

and

define(`confDH_PARAMETERS', `/path/to/dh.param')dnl

With (either) alternate fix in place, I start seeing the dread "TLS handshake failed" in the mail logs again.

I may be doing something else incorrectly, but I've gone back to the original sendmail.mc workaround:

LOCAL_CONFIG
O CipherList=DEFAULT:!EDH:!DHE

From the Sendmail Installation and Operational Guide for sendmail-8.14.4-9.el6 ('op.pdf'):

--
DHParameters:
Possible values are:
5 - use 512 bit prime
1 - use 1024 bit prime
none - do not use Diffie-Hellman
NAME - load prime from file

This is only required if a ciphersuite containing DSA/DH is used. If ‘‘5’’ is
selected, then precomputed, fixed primes are used. This is the default for the
client side. If ‘‘1’’ is selected, then prime values are computed during startup.
This is the default for the server side. Note: this operation can take a significant amount of time on a slow machine (several seconds), but it is only done once at startup.
--

I checked the code and it seems it really uses 1024 bits on server by default and we do not redefine the defaults.

Right, the point of the confDH_PARAMETERS change is to ensure that picky clients can connect to your server, ie that you can *receive* mail with TLS.  The business with CipherList is a workaround that can be applied on the *sending* side if the receiver has an insecurely small DH parameter --- but the proper long-term fix is really to fix the receiver's DH setting.

(In reply to Paul Sand from comment #3)
> Thanks much for the alternate workaround. Mr. Google (heh) also says (e.g.
> https://www.freebsd.org/security/advisories/FreeBSD-EN-15:08.sendmail.asc)

This is workaround for "sendmail client rejected by server due to small DH", so at least comment 0 is incorrect, because default settings is OK on server.

(In reply to Jaroslav Škarvada from comment #5)
> This is only required if a ciphersuite containing DSA/DH is used. If ‘‘5’’ is
> selected, then precomputed, fixed primes are used. This is the default for
> the client side. If ‘‘1’’ is selected, then prime values are computed during
> startup. This is the default for the server side.

Hm.  That does not seem to square with my observational experience.  I noticed the reported problem when I tried to send mail to cs.cmu.edu on Monday, shortly after applying the recent openssl update.  After some googling, I generated a larger DH file and added the confDH_PARAMETERS setting with a file name to my own sendmail config, but that did not fix it.  I eventually contacted CMU by phone (how 20th century) and the upshot was that they'd also generated a larger DH parameter file, but had forgotten to add the actual confDH_PARAMETERS setting to their sendmail config.  After they did that, the mail went through.  So it seems clear that the default server-side DH setting is *NOT* large enough to satisfy the new openssl.

Is it possible that the text you're quoting here is the result of some Red Hat patching, and doesn't reflect the behavior of the average sendmail in the wild?
Or maybe it was changed in sendmail 8.14?  (From their Received: lines I gather
that CMU is running 8.13.6.)

(In reply to Tom Lane from comment #8)
Sorry I am unable to reproduce, cleanly provisioned Red Hat Enterprise Linux Server release 6.6 (Santiago), sendmail-8.14.4-8.el6.x86_64, default configuration:

$ openssl s_client -starttls smtp -connect localhost:25
...
Server Temp Key: DH, 1024 bits
...

So it's 1024 bits exactly as stated in the operational guide.

Created attachment 1042784 [details]
Client hardening to use 1024 bits

AFAIK this is not upstream. It will use 1024 bits also on client by default. But I think rather than diverging from upstream KB article about this problem would be probably enough.

FYI: I've re-tried the experiment from the opening comment with current sendmail and openssl on RHEL-6.9, i.e.:
sendmail-8.14.4-9.el6_8.1.x86_64
openssl-1.0.1e-57.el6.x86_64

I have two RHEL-6.9 machines running sendmail to serve as the SMTP client and server. Both of them use the default config except for:
** Client:
define(`confLOG_LEVEL', `18')dnl
define(`SMART_HOST', `test-server')dnl
** Server:
define(`confLOG_LEVEL', `18')dnl
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
define(`confSERVER_CERT', `/etc/pki/tls/certs/sendmail.pem')dnl
define(`confSERVER_KEY', `/etc/pki/tls/certs/sendmail.pem')dnl
DAEMON_OPTIONS(`Port=smtp, Name=MTA')dnl

The server has a fairly generic self-signed TLS certificate generated using the instructions in sendmail.mc.

Upon sending out an e-mail at the client using mailx, a successful TLS session using DH takes place. Excerpt from client's maillog:

Aug  3 07:52:58 hostname sendmail[9158]: v73Bqw14009156: SMTP outgoing connect on test-client
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS: ClientCertFile missing
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS: ClientKeyFile missing
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS: CACertPath missing
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS: CACertFile missing
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS: CRLFile missing
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, init=1
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, start=ok
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, info: fds=11/10, err=2
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, info: fds=11/10, err=2
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, info: fds=11/10, err=2
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, info: fds=11/10, err=2
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, get_verify: 18 get_peer: 0x7f138163da50
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, relay=test-server, field=cn_subject, status=failed to extract CN
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, relay=test-server, field=cn_issuer, status=failed to extract CN
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, relay=test-server, version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-GCM-SHA384, bits=256/256
Aug  3 07:52:58 hostname sendmail[9158]: STARTTLS=client, cert-subject=/C=XX/L=Default+20City/O=Default+20Company+20Ltd, cert-issuer=/C=XX/L=Default+20City/O=Default+20Company+20Ltd, verifymsg=self signed certificate

The server uses a 1024-bit DH parameter (not key(?), I believe, technically speaking) - topmost part of server's maillog follows. The "(1)" incicates the choice of 1024 bits as DH_PARAMETERS (as stated above, anything that starts with a '1' equals 1024).

Aug  3 07:52:51 hostname sendmail[3632]: starting daemon (8.14.4): SMTP+queueing@01:00:00
Aug  3 07:52:51 hostname sendmail[3632]: STARTTLS: CRLFile missing
Aug  3 07:52:51 hostname sm-msp-queue[3642]: starting daemon (8.14.4): queueing@01:00:00
Aug  3 07:52:51 hostname sendmail[3632]: STARTTLS=server, Diffie-Hellman init, key=1024 bit (1)
Aug  3 07:52:51 hostname sendmail[3632]: STARTTLS=server, init=1

The check from comment 9 passess too:
# openssl s_client -starttls smtp -connect test-server:25
   (...)
Server Temp Key: DH, 1024 bits
   (...)
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
   (...)



As for the SMTP-client side of sendmail, I think it never generates any DH parameters in the first place. This needs careful verification (I'm not a developer), but it looks to me like the function inittls() in sendmail/tls.c is the only one which generates DH params. And this function never seems to be called by the client with any other "req" parameter but TLS_I_CLT. TLS_I_TRY_DH is required, however, for any DH parameter generation to take place. I haven't tested this rigorously, but I know from a recent experiment that the client side never generates the log message "(...) Diffie-Hellman init, key=%d bit (%c)". (It was a more recent version of sendmail, but the code looks basically the same.)

This means that it's not necessary to worry about the client side of sendmail at all WRT DH params (despite what the comments and the code in inittls() suggest). Furthermore, I think the patch from comment 10 would have no effect.

The fact that only the server generates DH params (and clients just adopt them) in OpenSSL (or TLS itself?) is also noted in a message linked at the top of this wiki page:
https://wiki.openssl.org/index.php/Diffie-Hellman_parameters

Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:
http://redhat.com/rhel/lifecycle

This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com