Mailing List Archive

Ahoj,

D?a Sat, 18 Sep 2021 10:58:33 +0100 Sabahattin Gucukoglu via Exim-users
<exim-users@exim.org> napísal:

> Is there really a good reason? I do it chiefly because I like
> OpenSSL’s cipher selection (I want very permissive, ordered by
> @STRENGTH, and TLS 1.3 would be nice). There were also horror stories
> about RNG entropy starvation caused by GnuTLS.

AFAIK, there are (or was?) some license problems (incompatibility) with
OpenSSL and readline libraries.

regards

--
Slavko
http://slavino.sk

On 2021-09-18 Sabahattin Gucukoglu via Exim-users <exim-users@exim.org> wrote:
> Debian always builds Exim against GnuTLS, in its “heavy” variation,
> but I’ve always resisted by building against OpenSSL (and,
> incidentally, taken the time to tweak it for me). On the face of it
> that’s fine, except …

> Is there really a good reason? I do it chiefly because I like
> OpenSSL’s cipher selection (I want very permissive, ordered by
> @STRENGTH, and TLS 1.3 would be nice). There were also horror stories
> about RNG entropy starvation caused by GnuTLS.

> It’s tedious. I don’t put compilers on my server, and I don’t much
> enjoy setting up a build environment just to compile Exim against
> stable libraries and headers. It also makes upgrading much harder.
[...]

Hello,

imho exim linked against GnuTLS is perfectly adequate for a quiet
personal server. I have been using it for ages. FWIW I also do not
fiddle with TLS cipher selection on my server. GnuTLS defaults are
supposed to be sane, and its author know a lot more about encryption
than I do.

Debian links exim against GnuTLS mainly for historic reasons. OpenSSL's
license (pre 3.0.0) is gpl incompatible and at the point in time we
looked at it some of the libraries we wanted to link (indirectly)
against were GPL without OpenSSL-exception.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi Sabahattin,

On 18.09.21 11:58, Sabahattin Gucukoglu via Exim-users wrote:
> Is there really a good reason? I do it chiefly because I like OpenSSL’s cipher selection (I want very permissive, ordered by @STRENGTH, and TLS 1.3 would be nice). There were also horror stories about RNG entropy starvation caused by GnuTLS.

I run a bunch of low volume mail servers (some thousand mails/day) with Debian standard packages and it works well for me. Never had issues with entropy starvation (I run haveged on my servers
now, but even before I did not observe any issues like this). As of now, I believe you could achieve anything you want with the GnuTLS configuration as well (some selection features were
missing some time ago), I personally use the following cipher selection:

tls_require_ciphers = PFS:SECURE256:SECURE192:-3DES-CBC:-CURVE-SECP192R1:-CURVE-SECP224R1:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-NULL:+VERS-TLS1.3:-MD5:%SERVER_PRECEDENCE:%FORCE_ETM

in the Exim configuration file. I use testssl.sh (https://testssl.sh/) to verify my configuration (as there is nothing handy like the Qualys Test for HTTPS, IMHO). Test result for the above
cipher list is:

--cut
Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4

PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
ECDHE-RSA-AES128-GCM-SHA256
Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
Finite field group: ffdhe2048 ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192

Testing server preferences

Has server cipher order? yes (OK) -- TLS 1.3 and below
Negotiated protocol TLSv1.3
Negotiated cipher TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
Cipher order
TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES256-CCM AES128-GCM-SHA256 AES128-CCM
TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
--cut

The documentation on https://gnutls.org/manual/html_node/Priority-Strings.html is very good. There are much more (good) examples and defaults for OpenSSL cipher strings, however the general
approach is very similar. This blog entry was a good start https://blog.lighttpd.net/gnutls-priority-strings.html, but it is quite outdated today (unfortunately).

> I appreciate that this is borderline a Debian question, but since there are presumably experienced users of both libraries here, do you think Exim+GnuTLS is actually viable and that if I were to switch to the prebuilt binaries and adapt to GnuTLSisms it would be adequate for a quiet personal server?

Last time I thought about switching to a self build with OpenSSL was, when TLS1.3 was bleeding edge and not provided by the Debian packaged GnuTLS. Did'nt do it, because security patching in
time by the distros team is a big plus (I would not be able to do this in time and quality).

Besides this: About 85% of the incoming traffic is still unencrypted (for my statistics, mainly because some high volume mailing list servers do not use TLS), about 10% uses TLS1.3, 5% still
uses TLS1.2 (I log TLS ciphers via +tls_cipher in Exim).

hth,
Thomas

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Ahoj,

D?a Sat, 18 Sep 2021 18:25:07 +0200 exim-users--- via Exim-users
<exim-users@exim.org> napísal:

> tls_require_ciphers =
> PFS:SECURE256:SECURE192:-3DES-CBC:-CURVE-SECP192R1:-CURVE-SECP224R1:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-NULL:+VERS-TLS1.3:-MD5:%SERVER_PRECEDENCE:%FORCE_ETM

I have something similar, but i disabled too big DH too:

-GROUP-FFDHE6144:-GROUP-FFDHE8192

regards

--
Slavko
http://slavino.sk

On Sat, Sep 18, 2021 at 10:58:33AM +0100, Sabahattin Gucukoglu via Exim-users wrote:

> Is there really a good reason? I do it chiefly because I like
> OpenSSL’s cipher selection (I want very permissive, ordered by
> @STRENGTH, and TLS 1.3 would be nice). There were also horror stories
> about RNG entropy starvation caused by GnuTLS.

OpenSSL is a good choice for ensuring interoperable TLS support. GnuTLS
has had in the past its share of various quirks that have led to
unwanted or surprising behaviour. I used to hear it derided as "GunTLS"
(as in foot-gun).

That said, GnuTLS has been around for quite some time now, and likely
most of the kinks have been worked out.

You could reach out to the Debian community and see whether they're
willing to also provide an alternative pre-packaged Exim built against
OpenSSL.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, 18 Sep 2021, exim-users@thomas.freit.ag via Exim-users wrote:

> I use testssl.sh (https://testssl.sh/) to verify my configuration
> (as there is nothing handy like the Qualys Test for HTTPS, IMHO).

Hardenize https://www.hardenize.com/ is not bad.

> Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
>
> PFS is offered (OK) TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
> ECDHE-RSA-AES128-GCM-SHA256
> Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448
> Finite field group: ffdhe2048 ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192
>
> Testing server preferences
>
> Has server cipher order? yes (OK) -- TLS 1.3 and below
> Negotiated protocol TLSv1.3
> Negotiated cipher TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
> Cipher order
> TLSv1.2: ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES256-CCM AES128-GCM-SHA256 AES128-CCM
> TLSv1.3: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256

> Besides this: About 85% of the incoming traffic is still unencrypted
> (for my statistics, mainly because some high volume mailing list
> servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
> (I log TLS ciphers via +tls_cipher in Exim).

It looks as though you do not allow TLSv1.1 - I suspect that a
substantial faction of that 85% would use it if you allowed it.
For email it is probably better to allow TLSv1.1 than reject it
and end up receiving the message in plain.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Sat, Sep 18, 2021 at 09:45:28PM +0100, Andrew C Aitchison via Exim-users wrote:

> > Besides this: About 85% of the incoming traffic is still unencrypted
> > (for my statistics, mainly because some high volume mailing list
> > servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
> > (I log TLS ciphers via +tls_cipher in Exim).
>
> It looks as though you do not allow TLSv1.1 - I suspect that a
> substantial faction of that 85% would use it if you allowed it.
> For email it is probably better to allow TLSv1.1 than reject it
> and end up receiving the message in plain.

Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
support at least TLS 1.2 almost invariably only support TLS 1.0.

There's little to nothing particularly wrong with TLS 1.0 for SMTP, and
certainly nothing that's fixed in TLS 1.1, so if the floor isn't TLS 1.2
it should be 1.0 (I still recommend leaving it enabled for now).

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Viktor Dukhovni via Exim-users <exim-users@exim.org> writes:

> On Sat, Sep 18, 2021 at 09:45:28PM +0100, Andrew C Aitchison via
> Exim-users wrote:
>
>> > Besides this: About 85% of the incoming traffic is still unencrypted
>> > (for my statistics, mainly because some high volume mailing list
>> > servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
>> > (I log TLS ciphers via +tls_cipher in Exim).
>>
>> It looks as though you do not allow TLSv1.1 - I suspect that a
>> substantial faction of that 85% would use it if you allowed it.
>> For email it is probably better to allow TLSv1.1 than reject it
>> and end up receiving the message in plain.
>
> Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
> support at least TLS 1.2 almost invariably only support TLS 1.0.

FWIW, I have used standard Debian exim (heavy, with GnuTLS) for my
personal email server for a couple of years, and I don't recall any
TLS-related problem. FWIW, it seems TLS1.2 and TLS 1.3 is in wide use,
see statistics from the last couple of days on my server:

root@uggla:~# zgrep ' <= ' /var/log/exim4/mainlog*|grep -v ' P=local '|grep X=TLS1.0|wc -l
3
root@uggla:~# zgrep ' <= ' /var/log/exim4/mainlog*|grep -v ' P=local '|grep X=TLS1.1|wc -l
1
root@uggla:~# zgrep ' <= ' /var/log/exim4/mainlog*|grep -v ' P=local '|grep X=TLS1.2|wc -l
640
root@uggla:~# zgrep ' <= ' /var/log/exim4/mainlog*|grep -v ' P=local '|grep X=TLS1.3|wc -l
657
root@uggla:~# zgrep ' <= ' /var/log/exim4/mainlog*|grep -v ' P=local '|grep -v X=TLS|wc -l
46
root@uggla:~#

/Simon

Hi Andrew,

On 18.09.21 22:45, Andrew C Aitchison via Exim-users wrote:
>> I use testssl.sh (https://testssl.sh/) to verify my configuration
>> (as there is nothing handy like the Qualys Test for HTTPS, IMHO).
>
> Hardenize https://www.hardenize.com/ is not bad.

Yes, Hardenize is a good start, I like their holistic approach. Compared to the Qualys SSL test however,
the TLS information is not as detailed as it could be.

>> Testing robust (perfect) forward secrecy, (P)FS -- omitting Null Authentication/Encryption, 3DES, RC4
>>
>> PFS is offered (OK)          TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
>> ECDHE-RSA-AES128-GCM-SHA256
>> Elliptic curves offered:     prime256v1 secp384r1 secp521r1 X25519 X448
>> Finite field group:          ffdhe2048 ffdhe3072 ffdhe4096 ffdhe6144 ffdhe8192
>>
>> Testing server preferences
>>
>> Has server cipher order?     yes (OK) -- TLS 1.3 and below
>> Negotiated protocol          TLSv1.3
>> Negotiated cipher            TLS_AES_256_GCM_SHA384, 256 bit ECDH (P-256)
>> Cipher order
>>    TLSv1.2:   ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES256-CCM AES128-GCM-SHA256 AES128-CCM
>>    TLSv1.3:   TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
>
>> Besides this: About 85% of the incoming traffic is still unencrypted
>> (for my statistics, mainly because some high volume mailing list
>> servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
>> (I log TLS ciphers via +tls_cipher in Exim).

> It looks as though you do not allow TLSv1.1 - I suspect that a substantial faction of that 85% would use it if you allowed it.
> For email it is probably better to allow TLSv1.1 than reject it
> and end up receiving the message in plain.

TLS1.2+ is state of the art, I intentionally disabled anything below that. That unencrypted fraction is mainly
from LMKL, their host does not even try STARTTLS. Which is okay for a public mailing list server, imho.

Regards,
Thomas

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi,

On 18.09.21 23:14, Viktor Dukhovni via Exim-users wrote:
>>> Besides this: About 85% of the incoming traffic is still unencrypted
>>> (for my statistics, mainly because some high volume mailing list
>>> servers do not use TLS), about 10% uses TLS1.3, 5% still uses TLS1.2
>>> (I log TLS ciphers via +tls_cipher in Exim).

>> It looks as though you do not allow TLSv1.1 - I suspect that a
>> substantial faction of that 85% would use it if you allowed it.
>> For email it is probably better to allow TLSv1.1 than reject it
>> and end up receiving the message in plain.

> Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
> support at least TLS 1.2 almost invariably only support TLS 1.0.
>
> There's little to nothing particularly wrong with TLS 1.0 for SMTP, and
> certainly nothing that's fixed in TLS 1.1, so if the floor isn't TLS 1.2
> it should be 1.0 (I still recommend leaving it enabled for now).
>

TLS 1.0 and 1.1 have been deprecated for HTTPS (at least practically, since modern
browsers stopped supporting it last year and IETF formally deprecated 1.0 and 1.1 March
2021) and TLS 1.2 is out for more than 10 years. Any site, that does not support at
least TLS 1.2 is running absolutely outdated software. GnuTLS handshake errors are logged
very few times (<<1% of the messages), I suppose that enabling TLS1.1 and lower would not
increase encrypted connections very much.

Anyway: My main goal is to protect credentials of my users, if I would enable TLS1.1
and lower, I would risk that this communication is not secured adequately. Additionally,
I enforce encryption (TLS1.2+) on outgoing connections (only very few sites do not support
that, I maintain a list of exceptions, when I see mails lingering in the queue).

Most of the incoming traffic, which is not encrypted is from high volume open lists,
especially from LKML (vger.kernel.org which does not even try to use STARTTLS)...

Regards,
Thomas

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, Sep 20, 2021 at 12:12:02PM +0200, exim-users--- via Exim-users wrote:

> > There's little to nothing particularly wrong with TLS 1.0 for SMTP,
> > and certainly nothing that's fixed in TLS 1.1, so if the floor isn't
> > TLS 1.2 it should be 1.0 (I still recommend leaving it enabled for
> > now).
>
> TLS 1.0 and 1.1 have been deprecated for HTTPS (at least practically,
> since modern browsers stopped supporting it last year and IETF
> formally deprecated 1.0 and 1.1 March 2021) and TLS 1.2 is out for
> more than 10 years.

Yes, that's because the relevant attacks are browser-related. Hence
the /for SMTP/ qualification.

> Any site, that does not support at least TLS 1.2 is running absolutely
> outdated software. GnuTLS handshake errors are logged very few times
> (<<1% of the messages), I suppose that enabling TLS1.1 and lower would
> not increase encrypted connections very much.

Indeed, but my take is that some encryption is better than no
encryption, see <https://datatracker.ietf.org/doc/html/rfc7435>.

> Anyway: My main goal is to protect credentials of my users, if I would
> enable TLS1.1 and lower, I would risk that this communication is not
> secured adequately.

Indeed, that's why I would recommend a floor of TLS 1.2 for portss 587
and 465, but not necessarily port 25.

> Additionally, I enforce encryption (TLS1.2+) on outgoing connections
> (only very few sites do not support that, I maintain a list of
> exceptions, when I see mails lingering in the queue).

This is where our priorities differ. Barring a practical downgrade
attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
see little reason yet to force the remaining TLS 1.0 to use cleartext.
(Yes I'm aware of past cross-protocol attacks, see the author list of
DROWN: <https://drownattack.com/drown-attack-paper.pdf>)

On Sun, Sep 19, 2021 at 10:21:20AM +0200, Simon Josefsson via Exim-users wrote:

> > Make that TLS 1.0, almost nobody uses TLS 1.1, the sites that don't
> > support at least TLS 1.2 almost invariably only support TLS 1.0.
>
> FWIW, I have used standard Debian exim (heavy, with GnuTLS) for my
> personal email server for a couple of years, and I don't recall any
> TLS-related problem. FWIW, it seems TLS1.2 and TLS 1.3 is in wide
> use, see statistics from the last couple of days on my server:

Indeed TLS 1.0 is increasingly rare. The DANE survey finds the
below TLS version frequencies for MX hosts with DANE TLSA records:

TLSv1.3 21,177
TLSv1.2 3,180
TLSv1.0 12

But these are domains that showed some active interest in SMTP security,
by publishing DANE TLSA records. I'd expect the TLS 1.0 frequency among
general domains to be somewhat higher.

Anyway, your call of course. My take is that supporting TLS 1.0 does
not in any practical way reduce the security of email sent to sites that
support TLS 1.2 or 1.3. TLS version negotiation is downgrade resistant.
Downgrades would in any case require an active attack, and SMTP STARTTLS
does not defend against active attacks. Far easier to just strip
STARTTLS than to perform TLS version downgrades.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, 20 Sep 2021, Viktor Dukhovni via Exim-users wrote:
>On Mon, 20 Sep 2021 "Thomas" wrote:
>> Any site, that does not support at least TLS 1.2 is running absolutely
>> outdated software. GnuTLS handshake errors are logged very few times
>> (<<1% of the messages), I suppose that enabling TLS1.1 and lower would
>> not increase encrypted connections very much.
>
> Indeed, but my take is that some encryption is better than no
> encryption, see <https://datatracker.ietf.org/doc/html/rfc7435>.
>
>> Anyway: My main goal is to protect credentials of my users, if I would
>> enable TLS1.1 and lower, I would risk that this communication is not
>> secured adequately.
>
> Indeed, that's why I would recommend a floor of TLS 1.2 for portss 587
> and 465, but not necessarily port 25.
>
>> Additionally, I enforce encryption (TLS1.2+) on outgoing connections
>> (only very few sites do not support that, I maintain a list of
>> exceptions, when I see mails lingering in the queue).
>
> This is where our priorities differ. Barring a practical downgrade
> attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
> see little reason yet to force the remaining TLS 1.0 to use cleartext.
> (Yes I'm aware of past cross-protocol attacks, see the author list of
> DROWN: <https://drownattack.com/drown-attack-paper.pdf>)

> Anyway, your call of course. My take is that supporting TLS 1.0 does
> not in any practical way reduce the security of email sent to sites that
> support TLS 1.2 or 1.3. TLS version negotiation is downgrade resistant.
> Downgrades would in any case require an active attack, and SMTP STARTTLS
> does not defend against active attacks. Far easier to just strip
> STARTTLS than to perform TLS version downgrades.

DROWN makes me think it would be sensible not to use the same
certificate for SMTP with TLS 1.0 or 1.1 and any non-SMTP service
- particularly webmail.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

> On 20 Sep 2021, at 12:24 pm, Andrew C Aitchison via Exim-users <exim-users@exim.org> wrote:
>
> DROWN makes me think it would be sensible not to use the same certificate for SMTP with TLS 1.0 or 1.1
> and any non-SMTP service
> - particularly webmail.

Actually, don't share mail certificates with web certificates, regardless of the
TLS version (even 1.3). There are also application-layer cross protocol attacks
that can cause grief when an HTTP client is talking to an IMAP server, ...

But once you have a dedicated SMTP certificate, there's cause for concern only if
you ignore all the details, and draw the most conservative (dare I say paranoid)
conclusions.

The details matter. TLS 1.0 is not SSL2. It shares the same message structure
and version negotiation mechanisms with TLS 1.2. TLS 1.2 introduces negotiable
signature algorithms (both better and worse!) and a few other minor mostly
positive tweaks, but fundamentally the protocol remains unchanged from 1.0.

The fact that we're talking about opportunistic unauthenticated STARTTLS in
MTA-to-MTA SMTP means that active attacks are out of scope anyway. So TLS
1.0 is harmless, and you can leave it enabled and continue to receive encrypted
email form ~1% of long-tail systems. When that falls below 0.01%, I'll turn it
off. The current TLS 1.0 server population is not yet "negligible" for me, and
supporting these presents no known risk in SMTP.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Hi Victor,

on 20.09.21 17:43, Viktor Dukhovni via Exim-users wrote:
>> Anyway: My main goal is to protect credentials of my users, if I would
>> enable TLS1.1 and lower, I would risk that this communication is not
>> secured adequately.
>
> Indeed, that's why I would recommend a floor of TLS 1.2 for portss 587
> and 465, but not necessarily port 25.

That is reasonable, now I need to see how to configure that in exim.

>> Additionally, I enforce encryption (TLS1.2+) on outgoing connections
>> (only very few sites do not support that, I maintain a list of
>> exceptions, when I see mails lingering in the queue).
>
> This is where our priorities differ. Barring a practical downgrade
> attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
> see little reason yet to force the remaining TLS 1.0 to use cleartext.
> (Yes I'm aware of past cross-protocol attacks, see the author list of
> DROWN: <https://drownattack.com/drown-attack-paper.pdf>)

Kudos, real nice paper. I definitely got your point. Just for information:
All hosts on my exception list do not support encryption at all (the
list is so short, that I can test the hosts before adding them).

Anyway, as you wrote in another mail, main attack would be stripping STARTTLS
before the connection is encrypted. I currently see no real widely used extension
to address that. TLSA records and DANE are not implemented widely, MTA-STS
probably even less wide.

Nonetheless, interesting thread with a lot points to rething and improve, thanks Victor.

Regards,
Thomas

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Mon, Sep 20, 2021 at 09:13:11PM +0200, exim-users--- via Exim-users wrote:

> > This is where our priorities differ. Barring a practical downgrade
> > attack on SMTP STARTTLS made possible by keeping TLS 1.0 enabled, I
> > see little reason yet to force the remaining TLS 1.0 to use cleartext.
> > (Yes I'm aware of past cross-protocol attacks, see the author list of
> > DROWN: <https://drownattack.com/drown-attack-paper.pdf>)
>
> Kudos, real nice paper.

For the record, my contribution was small, I observed that the
RC4 part of the attack was substantially more effective in the
presence of another bug, that was fixed less than a year back
at the time, and likely not universally deployed.

The real hard work was by Nimrod Aviram and others. So not claim
credit, so much as note that I'm familiar with the existence of
potential cross-protocol issues.

> Anyway, as you wrote in another mail, main attack would be stripping STARTTLS
> before the connection is encrypted. I currently see no real widely used extension
> to address that. TLSA records and DANE are not implemented widely, MTA-STS
> probably even less wide.

DANE is yet at "widely used" but adoption of both DNSSEC and DANE is
growing steadily.

https://stats.dnssec-tools.org/

MTA-STS is pretty much just Google. Well also mail.ru and comcast.net
(who also do DANE).

If you care about SMTP transport security, do DANE, but make sure you
implement monitoring and a robust key rollover process. Just turning
DANE on and neglecting it does nobody any good.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On 9/20/21 13:11, Viktor Dukhovni via Exim-users wrote:
> If you care about SMTP transport security, do DANE, but make sure you
> implement monitoring and a robust key rollover process. Just turning
> DANE on and neglecting it does nobody any good.

May be worth mentioning - Comcast will send TLS-RPT reports that include DANE information, and
hopefully others follow. Given Microsoft already sends TLS-RPT reports hopefully they do too when
they roll out DANE for outbound mail "this year" [1].

Of course don't rely on third parties exclusively for your monitoring, especially not if they can't
send you mail when things go down, but it may be helpful to configure.

Matt

[1] https://www.microsoft.com/en-us/microsoft-365/roadmap?filters=&searchterms=dnssec

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Interesting discussion ... I am in a slightly different place on our
three public mail servers that handle circa 200,000 mails per day for
about 20-30 domains.

1. I use Devuan 3.1 (Beowulf) and compile Exim from source with OpenSSL
rather than GnuTLS.  NB. No systemd here to fek with things!

2. For maximum compatibility I use a relatively permissive cipher list
and RSA-4096 for incoming connections as Microsoft Outlook servers
refused to talk to Exim with ECC certificates, hence this:

    #
    # Logging options
    #
    log_selector = +subject +tls_cipher +tls_peerdn

    #
    # Enable TLS with strong ciphers
    #
    MAIN_TLS_ENABLE = true

    #
    # OpenSSL options
    #
    openssl_options = -all +no_sslv2 +no_sslv3 +no_compression
+cipher_server_preference

    #
    # RSA 4096-bit certificate so that Microsoft can talk to us.... doh!
    #
    tls_certificate = /etc/ssl/thorcom/RSA/_star_.thorcom.net-bundle.crt
    tls_privatekey = /etc/ssl/thorcom/RSA/_star_.thorcom.net.key
    tls_dhparam = /etc/ssl/thorcom/RSA/dhparam.pem

    # ensure we tell everyone that we do TLS
    tls_advertise_hosts = *

    #
    # Better list of ciphers post debate on Exim mailing list
    #
    tls_require_ciphers = ALL:!LOW:!aDSS:!aNULL:!SSLv2:!PSK:!SRP:@STRENGTH

    # advertise auth to TLS sessions only
    auth_advertise_hosts = ${if eq {$tls_in_cipher}{}{}{*}}

on the basis that its better to receive email (with any encryption)
rather than have it delivered in the clear or not delivered at all...

I assume that my important customers (that require strong encryption
while sending to me) will step up to the mark and will initiate the use
of a decent cipher suite (there is nothing that prevents this).


3. For outgoing email I have to transports:

One called 'remote_smtp_force_tls' and one called 'remote_smtp'.

The first transport is called for important customers (based on a MySQL
query on the destination domain) where they expect (require) encryption
with a minimum strength or a failure to send - think government and
other agencies.  It looks like this:

    #
    # This transport is used for delivering messages over SMTP connections
    # where TLS is mandatory (forced) with high cipher strength. NB. this
    # transport is selected based on the destination domain, so the
hosts that
    # at this point the host(s) that require TLS are 'any' (wildcard)
because we
    # don't care who we're talking to it must use TLS.
    #
    remote_smtp_force_tls:
      driver = smtp
      hosts_require_tls = *
      tls_require_ciphers =
HIGH:!SRP:!PSK:!CHACHA20:!ARIA:!CAMELLIA128:!SHA:@STRENGTH


The other (not important) domains go out over the normal 'remote_smtp'
transport and use optimistic SSL/TLS but they are allowed to fall back
to plain.


Mike


On 18/09/2021 10:58, Sabahattin Gucukoglu via Exim-users wrote:
> Debian always builds Exim against GnuTLS, in its “heavy” variation, but I’ve always resisted by building against OpenSSL (and, incidentally, taken the time to tweak it for me). On the face of it that’s fine, except …
>
> Is there really a good reason? I do it chiefly because I like OpenSSL’s cipher selection (I want very permissive, ordered by @STRENGTH, and TLS 1.3 would be nice). There were also horror stories about RNG entropy starvation caused by GnuTLS.
>
> It’s tedious. I don’t put compilers on my server, and I don’t much enjoy setting up a build environment just to compile Exim against stable libraries and headers. It also makes upgrading much harder.
>
> I appreciate that this is borderline a Debian question, but since there are presumably experienced users of both libraries here, do you think Exim+GnuTLS is actually viable and that if I were to switch to the prebuilt binaries and adapt to GnuTLSisms it would be adequate for a quiet personal server?
>
> Cheers,
> Sabahattin
>
>


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Looks like I will be spending some more quality time with GnuTLS docs as I do seem to have been giving it a hard time. Most interesting so far is the discovery that the ciphersuite selection lets you specify not just the suites, but also the negotiated protocol version. It’s not as convenient, but it’s possible. Perhaps it grows on you, like GnuPG? It’s very comprehensive.

The interoperability issues that plagued GnuTLS in the past: I recall that they were particularly noticeable with mobile clients using Symbian. The earliest device I own runs Windows CE 6, with TLS 1.0 RC4 SHA1. I don’t suppose I’ll be letting it talk to my server again. All the clients I use now are modern Apple clients.

Courier Mail Server fetches MTA-STS policy documents. I’d consider this a good reason to do MTA-STS as well as DANE, even though I suspect the base of Courier users will be small. Interesting too is that Debian compiles their couriertls against GnuTLS (but I won’t be using that).

Thank you very much to everyone who responded. Very helpful and interesting discussion with lots of useful information. Much appreciated.

Cheers,
Sabahattin


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

> On 30 Sep 2021, at 6:32 pm, Sabahattin Gucukoglu via Exim-users <exim-users@exim.org> wrote:
>
> Courier Mail Server fetches MTA-STS policy documents. I’d consider this a good reason to do MTA-STS as well as DANE, even though I suspect the base of Courier users will be small. Interesting too is that Debian compiles their couriertls against GnuTLS (but I won’t be using that).

The primary use-case for MTA-STS at present is gmail.com, otherwise
it is basically unused. I am not a fan of propping up Google's walled
garden, so generally discourage its adoption. Below is a response to
the USG's call for public comment on an architecture that includes MTA-STS:

https://www.isi.edu/~hardaker/news/2021-09-20-DANE-vs-STS.html

--
Viktor.


--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/