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

[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

Re: [openssl-project] Entropy seeding the DRBG

[Paul Dale]

I can possibly provide some input having done similar for a number of platforms 
and written faster but equivalent entropy assessment code to NIST's (for the 
second draft of SP 800-90B rather than the final version).

I'm not knowledgeable about VMS though.

We could discuss further at ICMC if you're in the area.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Tuesday, 24 April 2018 5:46 AM
To: openssl-project@openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG

On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all 
> kinds of data that you can get out from the VMS kernel, most notably 
> through a system service called sys$getrmi()...  there's a gazillion 
> data points, a treasure trove for anyone that's into statistics.  And 
> I intend to spend some time trying to estimate what kind of entropy I 
> can get out of them...
> 
> ... and that's where Kurt came in:
> 
> > Can I suggest you try something like 
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least 
> > get an idea? You would need to sample 1 variable and feed that into 
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of 
> bits from a source and feed that to the assessment program.  As long 
> as I don't have to port a C++11 program to VMS, 'cause unfortunately, 
> the existing C++ compiler hasn't had a real update for quite a while 
> :-/ (I'm sure that VSI is quite busy updating all they can, but they 
> haven't let anything out yet)
> 
> But either way, creating a better entropy gatherer is the longer term 
> goal.  I hope I get that part done before the release.

Any update on this?


Kurt

___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Re: [openssl-project] Entropy seeding the DRBG

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
> In the mean time, I've spent a few days going through the docs on all
> kinds of data that you can get out from the VMS kernel, most notably
> through a system service called sys$getrmi()...  there's a gazillion
> data points, a treasure trove for anyone that's into statistics.  And
> I intend to spend some time trying to estimate what kind of entropy I
> can get out of them...
> 
> ... and that's where Kurt came in:
> 
> > Can I suggest you try something like
> > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
> > get an idea? You would need to sample 1 variable and feed that into
> > it.
> 
> And yeah, sure, especially if all it takes is to produce a stream of
> bits from a source and feed that to the assessment program.  As long
> as I don't have to port a C++11 program to VMS, 'cause unfortunately,
> the existing C++ compiler hasn't had a real update for quite a while
> :-/ (I'm sure that VSI is quite busy updating all they can, but they
> haven't let anything out yet)
> 
> But either way, creating a better entropy gatherer is the longer term
> goal.  I hope I get that part done before the release.

Any update on this?


Kurt

___
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

[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

[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

Re: [openssl-project] When to enable TLS 1.3

[Richard Levitte]

In message <431270c5-3da3-4a9d-9292-12adc46cc...@dukhovni.org> on Sat, 21 Apr 
2018 14:45:34 -0400, Viktor Dukhovni  said:

openssl-users> > We are considering if we should enable TLS 1.3 by default or 
not,
openssl-users> > or when it should be enabled. For that, we would like to know 
how
openssl-users> > applications behave with the current version.
openssl-users> 
openssl-users> It is perhaps unclear in the last sentence what "the current 
version"
openssl-users> means.

I took that to mean "the 1.1.0 series"

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project