301316Re: Individual smtpd_tls_ask_ccert?
- Jul 29, 2014* Viktor Dukhovni <postfix-users@...>:
> On Tue, Jul 29, 2014 at 03:54:37PM +0000, Viktor Dukhovni wrote:The use case goes like this:
> > Perhaps a better option is to change the "match" feature to a lookup
> > feature which returns a value of "no | ask | require | dane", thus we'd have:
> > smtpd_tls_ccert_policy =
> > lookup_client_address static:no,
> > lookup_client_helo_name static:ask,
> > lookup_client_name static:require,
> > lookup_client_helo_name static:dane,
> > with "static" being just an example table type that illustrates
> > the valid RHS values. With this "smtpd_tls_ccert_policy" subsumes
> > and obsoletes both of "smtpd_tls_ask_ccert" and "smtpd_tls_req_ccert".
> The syntactic overhead can be reduced, by making "lookup_client_helo_name"
> smtpd_tls_ccert_policy = static:dane
> and we could also make "static:" implicit when the string is one
> of: "no | ask | require | dane". Thus enabling a no-overhead form:
> smtpd_tls_ccert_policy = ask
> In addition we could also support "dane-only" (requiring TLSA RRs
> from a particular set of clients), and even allow the table lookups
> to return a certificate or public key fingerprint rather than "require".
> Which brings us back to the key question, what is the real motivation
> for this? Preventing HELO forgery? Making TLS access control easier
> to use (with "dane-only", one might be able to use check_helo_access
> safely, because certain HELO names would be authenticated)? Some sort
> of audit-trail that the client connection was not MiTMed?
Company A and B agree to use TLS in order to protect communication. While it
is simple for A to create a policy that enforces TLS when they send to B,
there's no easy way for B to enforce TLS on their (inbound) side.
B may create a SMTP TLS-only listener on a dedicated port/ip and tell A to use
that. Alternatively, if the feature we are discussin at the moment, was in
place, they may as well create a policy that
a) requires TLS if A's IP/hostname is used by the client
b) requests the client to send its ccert
c) verifies the clients ccert fingerprint matches one put down in a map
This could all take place on a publicly referenced MX. Assuming both parties
agreed to enforce TLS it would be RFC compliant.
> What are we really gaining here? Note that active attackers on theThe gain is mutual authentication. At the moment the SMTP server has no means
to enforce TLS selectively on its default ip/port.
> network path can change any of the three inputs (client IP, clientCorrect me if I am wrong: Client-side DANE and/or ccert fingerprint matching
> name or client HELO name), so unless the client is using an MiTM
> resistant sending policy, we can't prevent MiTM attacks, rather
> we can only detect their absense in some cases and perhaps grant
> the client greater access.
would be apt to prevent MiTM attacks.
[*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
- << Previous post in topic Next post in topic >>