From: Victor Duchovni (Victor.DuchovniMorganStanley.com)
Date: Wed Jun 01 2005 - 13:33:53 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Wed, Jun 01, 2005 at 06:36:12PM +0100, Richard Dawe wrote:

> > What I really would like to see standardize by the way (but have not
> > taken the time to propose properly) is my TLS client session key
> > generation trick that makes TLS session caching work for most
> > split-brain server caches (logical MX hosts with multiple IPs that
> > are physically separate hosts, or single IP addresses that map onto
> > multiple hosts via load-balancers).
>
> That sounds interesting. I'll take a look at the postfix sources.
>

Look at the 2.3 snapshot code. This has the final form of the client
cache id:

        address:port:EHLO_response_name

Early discussion took place on the Postfix-devel list... With 2.3 the
client peername is not in the cache id, peername verification happens
after sessions are established (even cached sessions). This allows the
cache to support servers with multiple personalities when AltSubjectName
is used to allow a single network endpoint to host multiple TLS identities.

The server certificate is does not depend on anything the client says,
because STARTTLS happens without the client telling the server who it
expects to talk to. So the server certificate depends only on the server.
The idea is to distinguish split-brain caches via their EHLO response:

        250-this.is.my.name
        250-...

The main thing I am looking for is for distinct servers that implement
TLS behind a load balancer or logical multi-homed host to respond
with different EHLO names. I also would like other MTAs to detect
this configuration and cache sessions accordingly.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majordomopostfix.org?body=unsubscribe%20postfix-users>

attached mail follows:

So today we have a cache indexed by the peername which loses with
split-brain servers (either multi-homed or behind laod balancers).

I proposed an end-point cache id (better for multi-homed and deals with
ports, but still loses for load-balancers).

We could instead have a

        peername:port/greeting-name

cache id. This will work with load balancers (when each host
responds with its real name), and does not penalize real
multi-homed hosts.

Comments?

--
        Viktor.

attached mail follows:

Victor Duchovni:
>
> So today we have a cache indexed by the peername which loses with
> split-brain servers (either multi-homed or behind laod balancers).

That's the SMTP client's cache with TLS sessions; in the current
design there can be only one cache entry per server hostname.

This loses when one server hostname resolves to multiple servers
when those servers don't share their TLS session caches.

> I proposed an end-point cache id (better for multi-homed and deals with
> ports, but still loses for load-balancers).

Indeed; this loses with multiple servers behind one IP address,
when those servers don't share their TLS session caches.

> We could instead have a
>
> peername:port/greeting-name
>
> cache id. This will work with load balancers (when each host
> responds with its real name), and does not penalize real
> multi-homed hosts.
>
> Comments?

Clever, except that the syntax is more complex than needed. Since
the fields that make up a client-side session cache ID have a fixed
order, one delimiter type (even white space) would get the job done.

        Wietse

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]