On 03/01/2019 12:52, Neil Craig wrote:
Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
sadly.
If anyone has any further suggestions, I¹d appreciate it very much as this
is in aid of our automated released testing for TLS1.3 on our production
traffic management service.
Cheers
Neil Craig
Lead Technical Architect | Online Technology Group
Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org
On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell"
<openssl-users-boun...@openssl.org on behalf of m...@openssl.org> wrote:
On 03/01/2019 10:31, Neil Craig wrote:
Hi all
Does anyone know why openssl (silently) fails to write session data to
a file
when run from cron? (It works fine running manually) via e.g.:
/path/to/openssl
s_client -connect <host>:443 -servername <hostname> -tls1_3 sess_out
Running the same command but with tls1_2 works fine from cron. This
feels like
it might be a bug? Or am I missing something? There¹s nothing obvious
in the
output that suggests failure.
Any help would be much appreciated, happy to provide more info and/or
do more
testing.
TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
TLSv1.2
session is established during the handshake. In TLSv1.3 the handshake
completes
first. At that point data can be exchanged. At some later point (usually
immediately after the handshake has completed) the server may send to the
client
new session ticket messages to create a session for later resumption.
When s_client is run non-interactively it will connect to the server and
complete the handshake. It will then read any data from stdin and send it
to the
server. It will keep doing this until it hits EOF from stdin and then
close the
connection.
My guess is that s_client is closing the connection before the server has
had a
chance to send its new session tickets.
You might want to experiment with the -ign_eof option to s_client. This
will
keep s_client running even after having hit EOF from stdin.
Maybe cron jobs are run without a valid stdin handle (rather than a
readable handle at EOF), in which case explicitly adding "</dev/null"
may be a fix.
Or maybe there is a bug in how the new TLS1.3 code handles the
-ign_eof option early in the connection, here again testing with
"</dev/null" may help figuring out what is happening.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
