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

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

or
    b) allow some kind of certificate pinning, that is loose the implied
       relation CN <=> hostname
> > Should I create certificates with IP address in SAN? (Any hint about
the
> > correct syntax for the openssl.conf is welcome). Or is there any
chance
> > that this is fixed already or will be fixed in the near future or even
> > better, that it's my fault?
> 
> I guess that could work for now. No idea about how to do such certificates.
I'll try that, but I think it's not a solution as soon as we reach out
for "official" certs. And because it puts more details about the
infrastructure into the configuration than would be necessary.

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20151013/6f845a4a/attachment.sig>

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

Timo Sirainen <tss at iki.fi> (Di 13 Okt 2015 21:36:40 CEST):
?
> > 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.
I'm about to test it.

    Best regards from Dresden/Germany
    Viele Gr??e aus Dresden
    Heiko Schlittermann
-- 
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -
 ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20151013/dd1fd0e3/attachment.sig>