On Thu, Sep 23, 2021 at 10:02:26PM -0400, David Mandelberg wrote: > With the settings below, postfix 3.5.6 and openssl 1.1.1k successfully > connected to a server with a 2048-bit RSA key, which should be > disallowed by openssl's security level 4.
Postfix explicitly overrides the security level to 0 for the "may" and "encrypt" security levels, and 1 for all higher levels. Coincidentally, Wietse and I were just discussing the possibility of making the authenticated TLS security level configurable. Not that its actually a good idea in most cases to turn it up to 11. > Does that mean that if I'm using a Postfix security level (which is > different from the openssl security level) greater than or equal to > encrypt, there's no way to set the openssl security level? Correct, Postfix uses sensibly interoperable OpenSSL security levels, but the floor for sensibly interoperable may eventually rise to 2, which will likely be the default security level for OpenSSL 3.1.0 when it is released. > Or am I missing another way to do it / misunderstanding the code? > Openssl's level 1 is really low. No, we're just helping you to avoid wasting your time to erect unnecessary interoperability barriers. :-) > P.S. Searching for SSL_set_security_level and > SSL_CTX_set_security_level, I see a few other calls. I think those calls > aren't as relevant as the one above, but I'm not sure. I do also want to > change the openssl security level for smtpd though, which looks like it > might also be a similar issue? The security level for smtpd(8) should remain at 0 at least on port 25, it is up to clients to ensure they're making sufficiently secure connections. They can always use a cleartext long-haul connection via a stunnel proxy if want an insecure connection to your server. See: http://www.postfix.org/TLS_README.html#client_tls_limits One could make a weak case that on SUBMIT ports (465 and 587) the SMTP server should set a high floor on TLS parameters to assure a secure connection from clients, but this would mostly be a mirage. When the security levels become configurable I'll do my best to discourage users from changing the defaults or setting them unreasonably high, expecting actual security as a result. You get security by raising the ceiling not the floor (see also <https://datatracker.ietf.org/doc/html/rfc7435>). Barring rather novel handshake protocol downgrade attacks on TLS 1.2, the client and server will negotiate the stongest mutually available ciphers. Setting high floors is counter-productive for SMTP and mostly a bad idea also for SUBMIT, unless you expect to be supporting users with exceedingly outdated software on their systems, which you want to force them to upgrade by refusing connectivity. -- Viktor.