On Fri, Nov 14, 2014 at 05:20:14PM +0000, Viktor Dukhovni wrote:
> So gmail.com and postfix.org offer and actually reuses sessions, On the
> other hand, storing hotmail, AOL or Yahoo sessions is just a waste
> of I/O, since they are rarely if ever reusable.
>
> $ posttls-finger -c -r 2 -m 1 -lmay -Lsummary,cache hotmail.com
> posttls-finger: looking for session
> [207.46.8.199]:25&B3615E5BC0C51EF280EB79AC8C2D83BB5062B2BE73D21E5CD2AE6E5577D99934
> in memory cache
> posttls-finger: save session
> [207.46.8.199]:25&B3615E5BC0C51EF280EB79AC8C2D83BB5062B2BE73D21E5CD2AE6E5577D99934
> to memory cache
> posttls-finger: Reconnecting after 2 seconds
> posttls-finger: looking for session
> [207.46.8.199]:25&7364A28B331EC120944E55777F8A2AF16784CDC5840C1BA6EF5FE028C66F993E
> in memory cache
> posttls-finger: save session
> [207.46.8.199]:25&7364A28B331EC120944E55777F8A2AF16784CDC5840C1BA6EF5FE028C66F993E
> to memory cache
> posttls-finger: Untrusted TLS connection established to
> mx4.hotmail.com[207.46.8.199]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384
> (256/256 bits)
Note that the cache lookup key is different for the second connection.
To work with split caches for hosts behind load-balancers, Postfix
includes the server name from the remote EHLO response in the lookup
key, that way a small number of hosts behind a single IP address
each get their own cache entry.
This does not work very well when the load-balancer front-ends
hundreds or thousands of hosts, you almost rarely connect to
the same host again, while caching lots of discrete sessions.
The gmail "cloud" has a fixed EHLO server name:
posttls-finger: < 250-mx.google.com at your service
which works well with Postfix, because they have a unified session
cache with session tickets and shared keys across the cloud. While
consecutive hotmail connections (to the same IP) may yield:
posttls-finger: < 250-BAY004-MC2F21.hotmail.com (3.20.0.138) Hello
[192.0.2.1]
posttls-finger: < 250-BAY004-MC2F35.hotmail.com (3.20.0.138) Hello
[192.0.2.1]
which results in a different cache slot. I'd have to write new
code to determine whether suppressing the EHLO response session
lookup key "salt" would lead to better cache utilization for the
various large "cloud provider" domains.
Determining this dynamically, would require keeping some statistics
on cache re-use by IP, and switching from salted to unsalted to
off, if cache re-use is sufficiently poor. The code for that would
require some care. Not promising anything any time soon.
--
Viktor.
