Mailing List Archive

Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list
Hello,

After having scanned 4.90.1 installation with OpenVAS, the below was
reported:

'Weak' cipher suites accepted by this service via the
TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA

Default settings (no explicit "tls_require_ciphers", "openssl_options")
are in use.

Can someone recommend simplest ciphers selection for Exim, to exclude
the mentioned cipher? The settings present on cipherli.st:

tls_require_ciphers = AES128+EECDH:AES128+EDH
openssl_options = +no_sslv2 +no_sslv3

seem kind of too strict, there were reported problems receiving email
after the above were put in effect.

Sincerely,
Konstantin

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
Am 28.03.2018 um 09:10 schrieb Konstantin Boyandin via Exim-users:
> Hello,
>
> After having scanned 4.90.1 installation with OpenVAS, the below was
> reported:
>
> 'Weak' cipher suites accepted by this service via the
> TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA
>
> Default settings (no explicit "tls_require_ciphers",
> "openssl_options") are in use.
>
> Can someone recommend simplest ciphers selection for Exim, to exclude
> the mentioned cipher? The settings present on cipherli.st:
>
> tls_require_ciphers = AES128+EECDH:AES128+EDH
> openssl_options = +no_sslv2 +no_sslv3
>
> seem kind of too strict, there were reported problems receiving email
> after the above were put in effect.
>
> Sincerely,
> Konstantin
>

in theorie:

If you disable sslv3 your doing the world a big favor, but
unfortunately, the world hates you for it.

in practis:

A "*******" of mailserver implementations worldwide still uses sslv3 to
connect to your mailserver.
Disabling it, removes your ability to get that email, which result in
all sorts of problems.

You can find a list of ciphers typically used here:

https://marius.bloggt-in-braunschweig.de/2017/05/30/haeufigkeit-von-tls-ciphern/

This statistics was made by analyzing our mailservercluster ( which has
also lead to
some f****** hilarious discoveries in crypto fails in germanies "secure"
goverment infrastructure . I could still LOL all the day :D )

As you can see from the list, a lot of connections are made with TLS
1.0, which has the same problems as sslv3
and should not be used. Even TLS 1.1 should not be used, but (again) a
lot of systems don't care.

If you rely on TLS 1.2 alone, your mailbox will stay empty most of the day.

General guideline :

First, make sure your server favors tls1.2 over any other protocol (
exim ensures it, so your good )
Second, make sure it favors a good cipher over weak ones. Use -LOW:-MID

"You can only be as secure, as the other part of the connection wants
you to be secure."

Whats a good cipher ?  Let others decide this, who know it better than
you and me ;)

https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet

Cipherlist : A+ => A => B => C => C-


best regards,
Marius



--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
Could I ask a possibly radical question of the list?

Firstly, I fully appreciate that a number of older encryption protocols and
ciphers are very weak. So *preferring* stronger ones over the weaker ones
has a clear benefit.

But given that most MTA to MTA traffic uses *opportunistic* encryption,
falling back to cleartext transfers if no encryption can be agreed between
the servers, isn't it better to continue to offer and use in such
situations a weak cipher than none at all? That is, weak encryption of a
message is better than none at all?

The exceptions being, of course, scenarios like:

- you require your incoming MTA to MTA traffic to arrive over an
encrypted connection and reject messages arriving in cleartext, or
- for MUA to MSA submissions as authentication credentials are usually
involved.

Cheers,
Mike B-)

On 28 March 2018 at 08:10, Konstantin Boyandin via Exim-users <
exim-users@exim.org> wrote:

> Hello,
>
> After having scanned 4.90.1 installation with OpenVAS, the below was
> reported:
>
> 'Weak' cipher suites accepted by this service via the
> TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA
>
> Default settings (no explicit "tls_require_ciphers", "openssl_options")
> are in use.
>
> Can someone recommend simplest ciphers selection for Exim, to exclude the
> mentioned cipher? The settings present on cipherli.st:
>
> tls_require_ciphers = AES128+EECDH:AES128+EDH
> openssl_options = +no_sslv2 +no_sslv3
>
> seem kind of too strict, there were reported problems receiving email
> after the above were put in effect.
>
> Sincerely,
> Konstantin
>
> --
> ## 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/
>



--
Systems Administrator & Change Manager
IT Services, University of York, Heslington, York YO10 5DD, UK
Tel: +44-(0)1904-323811

Web: www.york.ac.uk/it-services
Disclaimer: www.york.ac.uk/docs/disclaimer/email.htm
--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
Am 28.03.2018 um 11:21 schrieb Mike Brudenell via Exim-users:
> But given that most MTA to MTA traffic uses *opportunistic* encryption,
> falling back to cleartext transfers if no encryption can be agreed between
> the servers, isn't it better to continue to offer and use in such
> situations a weak cipher than none at all?

a) this would give a user the false impression, that "it was secured"
which with bad ciphers it isn't anymore.

b) it's getting even worse:

some mailservers even drop the TLS encrypted connection, if the hostname
in the DNS MX entry does not
match the servers presented certificates DN field, just to revert back
to cleartext transport to the exact same server.

sorry to say this, but the level of dumbness of devs implementing that
logic, isn't measureable anymore.

best regards,
marius

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
Begs the question, do DANE enabled machine therefore perhaps require a
stronger encryption - as their owners should know what they are doing?

I've no idea if its possible to allow weaker encryption for
opportunistic connections
but enforce stronger encryption types on DANE compliant connections?


On 28/03/2018 11:21, Mike Brudenell via Exim-users wrote:
> Could I ask a possibly radical question of the list?
>
> Firstly, I fully appreciate that a number of older encryption protocols and
> ciphers are very weak. So *preferring* stronger ones over the weaker ones
> has a clear benefit.
>
> But given that most MTA to MTA traffic uses *opportunistic* encryption,
> falling back to cleartext transfers if no encryption can be agreed between
> the servers, isn't it better to continue to offer and use in such
> situations a weak cipher than none at all? That is, weak encryption of a
> message is better than none at all?
>
> The exceptions being, of course, scenarios like:
>
> - you require your incoming MTA to MTA traffic to arrive over an
> encrypted connection and reject messages arriving in cleartext, or
> - for MUA to MSA submissions as authentication credentials are usually
> involved.
>
> Cheers,
> Mike B-)
>
> On 28 March 2018 at 08:10, Konstantin Boyandin via Exim-users <
> exim-users@exim.org> wrote:
>
>> Hello,
>>
>> After having scanned 4.90.1 installation with OpenVAS, the below was
>> reported:
>>
>> 'Weak' cipher suites accepted by this service via the
>> TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA
>>
>> Default settings (no explicit "tls_require_ciphers", "openssl_options")
>> are in use.
>>
>> Can someone recommend simplest ciphers selection for Exim, to exclude the
>> mentioned cipher? The settings present on cipherli.st:
>>
>> tls_require_ciphers = AES128+EECDH:AES128+EDH
>> openssl_options = +no_sslv2 +no_sslv3
>>
>> seem kind of too strict, there were reported problems receiving email
>> after the above were put in effect.
>>
>> Sincerely,
>> Konstantin
>>
>> --
>> ## 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/
>>
>
>

--
Mark James ELKINS - Posix Systems - (South) Africa
mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za


--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
On 28/03/18 10:21, Mike Brudenell via Exim-users wrote:> But given that
most MTA to MTA traffic uses *opportunistic* encryption,> falling back
to cleartext transfers if no encryption can be agreed between> the
servers, isn't it better to continue to offer and use in such>
situations a weak cipher than none at all? That is, weak encryption of
a> message is better than none at all?
Short-term yes. Long-term, no: people are supposed (hah!) to notice
that they are not getting TLS and fix the problem. We want the weak
(== too close to cleartext) methods to fall out of use.

There's a tension between the two answers; neither is perfect.
--
Cheers,
Jeremy

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
> On Mar 28, 2018, at 3:10 AM, Konstantin Boyandin via Exim-users <exim-users@exim.org> wrote:
>
> Can someone recommend simplest ciphers selection for Exim, to exclude the mentioned cipher? The settings present on cipherli.st:
>
> tls_require_ciphers = AES128+EECDH:AES128+EDH
> openssl_options = +no_sslv2 +no_sslv3
>
> seem kind of too strict, there were reported problems receiving email after the above were put in effect.

Per RFC7435, some security is better than none, and with opportunistic security one should should not be too strict in disabling weak ciphers. However, one should eventually disable weak ciphers which disappeared from use. Reducing the attack surface is also a worthy goal.

Therefor there are some deprecated ciphers that I recommend for removal to Postfix users.
These should also be suitable for removal in Exim.

MD5, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

To exclude these, your cipherlist would be:

DEFAULT:+RC4:!LOW:!EXPORT:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC6

You can probably also disable RC4 if you like, its use is rather negligible,
just a handful of Microsoft Exchange 2003 systems that most people never get
email from. For that, change "+RC4" (which moves it to the end of the list)
to "!RC4" (which disables it).

In Postfix I enable anonDH ciphers, for reasons in explained in:

https://tools.ietf.org/html/rfc7672#section-8.2

Security scanners tend to also warn you about that, so you'd need to be willing to ignore any such warnings. For that to be useful the anonymous ciphers would have to be preferred, and so the cipherlist becomes:

aNULL:-aNULL:ALL:+RC4:!LOW:!EXPORT:!MD5:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC6:@STRENGTH

Here the addition and removal of "aNULL" before including "ALL" moves the "aNULL"
ciphers to the front of the list, but @STRENGTH, does a stable sort by bit-stremgth,
so you get aNULL at the front of the list for each key length.

--
--
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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
On 2018-03-28 at 11:43 +0200, Mark Elkins via Exim-users wrote:
> Begs the question, do DANE enabled machine therefore perhaps require a
> stronger encryption - as their owners should know what they are doing?
>
> I've no idea if its possible to allow weaker encryption for
> opportunistic connections
> but enforce stronger encryption types on DANE compliant connections?

At present, it would require a bit of fiddling and logs-processing.

We have `$tls_out_dane` but the value is determined far too late to be
usable for setting `tls_require_ciphers` on the Transport.

We'd probably want some other variable, set as soon as we have DNS
signalling that DANE should be used, which can be referenced.
$smtp_found_dane or something? Note that DANE support is Experimental
and feedback and requests are a good thing (patches even better!).

If not willing to edit Exim's source, then at present I'd just make sure
that `log_selector` includes `+tls_certificate_verified` and look for
`CV=dane` in the logs. A logs processor could identify all domains
where that's seen, and things verified, and then update a DB of "domains
we should use better crypto for". It's hacky, but then it would be the
beginning of a lightweight reputation tracking system for outbound
connections.

-Phil

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
On 2018-03-28 at 21:11 -0400, Phil Pennock via Exim-users wrote:
> $smtp_found_dane or something? Note that DANE support is Experimental
> and feedback and requests are a good thing (patches even better!).

Uh ... DANE graduated from Experimental, I forgot. Sorry.

Am tentatively thinking that since so many other TLS-related Transport
options are ignored under DANE, and we don't require complicated
expansion rules, the cleanest and easiest would be to have a new option,
`dane_require_tls_ciphers`; if unset, `tls_require_ciphers` would be
used as the default, but if set and _IF_ DANE is in play, then this
cipherlist would be used instead.

I'll code up a strawman for consideration.

-Phil

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
On 28/03/18 10:43, Mark Elkins via Exim-users wrote:
> I've no idea if its possible to allow weaker encryption for
> opportunistic connections
> but enforce stronger encryption types on DANE compliant connections?

tls_required_ciphers on the smtp transport is expanded;
do a dnsdb lookup (or series) probing for the existence
of TLSA records, and tune the ciphers depending on that.

How complicated you want to make it depends on how
closely you want to emulate the actual DANE lookup sequence.
I'd not suggest worrying about the content of the
TLSA records, for example.

You'll be doubling the traffic to the resolver, if that's
a factor. I strongly suggest you should be running
a caching resolver locally, but YMMV.
--
Cheers,
Jeremy

--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
Hello Marius and everyone having responded.

Thanks, the pieces of advice taken and studied. Looks like I have,
indeed, to allow weaker ciphers for the time being and watch the mail
server for possible problems, otherwise I risk rejecting legitimate mail
sent from ancient mail servers.

Do I understand correctly, that *tls_require_ciphers accepts
OpenSSL-style list (the one also used by Apache and Dovecot), i.e.
something like

tls_require_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL

or I should use notation like TLS_RSA_WITH_SEED_CBC_SHA ?

Thanks for insights.

Sincerely,
Konstantin

On 28.03.2018 15:36, Cyborg via Exim-users wrote:
> Am 28.03.2018 um 09:10 schrieb Konstantin Boyandin via Exim-users:
>> After having scanned 4.90.1 installation with OpenVAS, the below was
>> reported:
>>
>> 'Weak' cipher suites accepted by this service via the
>> TLSv1.0/TLSv1.1/TLSv1.2 protocols: TLS_RSA_WITH_SEED_CBC_SHA
>>
>> Default settings (no explicit "tls_require_ciphers",
>> "openssl_options") are in use.
>>
>> Can someone recommend simplest ciphers selection for Exim, to exclude
>> the mentioned cipher? The settings present on cipherli.st:
>>
>> tls_require_ciphers = AES128+EECDH:AES128+EDH
>> openssl_options = +no_sslv2 +no_sslv3
>>
>> seem kind of too strict, there were reported problems receiving email
>> after the above were put in effect.
>
> in theorie:
>
> If you disable sslv3 your doing the world a big favor, but
> unfortunately, the world hates you for it.
>
> in practis:
>
> A "*******" of mailserver implementations worldwide still uses sslv3 to
> connect to your mailserver.
> Disabling it, removes your ability to get that email, which result in
> all sorts of problems.
>
> You can find a list of ciphers typically used here:
>
>
https://marius.bloggt-in-braunschweig.de/2017/05/30/haeufigkeit-von-tls-ciphern/
>
> This statistics was made by analyzing our mailservercluster ( which has
> also lead to
> some f****** hilarious discoveries in crypto fails in germanies "secure"
> goverment infrastructure . I could still LOL all the day :D )
>
> As you can see from the list, a lot of connections are made with TLS
> 1.0, which has the same problems as sslv3
> and should not be used. Even TLS 1.1 should not be used, but (again) a
> lot of systems don't care.
>
> If you rely on TLS 1.2 alone, your mailbox will stay empty most of the
day.
>
> General guideline :
>
> First, make sure your server favors tls1.2 over any other protocol (
> exim ensures it, so your good )
> Second, make sure it favors a good cipher over weak ones. Use -LOW:-MID
>
> "You can only be as secure, as the other part of the connection wants
> you to be secure."
>
> Whats a good cipher ?  Let others decide this, who know it better than
> you and me ;)
>
> https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet
>
> Cipherlist : A+ => A => B => C => C-
>
>
> best regards,
> Marius



--
## 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/
Re: Exclude TLS_RSA_WITH_SEED_CBC_SHA from cipher list [ In reply to ]
On 31/03/18 09:17, Konstantin Boyandin via Exim-users wrote:
> Do I understand correctly, that *tls_require_ciphers accepts
> OpenSSL-style list (the one also used by Apache and Dovecot), i.e.
> something like
>
> tls_require_ciphers = ALL:!LOW:!SSLv2:!EXP:!aNULL

Yes, if your exim is build with OpenSSL. For GnuTLS it
is different. Docs are at:

http://exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTreqciphssl

--
Cheers,
Jeremy

--
## 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/