On Fri, Jul 23, 2021 at 11:21:14AM +1000, raf wrote:
> > > The FORWARD_SECRECY_README suggests regenerating the
> > > Postfix SMTP server EDH parameters periodically.
> > > Would doing so necessitate a postfix reload?
> >
> > No. The new parameters get picked up by new smtpd(8)
> > processes as old ones exit after handling $max_use
> > connections or being idle at least $max_idle.
>
> Thanks for that. Am I right in thinking that the same
> doesn't apply when letsencrypt certificates are
> renewed? I read somewhere that people needed to
> automate the restarting of postfix and dovecot when
> that happens.
For the same reason as above, Postfix also DOES NOT need to be reloaded
during regulard (non-emergency) certificate rollover. Dovecot on the
other hand does need to be reloaded IIRC (I seem to need to do that
on my server).
Lots of people who think they know something write HOWTO guides, but
most of them make some of it up.
> I was more concerned that the documentation doesn't
> state clearly whether or not a reload is needed.
Postfix reloads are required very rarely, pretty much only when you
change parameters that affect the master(8) process (e.g. routine
master.cf changes), qmgr(8), or tlsmgr(8). Some changes to master.cf
(listen addresses of network services) require a restart.
On my server, very few Postfix processes have been running non-stop
since master(8) was started, the rest are recycled and pick up new
settings automatically:
PID ELAPSED COMMAND
76082 41-12:05:31 /usr/local/libexec/postfix/master -w
76221 41-11:54:22 qmgr -l -t unix -u
76224 41-11:54:21 tlsmgr -l -t unix -u
8310 01:32:05 pickup -l -t unix -u -o
receive_override_options=no_header_body_checks
9487 23:11 anvil -l -t unix -u
9621 00:09 smtpd -n smtp -t inet -u -o stress= -s 2 -o
smtpd_discard_ehlo_keywords=silent-discard,DSN
9622 00:09 proxymap -t unix -u
If your changes are not critically urgent, no reload is generally
required.
> Perhaps the absence of such a statement is to be interpreted to mean
> that it doesn't, but that would just be a guess, and TLS_README
> doesn't mention needing to reload when the certificate/key files are
> updated, but it seems that that is needed.
No reload is generally required, the documentation strives to explicitly
call out the cases when a reload may be required or desirable,
otherwise, unless we failed to mention it, reload is not needed.
> > In practice security is compromised by going around the
> > crypto, rather than cracking the algorithms. Focus on
> > the basics, keeping your endpoints up to date, monitoring,
> > ... Security is about operational discipline, the
> > cryptography gets all the press, but is almost never the
> > weak link.
>
> Very true, but the care and feeding of crypto matters
> too, otherwise https://ssl-config.mozilla.org and
> https://www.ssllabs.com wouldn't exist.
Those are also overhyped, though not quite as much in the context of
HTTPS. In SMTP TLS is opportunistic, and if you crank up the crypto to
11, often what happens is that more email is sent in the clear instead,
making "hardening" counter-productive. The same can also happen with
HTTPS, if a user is forced to use HTTP in order to avoid HTTPS breakage,
but much less often since browsers typically have new shiny crypto.
> And my government's tax department wouldn't insist on payroll service
> providers and the like not using anything older than TLSv1.2 for their
> websites and APIs. But perhaps that's just part of keeping your
> endpoints up to date.
The Web is a different story, and at this time TLS 1.0 is mostly gone
from the ecosystem, and 1.1 was pretty much never adopted, so turning
both off if is generally not imprudent.
> Having said that, regenerating DH params does seem like
> overkill, and just gives the monitoring more to whinge
> about. :-)
Very little TLS tuning has real benefit in Postfix, the defaults are
generally quite sufficient.
--
Viktor.
