TLS communication director -> backend with X.509 cert checks?

[Timo Sirainen]

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