On 13 Oct 2015, at 22:18, Heiko Schlittermann <h...@schlittermann.de> wrote: > > Timo Sirainen <t...@iki.fi> (Di 13 Okt 2015 21:02:59 CEST): > … >>> On connection setup from a client the director connects to the >>> selected backend. But it seems (not checked in the source yet), >>> that for SSL certificate verification the director doesn't know the >>> original host name anymore. The certificate's CN gets compared to >>> the IP address the director connects to. >> >> Right. The hostnames are lost immediately at director startup. I've never >> really thought about needing this functionality for director, since they're >> usually in the same trusted network with backends.. >> > > That's it… "ususally". And additionally local policy says that we should use > secured connections whenever credentials are transported … And since the > director uses either a master password or the credentials obtained from > the client, we want to use secured connections. And using TLS w/o > verified certs is better than nothing, but it's far from being perfect.
I've been planning to add support for non-plaintext SASL for Dovecot proxy. Probably SCRAM-SHA1. That would avoid sending credentials in plaintext, although it wouldn't prevent other kind of MITM. > I see: > > a) pass the host *names* to the director too, for CN verification > purpose > > May be in struct mail_host could be a field for the original > hostname we used to obtain the adress(es)? Does the attached patch work? Compiles, but untested.
director-host.diff
Description: Binary data
