Re: [openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to Postfix test

2018-04-28 Thread Benjamin Kaduk
On Tue, Apr 24, 2018 at 10:21:28AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 24, 2018, at 9:29 AM, Benjamin Kaduk  wrote:
> > 
> > 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

2018-04-24 Thread Benjamin Kaduk
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

2018-04-23 Thread Viktor Dukhovni


> 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

2018-04-23 Thread Viktor Dukhovni

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

2018-04-23 Thread Matt Caswell


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