On Fri, Jan 16, 2015 at 06:34:33PM +0000, Phil Pennock wrote:
> > - coder/architect
> > -- builds, testcases, documentation
> > -- security review (coding, operational constraints, logging)
> > -- feature-incompatibility (proxy-protocol? TLS? X509 certs?)
> > -- coding standards
> > -- feature spinoffs (xcode string expansions?)
>
> This should just be incompatible with proxy protocol, but with a note
> that there's no _useful_ interaction with TLS, as you're only verifying
> the connection from the loadbalancer, not from the end-client, and
> XCLIENT does not support passing on attributes of the TLS session,
> not even that there is one. So this limits authentication restriction
> to TLS and makes it impossible for gsasl users to set up channel binding
> information (which, currently, is not a loss since the current channel
> binding data turns out to be a security hole resulting from TLS
> problems).
XCLIENT is not incompatible with end-to-end TLS. Many proxies are
just layer 4 load-balancers, and only engage in XCLIENT at the
start of the connection (while SMTP is still doing cleartext before
STARTTLS), allowing the original client to complete a TLS handshake
with the ultimate back-end server.
Some proxies may do TLS and even SASL auth with the client, in
which case the client authenticates and perhaps channel-binds the
proxy. The proxy can choose to open a second TLS channel to the
backend server, and perhaps authenticate it by some means.
If the TLS tunnel is the proxies, but SASL is with the backend
server, that can break GSSAPI channel binding. Which SMTP clients
support GSSAPI with TLS channel binding? I've not had time to
contemplate that for Postfix just yet.
--
Viktor.
