TLS communication director -> backend with X.509 cert checks?
Timo Sirainen
tss at iki.fi
Tue Oct 13 19:36:40 UTC 2015
On 13 Oct 2015, at 22:18, Heiko Schlittermann <hs at schlittermann.de> wrote:
>
> Timo Sirainen <tss at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: director-host.diff
Type: application/octet-stream
Size: 4143 bytes
Desc: not available
URL: <http://dovecot.org/pipermail/dovecot/attachments/20151013/1b1d227d/attachment-0001.obj>
-------------- next part --------------
More information about the dovecot
mailing list