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. > 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? > Wietse Demi
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
