Sorry for the delay. Jakob - you’re a star! Thanks so much, your suggestion works. So I added </dev/null to now give: /path/to/openssl s_client -connect <host>:443 -servername <hostname> -tls1_3 sess_out </dev/null Actually, I also redirect stdin and stderr to a “log” file for debugging after the above but that’s not relevant here. I’m wondering if this would be something worthy of attention in openssl? I’ll document it on my blog in case anyone else comes across the same issue. Thanks everyone for your suggestions and time spent, really appreciated! 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, 14:52, "openssl-users on behalf of Jakob Bohm via openssl-users" <openssl-users-bounces@xxxxxxxxxxx on behalf of openssl-users@xxxxxxxxxxx> wrote: >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-bounces@xxxxxxxxxxx on behalf of matt@xxxxxxxxxxx> 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 ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
