Re: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()

[Andy Schmidt]

Thank you Victor and Kurt for your quick replies! They were very helpful

Best,
Andy Schmidt

On Thu, Jan 3, 2019 at 2:00 PM Kurt Roeckx  wrote:

> On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> > I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers,
> and
> > I've found that these parameters won't pass OpenSSL's Diffie Hellman
> > parameter check function DH_check(). The return code is
> > DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> > because the remainder of the prime divided by 24 is not 11. That its, p
> mod
> > 24 != 11. I have a couple of questions:
> >
> > What relationship between the prime p and the generator g is this
> checking
> > for? I thought that since p was a safe prime, as long as the generator g
> > wasn't 1 the only choice is between the full group and the subgroup of
> the
> > squares?
> >
> > I would like to use DH_check() to attempt to ensure that Diffie Hellman
> > parameters haven't been tampered on operating systems that don't have
> > digital signatures for executable binaries.
>
> See:
>
> https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11
>
>
> Kurt
>
> --
> 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] RFC 7919 DH parameters and OpenSSL DH_check()

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
> I've found that these parameters won't pass OpenSSL's Diffie Hellman
> parameter check function DH_check(). The return code is
> DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> because the remainder of the prime divided by 24 is not 11. That its, p mod
> 24 != 11. I have a couple of questions:
> 
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?
> 
> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.

See:
https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11


Kurt

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

Re: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()

[Viktor Dukhovni]

On Jan 3, 2019, at 3:18 PM, Andy Schmidt  wrote:

> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS
> servers, and I've found that these parameters won't pass OpenSSL's
> Diffie Hellman parameter check function DH_check(). The return code
> is DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears
> to fail because the remainder of the prime divided by 24 is not 11.
> That its, p mod 24 != 11. I have a couple of questions:
>
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?

For a safe prime $p = 2q + 1$ with $q$ also prime, the order of $2$ is $q$
provided $2$ is quadratic residue mod $p$, which, by quadratic reciprocity,
considering that $q$ is odd and not a multiple of 3 for any primes of interest,
gives $p \cong 23 mod 24$, which then gives $q \cong 11 mod 12$.

The order of $2$ is $2q$ when $2$ is not a quadratic residue mod $p$, which
then gives $p \cong 3 mod 8$ and so taking mod 3 into account
$p \cong 11 mod 24$.

So it seems that the check in question wants $2$ to generates the
full multiplicative group of order $2q$, rather than the prime-order
subgroup of quadratic residues of order $q$.

> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.
> 
> The OpenSSL version in use is 1.0.2q.

The primes in RFC7919 are all 23 mod 24, which has $o(2) = q$ rather
than $o(2) = 2q$.  This is actually fine, perhaps even better, and
the code in DH_check() is too strict in wanting the generator to
generate the full multiplicative group mod $p$, rather than just
the subgroup of of quadratic residues of order $q$.

So a pull request for OpenSSL would be welcome.  Given that we
should not care whether the order of $g$ is $q$ or $2q$, it suffices
to just check that $p$ is plausibly prime and $q = (p-1)/2 == (p
>> 1)$ is plausibly prime.  The special checks for $g == 2, 3 and
5$ should be removed.  For 1.1.1 the patch would be something like:

--- a/crypto/dh/dh_check.c
+++ b/crypto/dh/dh_check.c
@@ -88,8 +88,6 @@ int DH_check_ex(const DH *dh)
 DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_INVALID_Q_VALUE);
 if ((errflags & DH_CHECK_INVALID_J_VALUE) != 0)
 DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_INVALID_J_VALUE);
-if ((errflags & DH_UNABLE_TO_CHECK_GENERATOR) != 0)
-DHerr(DH_F_DH_CHECK_EX, DH_R_UNABLE_TO_CHECK_GENERATOR);
 if ((errflags & DH_CHECK_P_NOT_PRIME) != 0)
 DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_P_NOT_PRIME);
 if ((errflags & DH_CHECK_P_NOT_SAFE_PRIME) != 0)
@@ -140,20 +138,7 @@ int DH_check(const DH *dh, int *ret)
 if (dh->j && BN_cmp(dh->j, t1))
 *ret |= DH_CHECK_INVALID_J_VALUE;
 
-} else if (BN_is_word(dh->g, DH_GENERATOR_2)) {
-l = BN_mod_word(dh->p, 24);
-if (l == (BN_ULONG)-1)
-goto err;
-if (l != 11)
-*ret |= DH_NOT_SUITABLE_GENERATOR;
-} else if (BN_is_word(dh->g, DH_GENERATOR_5)) {
-l = BN_mod_word(dh->p, 10);
-if (l == (BN_ULONG)-1)
-goto err;
-if ((l != 3) && (l != 7))
-*ret |= DH_NOT_SUITABLE_GENERATOR;
-} else
-*ret |= DH_UNABLE_TO_CHECK_GENERATOR;
+}
 
 r = BN_is_prime_ex(dh->p, BN_prime_checks, ctx, NULL);
 if (r < 0)

-- 
Viktor.

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

Re: [openssl-users] RNG behavior by default

[Kurt Roeckx]

On Thu, Jan 03, 2019 at 11:03:01AM -0500, Mike Blaguszewski wrote:
> I am using the EVP API (version 1.1.1) for performing public key and 
> symmetric key operations across a variety of platforms (macOS, Windows, 
> Linux, iOS and Android). I am currently not doing anything to explicitly seed 
> OpenSSL’s random number generator. My understanding is that the default 
> behavior  should be 
> cryptographically secure.
> 
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these 
> various platforms, without any explicit initialization.
> 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.
> 
> Our current implementation uses libsodium, which relies on the usual system 
> calls to generate entropy, so if I can count on OpenSSL always doing this 
> then I’m happy. 

It will make use of system calls when available. Those are known
to provide system calls:
- Linux since 3.17
- Darwin since 16 (OSX 10.12, IOS 10.0).
- Solaris since 11.3
- OpenBSD since 5.6
- FreeBSD since 12.0 (1200061)

By default it will fall back to use something like /dev/urandom if
the system call is not available or returns an error.

On Windows we are also using the system provided entropy by using
function calls.

You do not need to do anything to initialize RNG. It will
automatically initiailze on first use.

It will hard fail when it's not able to get entropy.

Since it now reseeds from time to time, it can actually start to
fail after having run succesfully for some time. But it's very
unlikely that you would run into that, by default we should make
sure that we can always get entropy.


Kurt

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

[openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()

[Andy Schmidt]

I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
I've found that these parameters won't pass OpenSSL's Diffie Hellman
parameter check function DH_check(). The return code is
DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
because the remainder of the prime divided by 24 is not 11. That its, p mod
24 != 11. I have a couple of questions:

What relationship between the prime p and the generator g is this checking
for? I thought that since p was a safe prime, as long as the generator g
wasn't 1 the only choice is between the full group and the subgroup of the
squares?

I would like to use DH_check() to attempt to ensure that Diffie Hellman
parameters haven't been tampered on operating systems that don't have
digital signatures for executable binaries.

The OpenSSL version in use is 1.0.2q.

Any help is greatly appreciated.
Andy Schmidt
-- 
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
> Jakob Bohm via openssl-users
> Sent: Thursday, January 03, 2019 09:52
> To: openssl-users@openssl.org
> 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 " 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
> "https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] RNG behavior by default

[Mike Blaguszewski]

I am using the EVP API (version 1.1.1) for performing public key and symmetric 
key operations across a variety of platforms (macOS, Windows, Linux, iOS and 
Android). I am currently not doing anything to explicitly seed OpenSSL’s random 
number generator. My understanding is that the default behavior 
 should be 
cryptographically secure.

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

Our current implementation uses libsodium, which relies on the usual system 
calls to generate entropy, so if I can count on OpenSSL always doing this then 
I’m happy. 

Thanks,
Mike-- 
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 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 "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

[Salz, Rich via openssl-users]

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

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

[Matt Caswell]

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

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

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

[Matt Caswell]

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

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