SASL vs. TLS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

SASL vs. TLS

Tom Browder
For secure comm between my null client to my smtp server, do I need SASL if I use TLS for authentication also?

Thanks.

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

Re: SASL vs. TLS

Ralph Seichter
On 15.08.2017 14:13, Tom Browder wrote:

> For secure comm between my null client to my smtp server, do I need
> SASL if I use TLS for authentication also?

That's rather unspecific re what you are trying to accomplish and how
you have configured Postfix. http://www.postfix.org/TLS_README.html
should be a good starting point, and permit_tls_clientcerts might be
what you are looking for.

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

Re: SASL vs. TLS

Tom Browder
On Tue, Aug 15, 2017 at 07:25 Ralph Seichter <[hidden email]> wrote:
On 15.08.2017 14:13, Tom Browder wrote:

> For secure comm between my null client to my smtp server, do I need
> SASL if I use TLS for authentication also?

That's rather unspecific re what you are trying to accomplish and how
you have configured Postfix. http://www.postfix.org/TLS_README.html
should be a good starting point, and permit_tls_clientcerts might be
what you are looking for.

Hi, Ralph.

Specifically I want to: (1) use TLS for an encrypted SMTP connections from authorized relay clients, (2) use TLS client certs for the authentication of the relay clients, and (3) avoid use of SASL entirely.

Can I configure Postfix to achieve all three objectives?

Thanks.

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

Re: SASL vs. TLS

Marat Khalili
Hello Tom,

I'm also interested in this question.

On 15/08/17 15:55, Tom Browder wrote:
(2) use TLS client certs for the authentication of the relay clients, and
I see problem with this part. Nothing in docs says postfix uses or at least properly traces and logs client CNs from presented certificates. Therefore your system would resemble one-account-for-all configuration. Depending on requirements it might still work for you, but basically it'd be an open relay put into a TLS-protected network (which you can frankly organize even without postfix help).

--

With Best Regards,
Marat Khalili
Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Tom Browder
On Tue, Aug 15, 2017 at 08:28 Marat Khalili <[hidden email]> wrote:
Hello Tom,

I'm also interested in this question.

On 15/08/17 15:55, Tom Browder wrote:
(2) use TLS client certs for the authentication of the relay clients, and
I see problem with this part. Nothing in docs says postfix uses or at least properly traces and logs client CNs from presented certificates. Therefore your system would resemble one-account-for-all configuration. Depending on requirements it might still work for you, but basically it'd be an open relay put into a TLS-protected network (which you can frankly organize even without postfix help).

Hello, Marat,

I don't know about logging (but a good question), but I just now found this line in the "Postfix" book by Kyle Dent which says to me that the TLS-only authentication should be possible [p. 170, first sentence]: "You may want to use client-side certifiicates instead of, ..., other SMTP authentication tecniques."

With warmest regards,

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

Re: SASL vs. TLS

Ralph Seichter
In reply to this post by Tom Browder
On 15.08.2017 14:55, Tom Browder wrote:

> I want to: (1) use TLS for an encrypted SMTP connections from
> authorized relay clients, (2) use TLS client certs for the
> authentication of the relay clients, and (3) avoid use of
> SASL entirely.

In your master.cf, you can use something along these lines:

submission  inet  n  -  n  -  -  smtpd
 -o relay_clientcerts=hash:${config_directory}/relay_clientcerts
 -o smtpd_client_restrictions=permit_mynetworks,permit_tls_clientcerts,reject
 (...add more settings according to your needs...)

This will enable client-certificate based authentication for port 587,
with the file relay_clientcerts storing certificate fingerprint data.

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

Re: SASL vs. TLS

Michael Ströder
In reply to this post by Marat Khalili
Marat Khalili wrote:
> On 15/08/17 15:55, Tom Browder wrote:
>> (2) use TLS client certs for the authentication of the relay clients, and
>
> I see problem with this part. Nothing in docs says postfix uses or at least properly
> traces and logs client CNs from presented certificates. Therefore your system would
> resemble one-account-for-all configuration. Depending on requirements it might still
> work for you, but basically it'd be an open relay put into a TLS-protected network
> (which you can frankly organize even without postfix help).

IIRC I've implemented client authc based on cert fingerprint maps back in winter '99
(based on Lutz postfix-tls patches). So yes, it's feasible provided you issue personal
client certs to all your users.

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

Ciao, Michael.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Marat Khalili
> IIRC I've implemented client authc based on cert fingerprint maps back in winter '99
> (based on Lutz postfix-tls patches). So yes, it's feasible provided you issue personal
> client certs to all your users.
>
> http://www.postfix.org/postconf.5.html#relay_clientcerts
Thanks for pointing, missed this option. Then I retract my point, it
should possible to replace SASL with certs.

--

With Best Regards,
Marat Khalili

Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Tom Browder

On Tue, Aug 15, 2017 at 10:00 Marat Khalili <[hidden email]> wrote:
> IIRC I've implemented client authc based on cert fingerprint maps back in winter '99
> (based on Lutz postfix-tls patches). So yes, it's feasible provided you issue personal
> client certs to all your users.
>
> http://www.postfix.org/postconf.5.html#relay_clientcerts
Thanks for pointing, missed this option. Then I retract my point, it
should possible to replace SASL with certs.

Ah, thanks, Marat. That's what I intend to do. It will just be me alone from my personal hosts, so it won't be mush of a burden.

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

Re: SASL vs. TLS

Marat Khalili
I think your thanks should certainly go to Michael!

Please tell us how it went.

--

With Best Regards,
Marat Khalili

Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Tom Browder

On Tue, Aug 15, 2017 at 10:48 Marat Khalili <[hidden email]> wrote:
I think your thanks should certainly go to Michael!

You are correct!

Many thanks, Michael! I hope to use that TLS capability soon.




Please tell us how it went.

Definitele, and I'll probably have questions before it's complete.

Best,

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

Re: SASL vs. TLS

Michael Ströder
Tom Browder wrote:
> On Tue, Aug 15, 2017 at 10:48 Marat Khalili <[hidden email]> wrote:
>
>> I think your thanks should certainly go to Michael!
>
> You are correct!
>
> Many thanks, Michael! I hope to use that TLS capability soon.

You're welcome.

But credits go to Wietse, Viktor, Lutz, et al who have implemented all this in postfix.

Ciao, Michael.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Viktor Dukhovni
In reply to this post by Ralph Seichter
On Tue, Aug 15, 2017 at 04:33:28PM +0200, Ralph Seichter wrote:

> > I want to: (1) use TLS for an encrypted SMTP connections from
> > authorized relay clients, (2) use TLS client certs for the
> > authentication of the relay clients, and (3) avoid use of
> > SASL entirely.
>
> In your master.cf, you can use something along these lines:
>
> submission  inet  n  -  n  -  -  smtpd
>  -o relay_clientcerts=hash:${config_directory}/relay_clientcerts
>  -o smtpd_client_restrictions=permit_mynetworks,permit_tls_clientcerts,reject
>  (...add more settings according to your needs...)
>
> This will enable client-certificate based authentication for port 587,
> with the file relay_clientcerts storing certificate fingerprint data.

Don't forget to add:

    # To use client certs, we need to ask for them.
    #
    # Use "req_ccert" instead, if, and only if, all the client certs
    # are required to be issued by a trusted CA
    #
    -o smtpd_tls_ask_ccert=yes
    #
    # Set an explicit digest algorithm to match the actual algorithm
    # used to create the lookup keys in the relay_clientcerts table,
    # the legacy default of md5 is not recommended.
    #
    -o smtpd_tls_fingerprint_digest=sha256

to the list of override options for the submission service.

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

Re: SASL vs. TLS

Ralph Seichter
On 15.08.2017 18:27, Viktor Dukhovni wrote:

> Don't forget to add:
> -o smtpd_tls_ask_ccert=yes
> -o smtpd_tls_fingerprint_digest=sha256

Quite so, I had trimmed down my example configuration snippet too much.

Interestingly, http://www.postfix.org/postconf.5.html#smtpd_tls_fingerprint_digest
does not appear to mention SHA256 as a possible option? I'm still using
SHA1, because I thought this was, as of 2017-08, the best algorithm
available for smtpd_tls_fingerprint_digest.

-Ralph

Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Viktor Dukhovni
On Tue, Aug 15, 2017 at 06:57:26PM +0200, Ralph Seichter wrote:

> On 15.08.2017 18:27, Viktor Dukhovni wrote:
>
> > Don't forget to add:
> > -o smtpd_tls_ask_ccert=yes
> > -o smtpd_tls_fingerprint_digest=sha256
>
> Quite so, I had trimmed down my example configuration snippet too much.
>
> Interestingly, http://www.postfix.org/postconf.5.html#smtpd_tls_fingerprint_digest
> does not appear to mention SHA256 as a possible option?

The supported digest names/algorithms are a feature of the underlying
OpenSSL library, Postfix just passes the specified name to
EVP_get_digestbyname(3).

The Postfix documentation has not kept up with OpenSSL evolution.

> I'm still using SHA1, because I thought this was, as of 2017-08, the best
> algorithm available for smtpd_tls_fingerprint_digest.

In the absence of any realistic 2nd-preimage attacks on even MD5,
let alone SHA1, it is I believe still safe to use SHA1 as the
fingerprint digest.  However, use of SHA256 can reduce concerns
about surprising future developments.

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

Re: SASL vs. TLS

Ralph Seichter
On 15.08.2017 19:12, Viktor Dukhovni wrote:

> The supported digest names/algorithms are a feature of the underlying
> OpenSSL library, Postfix just passes the specified name to
> EVP_get_digestbyname(3).

Fair enough. It might be worth mentioning this in the Postfix docs.

> In the absence of any realistic 2nd-preimage attacks on even MD5,
> let alone SHA1, it is I believe still safe to use SHA1 as the
> fingerprint digest.

I agree, and I am not worried about SHA1 at this point. Still, if better
digests are available simply by configuring a different algorithm name
via smtpd_tls_fingerprint_digest, I'm all for using one of them.

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

Re: SASL vs. TLS

Viktor Dukhovni
On Tue, Aug 15, 2017 at 07:20:32PM +0200, Ralph Seichter wrote:

> On 15.08.2017 19:12, Viktor Dukhovni wrote:
>
> > The supported digest names/algorithms are a feature of the underlying
> > OpenSSL library, Postfix just passes the specified name to
> > EVP_get_digestbyname(3).
>
> Fair enough. It might be worth mentioning this in the Postfix docs.
>
> > In the absence of any realistic 2nd-preimage attacks on even MD5,
> > let alone SHA1, it is I believe still safe to use SHA1 as the
> > fingerprint digest.
>
> I agree, and I am not worried about SHA1 at this point. Still, if better
> digests are available simply by configuring a different algorithm name
> via smtpd_tls_fingerprint_digest, I'm all for using one of them.

Please review the documentation patch:

    https://github.com/vdukhovni/postfix/commit/7eb43e11987d9e7a9fd6fdb309726c3a19099a98

--
        Viktor.

commit 7eb43e11987d9e7a9fd6fdb309726c3a19099a98
Author: Viktor Dukhovni <[hidden email]>
Date:   Tue Aug 15 17:38:04 2017 +0000

    Update fingerprint digest documentation

diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto
index f8595a4e..7d6eeeb8 100644
--- a/postfix/proto/postconf.proto
+++ b/postfix/proto/postconf.proto
@@ -12191,17 +12191,16 @@ certificate (or public/private key-pair) that has the same fingerprint. </p>
 
 <p> The default algorithm is <b>md5</b>; this is consistent with
 the backwards compatible setting of the digest used to verify client
-certificates in the SMTP server. </p>
+certificates in the SMTP server. Any other digest algorithm supported
+by your OpenSSL library (and enabled via OpenSSL_add_ssl_algorithms())
+may be used instead. See the manpage for the OpenSSL "dgst" command for
+the list of implemented algorithms. </p>
 
-<p> The best practice algorithm is now <b>sha1</b>. Recent advances in hash
-function cryptanalysis have led to md5 being deprecated in favor of sha1.
-However, as long as there are no known "second pre-image" attacks
-against md5, its use in this context can still be considered safe.
-</p>
-
-<p> While additional digest algorithms are often available with OpenSSL's
-libcrypto, only those used by libssl in SSL cipher suites are available to
-Postfix. For now this means just md5 or sha1. </p>
+<p> Advances in hash function cryptanalysis have led to MD5 being
+deprecated in favor of SHA1 and more recently SHA2 (i.e. SHA224, SHA256,
+SHA384 and SHA512).  However, as long as there are no known "second
+pre-image" attacks against MD5, its use in this context can still be
+considered safe.  </p>
 
 <p> To find the fingerprint of a specific certificate file, with a
 specific digest algorithm, run:
@@ -12342,21 +12341,21 @@ configuration parameter.  See there for details. </p>
 %PARAM smtpd_tls_fingerprint_digest md5
 
 <p> The message digest algorithm to construct remote SMTP
-client-certificate
-fingerprints or public key fingerprints (Postfix 2.9 and later)
-for <b>check_ccert_access</b> and <b>permit_tls_clientcerts</b>. The
-default algorithm is <b>md5</b>, for backwards compatibility with Postfix
-releases prior to 2.5.  </p>
-
-<p> Advances in hash
-function cryptanalysis have led to md5 being deprecated in favor of sha1.
-However, as long as there are no known "second pre-image" attacks
-against md5, its use in this context can still be considered safe.
-</p>
-
-<p> While additional digest algorithms are often available with OpenSSL's
-libcrypto, only those used by libssl in SSL cipher suites are available to
-Postfix. </p>
+client-certificate fingerprints or public key fingerprints
+(Postfix 2.9 and later) for <b>check_ccert_access</b> and
+<b>permit_tls_clientcerts</b>. The default algorithm is <b>md5</b>,
+for backwards compatibility with Postfix releases prior to 2.5.  </p>
+
+<p> Any other digest algorithm supported by your OpenSSL library (and
+enabled via OpenSSL_add_ssl_algorithms()) may be used instead. See
+the manpage for the OpenSSL "dgst" command for the list of implemented
+algorithms. </p>
+
+<p> Advances in hash function cryptanalysis have led to MD5 being
+deprecated in favor of SHA1 and more recently SHA2 (i.e. SHA224, SHA256,
+SHA384 and SHA512).  However, as long as there are no known "second
+pre-image" attacks against MD5, its use in this context can still be
+considered safe.  </p>
 
 <p> To find the fingerprint of a specific certificate file, with a
 specific digest algorithm, run: </p>
Reply | Threaded
Open this post in threaded view
|

Re: SASL vs. TLS

Viktor Dukhovni
In reply to this post by Ralph Seichter
On Tue, Aug 15, 2017 at 07:20:32PM +0200, Ralph Seichter wrote:

> I agree, and I am not worried about SHA1 at this point. Still, if better
> digests are available simply by configuring a different algorithm name
> via smtpd_tls_fingerprint_digest, I'm all for using one of them.

The hardest part is making sure you still have a copy of all the
authorized public keys or certificates, so that you can compute a
new digest.  If all you have is the (say md5 or sha1) digest, then
it is not feasible to compute the corresponding sha256 digest.

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

Re: SASL vs. TLS

Ralph Seichter
On 15.08.2017 19:47, Viktor Dukhovni wrote:

> The hardest part is making sure you still have a copy of all the
> authorized public keys or certificates, so that you can compute a
> new digest.

I am dealing with approximately a dozen certificates, most of them for
server-to-server communication. Turns out that the small number of end
user certificates, which are used in addition to this dozen, will expire
in a few weeks anyway, and rolling out new certs will be an opportunity
to switch the digest algorithm.

-Ralph