Re: [openssl-users] Session params output fails via cron

[Jordan Brown]

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

Re: [openssl-users] RNG behavior by default

[Dr. Matthias St. Pierre]

I agree with Kurt, except for one point:

> The RAND_bytes and RAND_status manpages can clearly be improved.

Both manpages got an update during the DRBG rewrite (by me) and I don't
see any contradiction. You bring it to the point yourself:

> So _IF_ it is seeded it is seeded...

It is true that the DRBG will automatically seed, but it is equally true
that it can still end up in an unseeded (error) state, if no suitable entropy
source is available. And since this can also happen during reseeding (which
in particular is enforced after a fork), it is always necessary to check the 
return
value of the RAND_bytes() function. Because in the error state, the buffer is 
not
filled at all.

Matthias


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Dr Paul Dale]

I know that iOS (which was listed) has a good randomness source 
(SecRandomCopyBytes 
)
 but I don’t think OpenSSL uses it yet.
I’m not sure about the quality of Android’s sources, but would expect them to 
be decent.


Pauli


> On 4 Jan 2019, at 10:46 pm, Dr. Matthias St. Pierre 
>  wrote:
> 
>> So my concerns are:
>> 1. Whether I really can count on getting a high-entropy PRNG across these 
>> various platforms, without any explicit initialization.
> 
> Yes, for the mentioned platforms, the default configuration is 
> `--with-rand-seed=os`, which means the DRBG automatically seeds
> and reseeds using os entropy sources.
> 
> 2. If something goes wrong with PRNG initialization, that it will fail hard 
> rather than fall back to something less secure. And if so how I detect such a 
> failure.
> 
> If the (re-)seeding fails, the DRBG enters an error state. When you try to 
> generate random bytes it will detect the error state and try
> automatically to heal the error state by reinstantiating. But if reseeding 
> fails, it will return and error code and not generate any pseudo random bytes.
> 
> Citing from the manual pages:
> 
>   OpenSSL comes with a default implementation of the RAND API which is 
> based on the
>   deterministic random bit generator (DRBG) model as described in [NIST 
> SP 800-90A Rev. 1].
>   The default random generator will initialize automatically on first use 
> and will be fully functional
>   without having to be initialized ('seeded') explicitly. It seeds and 
> reseeds itself automatically using
>   trusted random sources provided by the operating system.
> 
>   As a normal application developer, you do not have to worry about any 
> details, just use RAND_bytes(3)
>   to obtain random data. Having said that, there is one important rule to 
> obey: Always check the error
>   return value of RAND_bytes(3) and do not take randomness for granted.
> 
>   https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> (See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)
> 
> Matthias
> 
> -- 
> 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

Re: [openssl-users] Session params output fails via cron

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] 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

Re: [openssl-users] Session params output fails via cron

[Jordan Brown]

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
>  ...
> 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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote:
> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72@Ex13.\
> ncp.local>:
>  |> So my concerns are:
>  |> 1. Whether I really can count on getting a high-entropy PRNG across \
>  |> these various platforms, without any explicit initialization.
>  |
>  |Yes, for the mentioned platforms, the default configuration is `--with-r\
>  |and-seed=os`, which means the DRBG automatically seeds
>  |and reseeds using os entropy sources.
>  |
>  |2. If something goes wrong with PRNG initialization, that it will fail \
>  |hard rather than fall back to something less secure. And if so how \
>  |I detect such a failure.
>  |
>  |If the (re-)seeding fails, the DRBG enters an error state. When you \
>  |try to generate random bytes it will detect the error state and try
>  |automatically to heal the error state by reinstantiating. But if reseeding \
>  |fails, it will return and error code and not generate any pseudo random \
>  |bytes.
>  |
>  |Citing from the manual pages:
>  ...
>  | As a normal application developer, you do not have to worry about \
>  | any details, just use RAND_bytes(3)
>  | to obtain random data. Having said that, there is one important rule \
>  | to obey: Always check the error
>  | return value of RAND_bytes(3) and do not take randomness for granted.
>  |
>  | https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> That is new however, _imho_.  The wording of RAND_bytes(3) (still)
> says that "an error occurs [.if.] not [been] seeded with enough
> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
> with enough data".  So if it is seeded it is seeded, in my
> understanding anything further on up the road only mixes in noise
> (which likely will undergo further maths and be stirred into the
> pool, i have not looked, actually).  I do not test RAND_bytes(3)
> return (yet), because i have ensured the PRNG is sufficiently
> seeded, and RAND_status(3) returns success, before RAND_bytes(3)
> is used the first time.

For 1.1.0 and older that works, because they do not reseed. Since
1.1.1 it does reseed, and if the reseed fails, it will go to an
error state. So yes, this is new behavior.

The RAND_bytes and RAND_status manpages can clearly be improved.
Since you always have to check RAND_bytes's return value now,
RAND_status is mostly useless.


Kurt

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session params output fails via cron

[Jakob Bohm via openssl-users]

On 04/01/2019 18:15, Salz, Rich wrote:

 Jakob - you’re a star! Thanks so much, your suggestion works. So I added
 
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

Re: [openssl-users] Session params output fails via cron

[open...@foocrypt.net]

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 
>  wrote:
> 
>Jakob - you’re a star! Thanks so much, your suggestion works. So I added
> ...
>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

Re: [openssl-users] Session params output fails via cron

[Salz, Rich via openssl-users]

Jakob - you’re a star! Thanks so much, your suggestion works. So I added
https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Steffen Nurpmeso]

Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72@Ex13.\
ncp.local>:
 |> So my concerns are:
 |> 1. Whether I really can count on getting a high-entropy PRNG across \
 |> these various platforms, without any explicit initialization.
 |
 |Yes, for the mentioned platforms, the default configuration is `--with-r\
 |and-seed=os`, which means the DRBG automatically seeds
 |and reseeds using os entropy sources.
 |
 |2. If something goes wrong with PRNG initialization, that it will fail \
 |hard rather than fall back to something less secure. And if so how \
 |I detect such a failure.
 |
 |If the (re-)seeding fails, the DRBG enters an error state. When you \
 |try to generate random bytes it will detect the error state and try
 |automatically to heal the error state by reinstantiating. But if reseeding \
 |fails, it will return and error code and not generate any pseudo random \
 |bytes.
 |
 |Citing from the manual pages:
 ...
 | As a normal application developer, you do not have to worry about \
 | any details, just use RAND_bytes(3)
 | to obtain random data. Having said that, there is one important rule \
 | to obey: Always check the error
 | return value of RAND_bytes(3) and do not take randomness for granted.
 |
 | https://www.openssl.org/docs/man1.1.1/man7/RAND.html

That is new however, _imho_.  The wording of RAND_bytes(3) (still)
says that "an error occurs [.if.] not [been] seeded with enough
[data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
with enough data".  So if it is seeded it is seeded, in my
understanding anything further on up the road only mixes in noise
(which likely will undergo further maths and be stirred into the
pool, i have not looked, actually).  I do not test RAND_bytes(3)
return (yet), because i have ensured the PRNG is sufficiently
seeded, and RAND_status(3) returns success, before RAND_bytes(3)
is used the first time.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] RNG behavior by default

[Dr. Matthias St. Pierre]

> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these 
> various platforms, without any explicit initialization.

Yes, for the mentioned platforms, the default configuration is 
`--with-rand-seed=os`, which means the DRBG automatically seeds
and reseeds using os entropy sources.

2. If something goes wrong with PRNG initialization, that it will fail hard 
rather than fall back to something less secure. And if so how I detect such a 
failure.

If the (re-)seeding fails, the DRBG enters an error state. When you try to 
generate random bytes it will detect the error state and try
automatically to heal the error state by reinstantiating. But if reseeding 
fails, it will return and error code and not generate any pseudo random bytes.

Citing from the manual pages:

OpenSSL comes with a default implementation of the RAND API which is 
based on the
deterministic random bit generator (DRBG) model as described in [NIST 
SP 800-90A Rev. 1].
The default random generator will initialize automatically on first use 
and will be fully functional
without having to be initialized ('seeded') explicitly. It seeds and 
reseeds itself automatically using
trusted random sources provided by the operating system.

As a normal application developer, you do not have to worry about any 
details, just use RAND_bytes(3)
to obtain random data. Having said that, there is one important rule to 
obey: Always check the error
return value of RAND_bytes(3) and do not take randomness for granted.

https://www.openssl.org/docs/man1.1.1/man7/RAND.html

(See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)

Matthias

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] 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 :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

[Neil Craig]

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