Backport of 94e341dee51c
The original intent of having kEDH before kEECDH was that if a `dhparam`
file was specified, this would be interpreted as a preference by the
admin for old and well-tested Diffie-Hellman key agreement over newer
elliptic curve ones. Otherwise the faster elliptic curve ciphersuites
would be preferred. This didn't really work as intended since this
affects the ClientHello on outgoing s2s connections, leading to some
servers using poorly configured kEDH.
With Debian shipping OpenSSL settings that enforce a higher security
level, this caused interoperability problems with servers that use DH
params smaller than 2048 bits. E.g. jabber.org at the time of this
writing has 1024 bit DH params.
MattJ says
> Curves have won, and OpenSSL is less weird about them now
This makes
`prosodyctl cert import example.com /path/to/example.com/fullchain.pem`
work. This was never intended to, yet users commonly tried this and got
problems.
Removes the need to enable DANE with two separate settings.
Previously you had to also set `ssl = { dane = true }` to activate DANE
support in LuaSec and OpenSSL.
Quick Fix\u{2122} to stop prevent certmanager from automatically adding
a client certificate for net.http.request, since this normally does not
require such.
lfs.dir() throws a hard error if there's a problem, e.g. no such
directory or permission issues. This also gets called early enough that
the main loop error protection hasn't been brought up yet, causing a
proper crash.
Otherwise the default "certs" would be relative to $PWD, which works
when testing from a source checkout, but not on installed systems where
it usually points to the data directory.
Also, the LuaFileSystem dir() iterator throws a hard error, which may
cause a crash or other problems.
Thanks to debacle for reminding me, in the context of mod_auth_ccert
I wonder if we still need lsec_ignore_purpose, Let's Encrypt seems to
include both client and server purposes in certs.
This is needed for SNI where certificates are in separate
per-hostname contexts, not the main one.
If there is a cert, it will still require a corresponding key.
The original intent of having kEDH before kEECDH was that if a `dhparam`
file was specified, this would be interpreted as a preference by the
admin for old and well-tested Diffie-Hellman key agreement over newer
elliptic curve ones. Otherwise the faster elliptic curve ciphersuites
would be preferred. This didn't really work as intended since this
affects the ClientHello on outgoing s2s connections, leading to some
servers using poorly configured kEDH.
With Debian shipping OpenSSL settings that enforce a higher security
level, this caused interoperability problems with servers that use DH
params smaller than 2048 bits. E.g. jabber.org at the time of this
writing has 1024 bit DH params.
MattJ says
> Curves have won, and OpenSSL is less weird about them now