On Fri, Jan 07, 2022 at 08:33:52AM -0500, PGNet Dev wrote: > Session Ticket RFC 5077 hint 7200 seconds, session tickets keys seems > to be rotated < daily
Keys are rotated as soon as possible, which is 2 * active lifetime. Initially the key is used to encrypt new tickets, later it is only used to decrypt previously issued tickets, and after that it is forgotten. So by default the key is gone after two hours. > ??? Session Resumption Tickets: yes, ID resumption test failed, > pls report Session ID resumption is by default disabled. This is a feature, let the client store a session ticket if it wants, otherwise it does a fresh handshake. This makes sense for SMTP. > OCSP stapling not offered > ??? OCSP must staple extension requires OCSP stapling (NOT ok) You made the mistake of using the "--must-staple" flag with certbot, or some equivalent way to elicit this certificate feature. Don't do that. Postfix has no CRL or OCSP support, and none is planned. > The other ??? item, > > "Session Resumption Tickets: yes, ID resumption test failed, > pls report" This is expected, nothing to worry about. > "[openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix > to Postfix test" > > https://mta.openssl.org/pipermail/openssl-project/2018-April/000671.html > > "The only interesting observations are: > > * With TLS 1.3 a new session is generated even sessions are > resumed, because the server responds with a new ticket > in the event of session resumption. With TLS 1.2 > sessions > that had sufficient remaining lifetime did not trigger > new > ticket generation on the server, and no new session was > stored on the client. This causes needless > wear-and-tear > on the external session cache in Postfix, since each > connection writes out a new session, replacing the one > it just used. Some might consider this a security > feature, > but it is not especially desirable with SMTP. Any > thoughts > about whether this could be tunable? It would have to > be > server-side tuning I think, since the client does not > know > why the server issued a new session, perhaps the old one > was not (or will soon not) be valid for re-use." Matt Caswell and I had a chat about this and session ticket issuance was made more configurable and backwards-compatible in a subsequent OpenSSL 1.1.1 release. OpenSSL 1.1.1<sufficiently-recent-patch-level> and later now honour the ticket callback signal to reuse the existing ticket. If you observe something else, let me know. Resumption with a previously obtained and still fresh ticket should not elicit yet another ticket. Unless "posttls-finger" fails to log the unwanted ticket this appears to still be working: $ posttls-finger -Lssl-debug,verbose -r3 -c amnesiac ... SSL_connect:SSL negotiation finished successfully SSL_connect:SSL negotiation finished successfully --> SSL_connect:SSLv3/TLS read server session ticket Reconnecting after 3 seconds amnesiac[192.0.2.1]:25: SNI hostname: amnesiac looking for session [192.0.2.1]:25&052C4F351BECBADDFB5D20D1494561BC746C8D59C314D298E46EEB183CB6021B in memory cache reloaded session [192.0.2.1]:25&052C4F351BECBADDFB5D20D1494561BC746C8D59C314D298E46EEB183CB6021B from memory cache SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:TLSv1.3 read encrypted extensions SSL_connect:SSLv3/TLS read finished SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished amnesiac[192.0.2.1]:25: Reusing old session Verified TLS connection established to amnesiac[192.0.2.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) Found a previously used server. Done reconnecting. ... There's no "read server session ticket" logged after resumption. -- Viktor.
