presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Lars Kollstedt
Hello List,

is there a clean way to optionally present a client certificate to a Postfix
MX configured with

smtpd_tls_received_header=yes
smtpd_tls_ask_ccert = yes
smtpd_tls_CApath=/etc/ssl/certs

without breaking the use of TLS or even the mail delivery to MXes that are
verifying presented client certificates against a local CA, and rejecting
anything else.

I don't want to configure them all explicitly in /etc/postfix/transport.


My first idea was:
/etc/postfix/master.cf:
smtp_ccert      unix  -       -       y       -       -       smtp
        -o syslog_name=postfix/$service_name
        -o smtp_tls_cert_file=/etc/postfix/ssl/crt/server.crt
        -o smtp_tls_key_file=/etc/postfix/ssl/key/server.key

/etc/postfix/main.cf:
default_transport = smtp_ccert:
fallback_transport = smtp:

I worried a bit about penalty times in greylisting scenaries since I expected
this to retry to fast, and the greylisting daemon not to notice the difference
between the attempts with and without greylisting.

But postfix isn't even trying with the fallback transport in this case.
fallback_relay and smtp_fallback_relay shows the same behavior (isn't used).


The idea behind this is to have a fully verified transport trust chain within
the header when all postfix servers on the transport do this.

Any ideas?

Kind regards
        Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail:  [hidden email]

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der Gesellschaft: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert


Reply | Threaded
Open this post in threaded view
|

Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Ralph Seichter-2
* Lars Kollstedt:

> is there a clean way to optionally present a client certificate to a
> Postfix MX [...]

I hope I don't misinterpret your question here. When acting as an SMTP
client, Postfix should present the certificate you have defined via
smtp_tls_cert_file if the receiving Postfix (the SMTP server) uses
smtpd_tls_ask_ccert=yes. That matches your example settings.

However, I don't see you using relay_clientcerts=/path/to/clientcerts
anywhere. That would be required on the SMTP server side to actually
look up certificate fingerprints.

-Ralph
Reply | Threaded
Open this post in threaded view
|

Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Viktor Dukhovni
In reply to this post by Lars Kollstedt
On Fri, Nov 22, 2019 at 12:11:21PM +0100, Lars Kollstedt wrote:

> Is there a clean way to optionally present a client certificate to a
> Postfix MX without breaking the use of TLS or even the mail delivery
> to MXes that are verifying presented client certificates against a
> local CA, and rejecting anything else.

Have you recently seen MX hosts that solicit client certs and then abort
the TLS handshake when these don't verify?  The Postfix documentation
speculatively warns against promiscuous use of client certs:

    http://www.postfix.org/postconf.5.html#smtp_tls_cert_file

    Do not configure client certificates unless you must present client
    TLS certificates to one or more servers. Client certificates are not
    usually needed, and can cause problems in configurations that work
    well without them.

but the ecosystem may have improved since those words of caution were
written.

> I don't want to configure them all explicitly in /etc/postfix/transport.

You certainly can't blacklist all the bad sites, and so the right
answer is to whitelist only the sites to which you need to present
client certs.

> My first idea was:
> /etc/postfix/master.cf:
> smtp_ccert      unix  -       -       y       -       -       smtp
>         -o syslog_name=postfix/$service_name
>         -o smtp_tls_cert_file=/etc/postfix/ssl/crt/server.crt
>         -o smtp_tls_key_file=/etc/postfix/ssl/key/server.key
>
> /etc/postfix/main.cf:
> default_transport = smtp_ccert:
> fallback_transport = smtp:

You have failed to read the documentation of "fallback_transport".

    http://www.postfix.org/postconf.5.html#fallback_transport

    Optional message delivery transport that the local(8) delivery agent
    should use for names that are not found in the aliases(5) or UNIX
    password database.

It is NOT used on SMTP delivery (temporary) failure.

> But postfix isn't even trying with the fallback transport in this case.

As expected.

> The idea behind this is to have a fully verified transport trust chain within
> the header when all postfix servers on the transport do this.

There's no need to attempt to present your client certificate to random
strangers, even if they're bold enough to ask whether you're one of
their relations.

Postfix does not presently have support for a sort of inverse-SNI,
where a client certificate chain is selected via the tls policy table,
without a dedicated custom transport.  It is not clear this is needed.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Lars Kollstedt
In reply to this post by Ralph Seichter-2
Am Freitag, 22. November 2019, 23:08:39 CET schrieb Ralph Seichter:
> * Lars Kollstedt:
> > is there a clean way to optionally present a client certificate to a
> > Postfix MX [...]
>
> I hope I don't misinterpret your question here.
[...]
> However, I don't see you using relay_clientcerts=/path/to/clientcerts
> anywhere. That would be required on the SMTP server side to actually
> look up certificate fingerprints.


Hi Ralph,

at first thank you for the reply.

But I'm not talking about doing relay control via client certificates. This is
just a setup I know and I don't want to break, if someone does it on the same
host and port as his MX.

We've someone running

smtpd_tls_received_header=yes
smtpd_tls_ask_ccert = yes
smtpd_tls_CApath=/etc/ssl/certs

on his Postfix MX servers in our nearer environment, but I don't want to
maintain a list of all his domains to present the client certificate there.

But I understand the wish to also cryptographically verify this direction. So
I would like to make his servers logging the verification of the client
certificate "I've crypographically sure got the mail from that host."


At the moment it's a single MX server name on the other end but a bunch of
domains. And since the transport map is working on domain names prior of the
MX lookup (at least as far as I know) this is not an option.

Something mapping the transport method the after MX lookup was done would  
solve this, for my current usecase. With the single server configured this way
on the other end.


But it's of course not worth breaking the mail delivery or TLS to other mail
recipients where relay control is done this way on port 25 of the MX server,
in a way that causes problems if an unexpected client certificate is
presented.

So the question was if there is a clean way, to configure a client certficate
that is tried to present, and left away in case of failure. Unfortunately this
will need a second connection, when tried without the other side to signal
what kind of verification is done. And it's not possible to determine the
reason of failure, that's the reason of my worries about greylisting.

The more I'm thinking about this seems to be more a protocol extension for
future but anything that can be implemented by configuration - without
breaking anything, yet.

Kind regards,
        Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail:  [hidden email]

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der Gesellschaft: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert


Reply | Threaded
Open this post in threaded view
|

Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Viktor Dukhovni
On Sun, Nov 24, 2019 at 09:45:20PM +0100, Lars Kollstedt wrote:

> We've someone running
>
> smtpd_tls_received_header=yes
> smtpd_tls_ask_ccert = yes
> smtpd_tls_CApath=/etc/ssl/certs
>
> on his Postfix MX servers in our nearer environment, but I don't want
> to maintain a list of all his domains to present the client
> certificate there.
>
> But I understand the wish to also cryptographically verify this
> direction. So I would like to make his servers logging the
> verification of the client certificate "I've crypographically sure got
> the mail from that host."
>
> At the moment it's a single MX server name on the other end but a
> bunch of domains. And since the transport map is working on domain
> names prior of the MX lookup (at least as far as I know) this is not
> an option.

Humouring the curiousity of that particular receiving system is not
worth the complexity of attempting to keep track of the associated
domains, or presenting client certs to all strangers who ask and then
inventing a complex fallback scheme in case they fumble the resulting
handshake.

Your best bet is to simply not configure any client certs, you don't
need them to get the mail delivered.

Yes, Postfix could in principle have late binding of client certificates
by MX hostname (a dual to SNI-based certificate selection on the server).
It is not clear that there is sufficient merit in such a feature.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX

Lars Kollstedt
In reply to this post by Viktor Dukhovni
Hi Viktor,

at first thank you for your two answers. I decided to keep my reactions to
them in order but in all in this answer. ;-)

On Friday, 22. November 2019, 23:29:46 CET Viktor Dukhovni wrote:
> Have you recently seen MX hosts that solicit client certs and then abort
> the TLS handshake when these don't verify?
Not, yet. But stumbling into this when someone is running his MSA and MX on
the same host and port is something I want to avoid.

> The Postfix documentation
> speculatively warns against promiscuous use of client certs:
>
>     http://www.postfix.org/postconf.5.html#smtp_tls_cert_file
>
>     Do not configure client certificates unless you must present client
>     TLS certificates to one or more servers. Client certificates are not
>     usually needed, and can cause problems in configurations that work
>     well without them.
> but the ecosystem may have improved since those words of caution were
> written.
I know this warning. And I understand where it cames from. And what I did was
an attempt to work around this.

See this mailinglist post more as a test balloon for this. But there was not a
bunch of people answering this warning is deprecated, and I don't want to try.
;-)

[...]

> You have failed to read the documentation of "fallback_transport".
>
>     http://www.postfix.org/postconf.5.html#fallback_transport
>
>     Optional message delivery transport that the local(8) delivery agent
>     should use for names that are not found in the aliases(5) or UNIX
>     password database.
>
> It is NOT used on SMTP delivery (temporary) failure.
I've also read this description. The name duality of "default_transport" and
"fallback_transport" and some experiences with the fallback_transport that are
long ago, lead me to nevertheless try this. But obviously it's only a name
duality nowadays.
The two directives seem to have nothing to do with each other (anymore?).

>
> > But postfix isn't even trying with the fallback transport in this case.
> As expected.
As documented, see above. ;-) But I don't want to discuss about that. ;-)

Both answers my question, that far. ;-) :-)


> There's no need to attempt to present your client certificate to random
> strangers, even if they're bold enough to ask whether you're one of
> their relations.
We're in relation to the interesting target.
But I still don't want to maintain a list of all possible mail destination
domains. Mail delivery is controlled via MX records for good reasons there and
wildcards don't help.

>
> Postfix does not presently have support for a sort of inverse-SNI,
> where a client certificate chain is selected via the tls policy table,
> without a dedicated custom transport.
That's an answer. I don't need different certs but a way to turn this off and
on, after the MX lookup was done.

> It is not clear this is needed.
Needed is a big word for this. Especially since this would only partially fix
the usecase.

I was just evaluating the possibilities. And my interest was if I was
overlooking some extensions, solving this.

On Sunday, 24. November 2019, 22:55:51 CET Viktor Dukhovni wrote:
[...]
> Yes, Postfix could in principle have late binding of client certificates
> by MX hostname (a dual to SNI-based certificate selection on the server).
> It is not clear that there is sufficient merit in such a feature.
[...]
You were to fast with your answer. ;-) I was still typing on this one. I left
my previous answers to you in above.


The more I think about all this:

What I really would like to have is the recipient server to signal something
like an TLSMTAVERIFICATION ESMTP-keyword back to me and activating some client
certificates configured especially for that on my side. And they're verified
on the recipient server in different ways:
  1. If there are CAs for Relay-Control and special CAs they are verified
      first.
  2. if SMTP helo-Hostname and PTR-Hostname have DANE-TSA for _25._tcp.  
      records they must (both) match, if a certificate is presented that
      does'nt match (1.). Otherwise mail is deferred.
  3. There might be a bunch of manual filtering and signaling possibilities on
      the recipient server based on the trust, the CAs and the fingerprints.
      Not all of them are without side effects in all cases.
  4. Any other seen client certificate is verified against the configured
      system certificates and the result is logged to the header if
      "smtpd_tls_received_header=yes" is set.
  5. Since DANE is elder something else must be used to enforce the use of
      TLSMTAVERIFICATION if wanted.

But that's only a dream till now. And there are probably more urgend things to
do within the smtp transport. ;-)

For now I'll take this as a answer there is still no good way to do this, yet.

I'll wait which way all this will take in the next years.

[...]
> Your best bet is to simply not configure any client certs, you don't
> need them to get the mail delivered.
[...]
With the current state of implementation, yes.


Thank you for your answers. :-)

Many thanks for the time to read and answer this. ;-) :-)

Kind regards,
        Lars

--
Lars Kollstedt

Telefon: +49 6151 16-71027
E-Mail:  [hidden email]

man-da.de GmbH
Dolivostraße 11
64293 Darmstadt

Sitz der Gesellschaft: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert