Re: [openssl-users] Session params output fails via cron
Actually, my apologies, I missed -ign_eof - that is also needed, so the “fixed” request is: /path/to/openssl s_client -connect :443 -servername -tls1_3 sess_out -ign_eof https://twitter.com/tdp_org On 04/01/2019, 10:58, "Neil Craig" wrote: >Sorry for the delay. > >Jakob - you’re a star! Thanks so much, your suggestion works. So I added > > >/path/to/openssl s_client -connect :443 -servername >-tls1_3 sess_out > >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@openssl.org> 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" >>> >>>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 :443 -servername -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 ">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 >>"> >>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
Re: [openssl-users] Session params output fails via cron
Sorry for the delay. Jakob - you’re a star! Thanks so much, your suggestion works. So I added :443 -servername -tls1_3 sess_out https://twitter.com/tdp_org On 03/01/2019, 14:52, "openssl-users on behalf of Jakob Bohm via openssl-users" 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" >> 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 :443 -servername -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 "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 >" >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
Re: [openssl-users] Session params output fails via cron
I am, yes. And as I say, it works fine interactively, it¹s just via cron that it fails. 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:56, "openssl-users on behalf of Matt Caswell" 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 :443 -servername -tls1_3 sess_out > >I assume you are actually supplying a filename after the "-sess_out" >flag, right? > >Matt > >-- >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
Re: [openssl-users] Session params output fails via cron
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" 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 :443 -servername -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. > >Matt > >-- >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
[openssl-users] Session params output fails via cron
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 :443 -servername -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. Cheers Neil Craig Lead Technical Architect | Online Technology Group [cid:2EBC98B1-F146-4192-B967-20E7C30AA8C0] Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org 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
Re: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1
Thanks very much Matt. I have indeed built with NGINX configure opt --with-openssl-opt=enable-weak-ssl-cipher and whilst I don¹t see an error when running NGINX with a/some 3DES cipher(s) in the ciphers list, I don¹t see any 3DES ciphers in the output of e.g. Testssl and I can¹t make a connection to the server using openssl CLI with -cipher <3DES cipher>. I wonder if the problem might be either NGINX not respecting/processing the configure opt (above) or possibly removing 3DES ciphers for some reason with openssl 1.1.1. I¹ll keep digging, thanks again for your help and for confirming that¹s the right thing to do. Cheers Neil Craig Lead Technical Architect | Online Technology Group Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org On 17/09/2018, 17:41, "openssl-users on behalf of Matt Caswell" wrote: > > >On 17/09/18 16:29, Neil Craig wrote: >> Hi all >> >> I'm trying to re-add 3DES support (a temporary move, due to business >> requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX >> build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt >> from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. >> >> Whilst I do see some older ciphersuites being offered by NGINX after >> doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was >> expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but >> that didn¹t work. I have also tried adding @seclevel=0 to the >> ciphersuite string in NGINX but again, that didn¹t work, I don¹t see any >> 3DES ciphersuites available in NGINX. >> >> I'm wondering whether something changed between the above article and >> the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was >> completely removed in OpenSSL 1.1.1). >> >> Any pointers would be very much appreciated, I can¹t find anything very >> useful on the web. > >3DES is still available in 1.1.1 but is no longer in the DEFAULT >ciphersuite list, so unless you explicitly configure them to be >available you won't see them (even if you configure with >enable-weak-ssl-ciphers). > >E.g. (assuming you compiled with enable-weak-ssl-ciphers): > > >$ openssl ciphers -v | grep 3DES > >Will give you 0 ciphers, but > >$ openssl ciphers -v 3DES | grep 3DES > >Should list 14 different 3DES ciphersuites that are available. > >I don't know about nginx config though so maybe someone else can help >there. > >Matt > >-- >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
[openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1
Hi all I'm trying to re-add 3DES support (a temporary move, due to business requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. Whilst I do see some older ciphersuites being offered by NGINX after doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but that didn’t work. I have also tried adding @seclevel=0 to the ciphersuite string in NGINX but again, that didn’t work, I don’t see any 3DES ciphersuites available in NGINX. I'm wondering whether something changed between the above article and the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was completely removed in OpenSSL 1.1.1). Any pointers would be very much appreciated, I can’t find anything very useful on the web. Cheers Neil Craig Lead Technical Architect | Online Technology Group [cid:FDC52DA5-F1EC-4ED7-A69C-CACB83B41880] Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
