X-Git-Url: https://git.exim.org/users/heiko/exim.git/blobdiff_plain/51fb80db26ea90194e91bfb4b9676715f1466dfc..6de1067a8651cc74c59bb661f135235cd8d98e5b:/doc/doc-txt/GnuTLS-FAQ.txt?ds=sidebyside diff --git a/doc/doc-txt/GnuTLS-FAQ.txt b/doc/doc-txt/GnuTLS-FAQ.txt index 60f402004..8d5887bac 100644 --- a/doc/doc-txt/GnuTLS-FAQ.txt +++ b/doc/doc-txt/GnuTLS-FAQ.txt @@ -143,6 +143,10 @@ connections. (6): What's the deal with tls_dh_max_bits? What's DH? ------------------------------------------------------ +You can avoid all of the tls_dh_max_bits issues if you leave "tls_dhparam" +unset, so that you get one of the standard built-in primes used for DH. + + DH, Diffie-Hellman (or Diffie-Hellman-Merkle, or something naming Williamson) is the common name for a way for two parties to a communication stream to exchange some private random data so that both end up with a shared secret @@ -232,6 +236,43 @@ security versus compatibility by raising it. A future release of Exim may even let the administrator tell GnuTLS to ask for more or less than "NORMAL". +To add to the fun, the size of the prime returned by GnuTLS when we call +gnutls_dh_params_generate2() is not limited to be the requested size. GnuTLS +has a tendency to overshoot. 2237 bit primes are common when 2236 is +requested, and higher still have been observed. Further, there is no API to +ask how large the prime bundled up inside the parameter is; the most we can do +is ask how large the DH prime used in an active TLS session is. Since we're +not able to use GnuTLS API calls (and exporting to PKCS3 and then calling +OpenSSL routines would be undiplomatic, plus add a library dependency), we're +left with no way to actually know the size of the freshly generated DH prime. + +Thus we check if the the value returned is at least 10 more than the minimum +we'll accept as a client (EXIM_CLIENT_DH_MIN_BITS, see below, defaults to +1024) and if it is, we subtract 10. Then we reluctantly deploy a strategy +called "hope". This is not guaranteed to be successful; in the first code +pass on this logic, we subtracted 3, asked for 2233 bits and got 2240 in the +first test. + +If you see Thunderbird clients still failing, then as a user who can see into +Exim's spool directory, run: + +$ openssl dhparam -noout -text -in /path/to/spool/gnutls-params-2236 | head + +Ideally, the first line will read "PKCS#3 DH Parameters: (2236 bit)". If the +count is more than 2236, then remove the file and let Exim regenerate it, or +generate one yourself and move it into place. Ideally use "openssl dhparam" +to generate it, and then wait a very long time; at least this way, the size +will be correct. + +The use of "hope" as a strategy was felt to be unacceptable as a default, so +late in the RC series for 4.80, the whole issue was side-stepped. The primes +used for DH are publicly revealed; moreover, there are selection criteria for +what makes a "good" DH prime. As it happens, there are *standard* primes +which can be used, and are specified to be used for certain protocols. So +these primes were built into Exim, and by default exim now uses a 2048 bit +prime from section 2.2 of RFC 5114. + + A TLS client does not get to choose the DH prime used, but can choose a minimum acceptable value. For Exim, this is a compile-time constant called "EXIM_CLIENT_DH_MIN_BITS" of 1024, which can be overruled in "Local/Makefile".