[openssl-users] Session params output fails via cron
jb-openssl at wisemo.com
Thu Jan 3 14:52:04 UTC 2019
On 03/01/2019 12:52, Neil Craig wrote:
> Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
> 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.
> 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-bounces at openssl.org on behalf of matt at 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.:
>>> 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
>> TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
>> session is established during the handshake. In TLSv1.3 the handshake
>> 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
>> 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
>> 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
>> 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.
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
More information about the openssl-users