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

On 14 Oct 2015, at 00:34, Heiko Schlittermann <hs at schlittermann.de>
wrote:
> 
> Hi Timo,
> 
> Heiko Schlittermann <hs at schlittermann.de> (Di 13 Okt 2015 22:33:23
CEST):
>>> Does the attached patch work? Compiles, but untested.
>> I'm about to test it.
> 
> It seems to update the struct mail_host, but it looks as if the data 
> in mail_host do not propagate down to login_proxy_new(). 
> 
> In other words, in login_proxy_new() set->host contains the IP address,
> correctly, because the director choose it, but where can I find the
> hostname there? And we need a way to pass the host*name* further, to the
> SSL verifcation step, don't we?
Proxying in general does check that hostname matches the SSL certificate,
because both the hostname and IP address are sent to login process. So it should
work in a way that host=<hostname> and hostip=<ip> is sent. I
thought my patch did that.. Normally auth_debug=yes would be enough to debug
this, but this happens between director and login process so I don't think
it's going to be of much use. login process's client_auth_parse_args()
is what should see these two parameters correctly.

I can check this further tomorrow.

Timo Sirainen <tss at iki.fi> (Di 13 Okt 2015 23:49:20 CEST):
?
> 
> Proxying in general does check that hostname matches the SSL certificate,
because both the hostname and IP address are sent to login process. So it should
work in a way that host=<hostname> and hostip=<ip> is sent. I
thought my patch did that.. Normally auth_debug=yes would be enough to debug
this, but this happens between director and login process so I don't think
it's going to be of much use. login process's client_auth_parse_args()
is what should see these two parameters correctly.
> 
> I can check this further tomorrow.
I've put an i_warning("*** %s: ...", __FUNCTION__, ...) into
several places.

Oct 14 00:02:33 director1 dovecot: director: Warning: *** login_host_callback:
OK#0112#011user=foo#011proxy#011ssl=yes#011nopassword=y#011lip=2001:x.y:f33::5:1#011lport=993#011pass=x#011proxy_refresh=450#011host=2001:x.y:f33::5:fe

Here it seems that the director doesn't send it's knowledge about the
hostname.

Here some other output, to show that the host list contains names and addresses:

Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add: added
backends.<domain> [2001:x.y:f33::5:fe]
Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add: added
backends.<domain> [2001:x.y:f33::5:ff]
Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add: added
backends.<domain> [149.x.y.103]
Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add: added
backends.<domain> [149.x.y.102]


-- 
Heiko
-------------- 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/20151014/1d0a9799/attachment.sig>

Heiko Schlittermann <hs at schlittermann.de> (Mi 14 Okt 2015 00:10:50
CEST):
> Timo Sirainen <tss at iki.fi> (Di 13 Okt 2015 23:49:20 CEST):
> ?
> > 
> > Proxying in general does check that hostname matches the SSL
certificate, because both the hostname and IP address are sent to login process.
So it should work in a way that host=<hostname> and hostip=<ip> is
sent. I thought my patch did that.. Normally auth_debug=yes would be enough to
debug this, but this happens between director and login process so I don't
think it's going to be of much use. login process's
client_auth_parse_args() is what should see these two parameters correctly.
> > 
> > I can check this further tomorrow.
> 
> I've put an i_warning("*** %s: ...", __FUNCTION__, ...) into
several places.
> 
> Oct 14 00:02:33 director1 dovecot: director: Warning: ***
login_host_callback:
OK#0112#011user=foo#011proxy#011ssl=yes#011nopassword=y#011lip=2001:x.y:f33::5:1#011lport=993#011pass=x#011proxy_refresh=450#011host=2001:x.y:f33::5:fe
> 
> Here it seems that the director doesn't send it's knowledge about
the
> hostname.
> 
> Here some other output, to show that the host list contains names and
addresses:
> 
> Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add:
added backends.<domain> [2001:x.y:f33::5:fe]
> Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add:
added backends.<domain> [2001:x.y:f33::5:ff]
> Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add:
added backends.<domain> [149.x.y.103]
> Oct 14 00:02:32 director1 dovecot: director: Warning: ** mail_host_add:
added backends.<domain> [149.x.y.102]
And if I add -D to the director service, I can see "Debug: request
<hash> refreshed timeout to ?",
but never I see "Debug: request <hash> added".  And from what I
understand this would be the place where the mail_host info comes into
the game. 

But probably I do not understand how director_request_continue() is
supposed to work.

    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/20151014/f19b68f0/attachment-0001.sig>