Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
On Tue, Apr 24, 2018 at 10:21:28AM -0400, Viktor Dukhovni wrote: > > > > On Apr 24, 2018, at 9:29 AM, Benjamin Kadukwrote: > > > > To be clear, the current draft explicitly says "Servers SHOULD issue > > new tickets with every connection." This is not a MUST, but is > > perhaps strong enough guidance to merit overriding the existing > > ticket callback semantics. > > Fine advice for browsers, but not terribly useful for Postfix. > Multiple processes read and write the session cache in parallel, > and single-use tickets won't work without serialization and > multiple cache slots for the same destination. > > The Postfix SMTP server needs to be able to issue tickets only > as-needed on the server. The TLS 1.2 model works just fine for > SMTP and STEKs are already properly rotated. I'm not trying to say that Postfix or even SMTP in general needs to adopt the TLS 1.3 (Web) model; I'm only trying to consider the OpenSSL 1.1.1 library default, which I think ought to honor the SHOULD in the spec. > I think that the previous behaviour of the callback needs to > continue to apply, if the callback does not return re-issue, > no new ticket should be returned. The callback has access > to the SSL handle and can determine the protocol version > if it so chooses. and will not automatically update to TLS 1.3 semantics by default. But maybe that's okay. > The built-in ticket callback can always re-issue if that's > the preferred default. I think that is the preferred default, and would not object to implementing the default in the built-in ticket callback if you insist on Postfix not having to change its callback to get its preferred behavior. -Ben ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
On Mon, Apr 23, 2018 at 09:34:18PM -0400, Viktor Dukhovni wrote: > > > > On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni> > wrote: > > > > - Client-side diagnostics - > > On the server side I see that even when the ticket callback returns "0" to > accept and not re-issue the ticket, a new ticket is requested anyway. I'd > like to be able to control this, and not issue new tickets when the present > ticket is acceptable. If this requires new API entry points, I can condition > them on a suitable min library version. But ideally the callback return > value will be honoured, I don't yet see why we would not do that. To be clear, the current draft explicitly says "Servers SHOULD issue new tickets with every connection." This is not a MUST, but is perhaps strong enough guidance to merit overriding the existing ticket callback semantics. -Ben ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
> On Apr 22, 2018, at 9:49 PM, Viktor Dukhovni> wrote: > > - Client-side diagnostics - On the server side I see that even when the ticket callback returns "0" to accept and not re-issue the ticket, a new ticket is requested anyway. I'd like to be able to control this, and not issue new tickets when the present ticket is acceptable. If this requires new API entry points, I can condition them on a suitable min library version. But ideally the callback return value will be honoured, I don't yet see why we would not do that. - Server-side diagnostics - Initial session: SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:TLSv1.3 write encrypted extensions SSL_accept:SSLv3/TLS write certificate SSL_accept:TLSv1.3 write server certificate verify SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read finished >>> Callback log entry, create initial ticket: Issuing session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS write session ticket >>> Post-handshake SMTP server log entry: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) Resumed session: SSL_accept:before SSL initialization SSL_accept:before SSL initialization >>> Callback log entry, decrypting presented ticket: Decrypting session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS read client hello SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:TLSv1.3 write encrypted extensions SSL_accept:SSLv3/TLS write finished SSL_accept:TLSv1.3 early data SSL_accept:TLSv1.3 early data SSL_accept:SSLv3/TLS read finished >>> Callback asked to create a new ticket: Issuing session ticket, key expiration: 1524534619 SSL_accept:SSLv3/TLS write session ticket >>> Post-handshake application logging: Reusing old session (RFC 5077 session ticket) Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) - End - -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
I tested a Postfix server and client built against OpenSSL 1.1.0, using 1.1.1 run-time libraries. This exercised peer certificate fingerprint matching and session resumption. No major issues. 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. * Postfix logs a warning when the compile-time and runtime libraries are not exactly the same (once per process start), this is expected. Perhaps we should provide a means for users to turn that off. * The Postfix logging from the new session callback precedes the OpenSSL message callback that a session ticket was received from the server. It seems that the OpenSSL message callback happens at the completion of session ticket processing, but this results in slightly surprising ordering of the logs. It seems as though the session is stored before the ticket arrives. I think this "cosmetic" issue may be worth addressing. - Client-side diagnostics - posttls-finger: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.1.1 may not be compatible with OpenSSL 1.1.0 posttls-finger: SSL_connect:before SSL initialization posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read server certificate posttls-finger: SSL_connect:TLSv1.3 read server certificate verify posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache posttls-finger: SSL_connect:SSLv3/TLS read server session ticket posttls-finger: Reconnecting after 1 seconds posttls-finger: looking for session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D in memory cache posttls-finger: reloaded session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D from memory cache posttls-finger: SSL_connect:before SSL initialization posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS write client hello posttls-finger: SSL_connect:SSLv3/TLS read server hello posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions posttls-finger: SSL_connect:SSLv3/TLS read finished posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec posttls-finger: SSL_connect:SSLv3/TLS write finished posttls-finger: 127.0.0.1[127.0.0.1]:25: Reusing old session posttls-finger: Verified TLS connection established to 127.0.0.1[127.0.0.1]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: SSL_connect:SSL negotiation finished successfully posttls-finger: save session [127.0.0.1]:25&340DAEC7D4C243D38B19F31A405375B4DF69D1A1E5FB70B81C38E9EDC190976D to memory cache posttls-finger: SSL_connect:SSLv3/TLS read server session ticket - End - -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test
On 23/04/18 02:49, Viktor Dukhovni wrote: > > I tested a Postfix server and client built against OpenSSL 1.1.0, > using 1.1.1 run-time libraries. This exercised peer certificate > fingerprint matching and session resumption. No major issues. > > 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. Note that some servers may actually issue more than one ticket per connection. Notably boring issues 2 by default. I'm not sure if they enable configuration of that. In servers that accept early data we enforce single use tickets. In those scenarios it may make sense to have more than one ticket issued per connection. I do have a WIP PR for enabling configuration of the number of tickets to be sent on the server side: https://github.com/openssl/openssl/pull/5227 I have not been prioritising that at the moment because I have been focussing more on fixing defects. Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project