Re: [exim-dev] [Bug 2266] TLS SNI should default set

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Viktor Dukhovni
Date:  
À: exim-dev
Sujet: Re: [exim-dev] [Bug 2266] TLS SNI should default set


> On Apr 20, 2018, at 7:07 PM, admin--- via Exim-dev <exim-dev@???> wrote:
>
> Because unless you have DNSSEC, $host is derived via insecure means, the DNS.
> DNSSEC means that DNS becomes secure for our purposes.
>
> If you have DNSSEC and want $host sent, then publish TLSA records to enable
> DANE, and the other tracking bug will cover our fixing Exim to honor those for
> selecting the SNI value to send.
>
> There is never any point in setting TLS SNI to a value which you are not
> willing to validate as being correct, referring back to a trusted path of
> input. If some people run self-signed without SNI but CA-signed with SNI, then
> that's a bug, but for MTAs delivering to MX it makes no difference because by
> default MX TLS *IS NOT VALIDATED*.
>
> So, no DNSSEC, need a value, needs to be tied back to the recipient in a
> trustworthy way, thus $domain is all we have to go on.
>
> It's not good. It's simply the least bad option available.


In Postfix we have a notion that is the "next-hop" domain,
which is normally the envelope recipient domain, but when
a smarthost (or domain whose MX records are used for routing)
is specified, then the next-hop domain is the smarthost.

This provides a "secure" name for TLS policy lookup, and is
not subject to insecure DNS downgrades. This is available
for peer name matching, and will also be available for
client-side SNI when I get that implemented (shortly).

Is there anything similar in Exim?

-- 
    Viktor.