Le 14/11/2014 18:47, Viktor Dukhovni a écrit :
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.
Hello Viktor,
Side questions about session cache.
If I have some postfix smtpd physical servers behind a load-balancer,
how could I setup them to be TLS client session cache friendly ?
- same EHLO
- same keys (and certificate ?).
- shared memcached session cache
and the same questions but to be session ticket friendly: no need of the
shared memcached, but for the other things ?
Emmanuel.
