Demi Marie Obenour:
> On 4/15/21 11:00 AM, Wietse Venema wrote:
> > Demi Marie Obenour:
> >> Would the following be a good idea?
> > [a bunch of port-dependent behavior]
> >
> > That is all good and well, but this needs to be made configurable.
> >
> > I boldly assume this will use the xxx_tls_wrapper_mode parameters,
> > instead of replacing them with some totally different mechanism.
>
> I don?t particularly care about the mechanism. Since this already
> exists, using it is obviously preferable to writing a new one.
>
> > Possible options:
> >
> > smtpd_tls_wapper_mode =
> > Something that depends on an inbound port which is defined
> > in master.cf. As of Postfix 3.3, the read-only "service_name"
> > parameter contains the first field of a master.cf entry,
> > in the form of a port, service-name, host:port, host:service-name,
> > or UNIX-domain pathname. Extracting or matching the port
> > or service-name portion is beyond what is currently possible
> > with Postfix conditional parameter expansions. From a
> > security standpoint, using this information is OK because
> > master.cf is writable by the super-user only, and because
> > the Postfix master daemon is a trusted process.
> >
> > smtp_tls_wrapper_mode =
> > Something that depends on an outbound port or service-name
> > that is specified in a delivery request in a next-hop
> > destination as host:port or host:service-name (this is based
> > on information from default_transport, relayhost, transport_maps,
> > or the sender-dependent versions of those). Basically,
> > this would make parameter evaluation dependent on data in
> > a delivery request. There is prior art for doing this in
> > the local delivery agent in very limited cases: luser_relay,
> > forward_path, and command_execution_directory. That had to
> > be implemented very carefully to avoid security problems.
> >
> > So based on this we need
> >
> > 1) SMTP server: Add support to match the port or service name in
> > in the service_name parameter (new parameter evaluation code,
> > non-trivial), OR: make the port or service name available as another
> > parameter (new code in daemon library, trivial and safe). In both
> > cases, make the smtpd_ls_wrapper_mode default value port dependent.
>
> Exactly.
This introduces no new opportunities for attack, as it does not
involve new information flows. It is now a matter of cost versus
benefit. Time spent on this cannot be spent on something else.
> > 2) SMTP client: Postpone the evaluation of smtp_tls_wrapper_mode
> > until after a delivery request is received, add support for
> > request-dependent $parameter expansion in smtp_tls_wrapper_mode,
> > and make that bullet-proof. Doing this for smtp_tls_wrapper_mode
> > can be made safe; doing this for more SMTP client parameters would
> > require a much more extensive security analysis.
>
> From my perspective, SMTP + STARTTLS is equivalent to SMTPS, except
> that they use different port numbers and the latter uses fewer
> round-trips. Obviously, downgrade from TLS to no TLS is bad, but
> switching between SMTP + STARTTLS and SMTPS is fine.
>
> That said, this appears to be more complicated than I thought it
> would be. Do you consider the extra complexity (and attack surface)
> justified?
Maybe. If smtp_tls_wrapper_mode is made port-dependent, then it can
be safe as long as the destination has already been validated as a
legitimate service name or TCP port number. Other request attributes
would be harder to validate, and that could lead down a slippery
slope.
Forgetting to turn on smtp_tls_wrappemode is a low-probability
mistake in what is now a rarely-used feature. And the error message
is better (connection timed out while waiting for server greeting)
than in the missing smtpd_tls_wrappermode case (lost connection
after unknown, too many errrors). So the effort is non-trivial and
the benefit is small.
Wietse
