Session params output fails via cron

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Session params output fails via cron

Neil Craig

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.

Cheers 

Neil Craig
Lead Technical Architect | Online Technology Group
Broadcast Centre, London W12 7TQ | BC4 A3 

 

----------------------------

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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Matt Caswell-2


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.

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Neil Craig
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"
<[hidden email] on behalf of [hidden email]> 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.
>
>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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Matt Caswell-2
In reply to this post by Neil Craig


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

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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Neil Craig
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"
<[hidden email] on behalf of [hidden email]> 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
>
>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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
Two of the more common causes of cron failure are
        - Environment variable missing or has different value (PATH etc)
        - File permissions are different if running under root vs normal interactive user.

Hope that helps.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
In reply to this post by Neil Craig
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"
> <[hidden email] on behalf of [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Jakob Bohm via openssl-users
> Sent: Thursday, January 03, 2019 09:52
> To: [hidden email]
> Subject: Re: [openssl-users] Session params output fails via cron
>
>
> 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.

Or if the OP is already redirecting / piping stdin in the cron job command line, something like this:

(cat input.txt; sleep 10) | openssl s_client ...

so that stdin remains open for a while after the actual input is exhausted. Maybe use that in conjunction with -ign_eof (shouldn't hurt, assuming the server closes its end of the connection when it's done).

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Neil Craig
In reply to this post by OpenSSL - User mailing list
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" <[hidden email] on behalf of
[hidden email]> 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"
>> <[hidden email] on behalf of [hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Neil Craig
Actually, my apologies, I missed -ign_eof - that is also needed, so the
“fixed” request is:

/path/to/openssl s_client -connect <host>:443 -servername <hostname>
-tls1_3 ­sess_out -ign_eof </dev/null


Cheers

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 04/01/2019, 10:58, "Neil Craig" <[hidden email]> wrote:

>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" <[hidden email] on behalf of
>[hidden email]> 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"
>>> <[hidden email] on behalf of [hidden email]>
>>>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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
In reply to this post by Neil Craig
    Jakob - you’re a star! Thanks so much, your suggestion works. So I added
    </dev/null to now give:
...
    I’m wondering if this would be something worthy of attention in openssl?
   
Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

FooCrypt
Just a thought …

Do you get the same error when running the command from within a shell script from cron [ in either bash or Korn or one of the other sh’s ] or by executing the shell script from the command line ?

What are your default environment settings and shell for the user you are executing the commands via cron ?

> On 5 Jan 2019, at 04:15, Salz, Rich via openssl-users <[hidden email]> wrote:
>
>    Jakob - you’re a star! Thanks so much, your suggestion works. So I added
>    </dev/null to now give:
> ...
>    I’m wondering if this would be something worthy of attention in openssl?
>
> Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
On 04/01/2019 18:15, Salz, Rich wrote:
>      Jakob - you’re a star! Thanks so much, your suggestion works. So I added
>      </dev/null to now give:
> ...
>      I’m wondering if this would be something worthy of attention in openssl?
>    
> Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.
>

Perhaps it is simpler to just accept invalid stdin if -ignoreeof is set.

In particular, this avoids dealing with OS specific names of /dev/null,
as well as chroot jails without that character device.


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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

JordanBrown
In reply to this post by OpenSSL - User mailing list
On 1/4/2019 9:15 AM, Salz, Rich via openssl-users wrote:
    Jakob - you’re a star! Thanks so much, your suggestion works. So I added
    </dev/null to now give:
...
    I’m wondering if this would be something worthy of attention in openssl?
   
Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.


All kinds of Bad Stuff will happen if file descriptors {0,1,2} aren't set up right.  Start with, say, an application opening a database, getting fd  2 because that happens to be the first available, and then for some reason writing an error message to stderr.

I'd be shocked if cron starts an application without *something* reasonable on {0,1,2}.  I'd consider it to be a very serious bug in cron.  (I can't speak to anything else, but Solaris cron has 0 on /dev/null and 1 and 2 leading to a temporary file that gets mailed to the user if non-empty.)

Whether an application should try to cope with such a broken environment... shrug.  Few if any do.

If you want to, what you want is something like:

	int fd;
	do {
		fd = open("/dev/null", O_RDWR);
	} while (fd < 3);
	close(fd);

(That's strictly not quite right, since it leaves 0 open writable and 1 and 2 open readable, but that's pretty harmless.)

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Jordan Brown
> Sent: Friday, January 04, 2019 13:16

> If you want to, what you want is something like:
>       int fd;
>       do {
>               fd = open("/dev/null", O_RDWR);
>       } while (fd < 3);
>       close(fd);
> (That's strictly not quite right, since it leaves 0 open writable and 1 and 2 open readable,
> but that's pretty harmless.)

Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).

Since source bytes are cheap, though, and there are at most three opens to be done, I'd just do it explicitly for the three stdio descriptors. That would also make the intention clear. (Yes, the intention of your version is clear to old UNIX hands. It might not be to other people.)

I'm ignoring portability considerations, since I personally don't think this would be a great thing to implement in the apps, so I'm not going to be submitting a PR for it.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

JordanBrown
On 1/4/2019 1:04 PM, Michael Wojcik wrote:
Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).

Yes.  Oops.

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
In reply to this post by Michael Wojcik
On 04/01/2019 22:04, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of Jordan Brown
>> Sent: Friday, January 04, 2019 13:16
>> If you want to, what you want is something like:
>>        int fd;
>>        do {
>>                fd = open("/dev/null", O_RDWR);
>>        } while (fd < 3);
>>        close(fd);
>> (That's strictly not quite right, since it leaves 0 open writable and 1 and 2 open readable,
>> but that's pretty harmless.)
> Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).
>
> Since source bytes are cheap, though, and there are at most three opens to be done, I'd just do it explicitly for the three stdio descriptors. That would also make the intention clear. (Yes, the intention of your version is clear to old UNIX hands. It might not be to other people.)
>
> I'm ignoring portability considerations, since I personally don't think this would be a great thing to implement in the apps, so I'm not going to be submitting a PR for it.
>
A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).

Please refer to my previous post about the many other reasons why
opening /dev/null has a high risk of failure.

Stepping back, it is worth investigating if:

  - Running TLS1.3 s_client with -ignoreeof and no stdin actually fails
   earlier than with stdin == /dev/null

  - If this is triggered by a code bug.

P.S.

On some Debian systems, cron runs scripts with stdout and stderr piped
(directly or indirectly) to a mail program that times out if a cron job
runs for a long time.


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
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

JordanBrown
[ Off topic for OpenSSL... ]

On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).


There's always a first reason :-)

But also:  /dev/null is part of the definition of UNIX.  Programs have every right to expect that it will be there.  Yes, you can build a chroot environment that doesn't include it... but then you can't complain when programs don't work in your environment.  You can also build an environment that doesn't include system libraries, and there are reasons to do so, but few programs will work in it.

Looking at Solaris, about 15% of the programs in /usr/bin and 5% of the libraries in /usr/lib have a reference to /dev/null.

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Session params output fails via cron

OpenSSL - User mailing list
On 07/01/2019 22:26, Jordan Brown wrote:

> [ Off topic for OpenSSL... ]
>
> On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
>> A chroot with no other reason to open /dev/null should not contain that
>> file name, even on unix-like platforms (least privilege chroot design).
>
>
> There's always a first reason :-)
>
> But also:  /dev/null is part of the definition of UNIX
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html#tag_10_01>. 
> Programs have every right to expect that it will be there.  Yes, you
> can build a chroot environment that doesn't include it... but then you
> can't complain when programs don't work in your environment.  You can
> also build an environment that doesn't include system libraries, and
> there are reasons to do so, but few programs will work in it.
>
> Looking at Solaris, about 15% of the programs in /usr/bin and 5% of
> the libraries in /usr/lib have a reference to /dev/null.
>
>
The whole point of a chroot jail is to deny a program access to any
and all parts of Unix (and the local flavor) it won't need.  For
example, most chroot jails remove /bin/ls, with ftp servers as the
major exception.

Thus /dev/null being part of UNIX/POSIX doesn't say anything about
its availability in chroot jails. Nor does it say anything about
its availability on non-unix platforms, many of which are explicitly
supported by the OpenSSL libraries.

For many programs, it is standard to chroot to a directory with
nothing or almost nothing after loading configuration files, code,
certificates etc. /var/empty and /var/www are common examples.


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