Re: [exim] Force TLSv1.2 on EXIM server (4.80.1)

Pàgina inicial
Delete this message
Reply to this message
Autor: Viktor Dukhovni
Data:  
A: exim-users
Assumpte: Re: [exim] Force TLSv1.2 on EXIM server (4.80.1)
On Thu, Jul 30, 2015 at 12:55:37PM +0000, Viktor Dukhovni wrote:

> This is unwise, the majority of the ciphers used in TLS 1.2 are
> carried over from SSL 3.0, so you SHOULD NOT disable SSLv3 ciphers,
> rather just disabling the protocols suffices. And your cipherlist
> is unwise. For decent security and maximum interoperability try:
>
>     HIGH:MEDIUM:@STRENGTH:+RC4:!MD5:!SRP:!PSK:!aDSS:!kECDH:!kDH:!SEED:!IDEA:!RC2:!RC5

>


Forgot one thing. Postfix automatically excludes aNULL (aka ADH)
ciphers when peer authentication is required, but Exim probably
uses the same cipherlist throughout. So you may want to also
disable aNULL (or ADH if you like that name better) as your post
indicated.

If possible, I would leave aNULL enabled on the receiving side
(SMTP server), if the client is not checking your certificate
(willing do without) sending the certificate and doing signing
operations is mostly wasted effort. Whether you need to disable
aNULL on the sending side (SMTP client) is your call. If as with
most SMTP servers you don't enforce authentication for any peers,
soliciting certificates is of marginal value.

Some folks say that not signalling that you're not intending to
authenticate the server makes it easier for an active man-in-the-middle
attacker to select connections where the attacks won't be detected.
I don't think this makes much of a difference.

If you want MiTM protection, recent Exim versions support DANE
(still experimental?). While deployment is still very thin, it is
growing. If you decide to sign your DNS zones and publish TLSA
records, PLEASE PLEASE don't forget to update the TLSA records
before deploying new keys/certificates in the future.

    https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-8.1
    https://tools.ietf.org/html/draft-ietf-dane-ops-14#section-8.4
    https://dane.sys4.de/common_mistakes#3
    https://dane.sys4.de/common_mistakes


-- 
    Viktor.