Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-11 Thread Sanjaya Joshi
Hi,
Thank you for the clarifications.

Regards,
Sanjaya

On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm  wrote:

> (Top posting for consistency).
>
> Once the client receives the TLS1.2 servers choice of DH group,
> it can either accept it or abort the connection.
>
> However if both client and server support the "supported_groups"
> extension (RFC4492) with the additional DH group identifiers in
> RFC7919, they can negotiate a common accepted group of desired
> strength, though the mechanism (like TLS1.3) is artificially
> limited to a fixed set of groups listed in the RFC.
>
>
> On 08/06/2018 12:15, Sanjaya Joshi wrote:
>
>> Hello,
>> Thank you Matt and Jordan. So, it seems that it's possible to modify my
>> client to accept/reject the DH group key length. But i have one more issue
>> to be clarified.
>>
>> Is it possible that if a client does not accept the DH group key length
>> used by the server, then, a different possible cipher (for e.g., RSA) is
>> tried to be negotiated. It seems that the connection is rejected, instead
>> of falling back to a different possible cipher. At least, i tested this
>> quickly using s_client and s_server, and the behavior is as stated above,
>> i.e., no fallback and connection was terminated. Is this the default
>> OpenSSL behavior or this behaviour could be modified somehow by
>> applications ?
>>
>> Regards,
>> Sanjaya
>>
>> On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell > m...@openssl.org>> wrote:
>>
>>
>>
>> On 07/06/18 16:02, Jordan Brown wrote:
>> > I do not understand, however, how the 80 relates to a 1024-bit
>> limit.
>>
>> It's a measure of the "security bits" of an algorithm according to
>> table
>> 2 in this doc:
>> https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.
>> sp.800-57pt1r4.pdf
>> > sp.800-57pt1r4.pdf>
>>
>>
> 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-08 Thread Jakob Bohm

(Top posting for consistency).

Once the client receives the TLS1.2 servers choice of DH group,
it can either accept it or abort the connection.

However if both client and server support the "supported_groups"
extension (RFC4492) with the additional DH group identifiers in
RFC7919, they can negotiate a common accepted group of desired
strength, though the mechanism (like TLS1.3) is artificially
limited to a fixed set of groups listed in the RFC.


On 08/06/2018 12:15, Sanjaya Joshi wrote:

Hello,
Thank you Matt and Jordan. So, it seems that it's possible to modify 
my client to accept/reject the DH group key length. But i have one 
more issue to be clarified.


Is it possible that if a client does not accept the DH group key 
length used by the server, then, a different possible cipher (for 
e.g., RSA) is tried to be negotiated. It seems that the connection is 
rejected, instead of falling back to a different possible cipher. At 
least, i tested this quickly using s_client and s_server, and the 
behavior is as stated above, i.e., no fallback and connection was 
terminated. Is this the default OpenSSL behavior or this behaviour 
could be modified somehow by applications ?


Regards,
Sanjaya

On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell > wrote:




On 07/06/18 16:02, Jordan Brown wrote:
> I do not understand, however, how the 80 relates to a 1024-bit
limit.

It's a measure of the "security bits" of an algorithm according to
table
2 in this doc:

https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf





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] Selection of DHE ciphers based on modulus size of DH

2018-06-08 Thread Sanjaya Joshi
Hello,
Thank you Matt and Jordan. So, it seems that it's possible to modify my
client to accept/reject the DH group key length. But i have one more issue
to be clarified.

Is it possible that if a client does not accept the DH group key length
used by the server, then, a different possible cipher (for e.g., RSA) is
tried to be negotiated. It seems that the connection is rejected, instead
of falling back to a different possible cipher. At least, i tested this
quickly using s_client and s_server, and the behavior is as stated above,
i.e., no fallback and connection was terminated. Is this the default
OpenSSL behavior or this behaviour could be modified somehow by
applications ?

Regards,
Sanjaya

On Thu, Jun 7, 2018 at 8:43 PM, Matt Caswell  wrote:

>
>
> On 07/06/18 16:02, Jordan Brown wrote:
> > I do not understand, however, how the 80 relates to a 1024-bit limit.
>
> It's a measure of the "security bits" of an algorithm according to table
> 2 in this doc:
> https://nvlpubs.nist.gov/nistpubs/specialpublications/
> nist.sp.800-57pt1r4.pdf
>
> Matt
> --
> 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] Selection of DHE ciphers based on modulus size of DH

2018-06-07 Thread Matt Caswell



On 07/06/18 16:02, Jordan Brown wrote:
> I do not understand, however, how the 80 relates to a 1024-bit limit.

It's a measure of the "security bits" of an algorithm according to table
2 in this doc:
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf

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


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-07 Thread Jordan Brown
On 6/6/2018 11:22 PM, Sanjaya Joshi wrote:
> >>Current OpenSSL isn't willing to connect to a server using a DH key size
> below 1024 bits.
> Yes, i have verified this. However, not sure, how my OpenSSL-based
> client can do this, as our requirement is that we must not use DH key
> size below 2048 bits.
>
> >> I'm pretty sure that clients can and do refuse to talk to servers
> with small DH parameters.
> Could you please provide some more clues how a client can do so ?

The 1024-bit DH limit is implemented in the OpenSSL client library.  I
don't know if the calling application has any control or any visibility
onto that decision.

(But note: it's still the client that's making the decision, from the
perspective of the TLS protocol.)

A bit of searching later...

It looks like the key test is here:

https://github.com/openssl/openssl/blob/e6e9170d6e28038768895e1af18e3aad8093bf4b/ssl/ssl_cert.c#L921

/*
 * No EDH keys weaker than 1024-bits even at level 0, otherwise,
 * anything goes.
 */
if (op == SSL_SECOP_TMP_DH && bits < 80)
return 0;
return 1;

and it looks like you can plug in your own function using
SSL_set_security_callback.  I do not understand, however, how the 80
relates to a 1024-bit limit.

Here's the documentation:

https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_security_callback.html

-- 
Jordan Brown, Oracle Solaris

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


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-07 Thread Matt Caswell


On 07/06/18 04:10, Viktor Dukhovni wrote:
> 
> 
>> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users 
>>  wrote:
>>
>> Without commenting on whether or not your understanding is correct (the 
>> client gets the params and can see how big the key is, no?), I will point 
>> out that the way DHE works is defined by the IETF RFC’s, and they have not 
>> changed.
> 
> However, in TLS 1.3, the FFDHE groups are pre-defined, and the server
> does not get to choose ad-hoc (p, g) pairs.

Although OpenSSL does not currently support FFDHE groups in TLSv1.3.

Matt

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


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-07 Thread Sanjaya Joshi
Hello,
Thank you all for your responses. I forgot to mention that we are on
OpenSSL 1.1.0 and TLS 1.2.
I have some more queries though.


>>Current OpenSSL isn't willing to connect to a server using a DH key size
below 1024 bits.
Yes, i have verified this. However, not sure, how my OpenSSL-based client
can do this, as our requirement is that we must not use DH key size below
2048 bits.

>> I'm pretty sure that clients can and do refuse to talk to servers with
small DH parameters.
Could you please provide some more clues how a client can do so ?

>> However, in TLS 1.3, the FFDHE groups are pre-defined, and the server
>>does not get to choose ad-hoc (p, g) pairs
Yep; i saw them. Here, client plays a role to offer the supported DHE first
and then, the server can use that - just like elliptic curve negotiation.
But again, one catch is that custom DH groups are no more allowed, for
which i didn't find a good reasoning.


Regards,
Sanjaya

On Thu, Jun 7, 2018 at 8:52 AM, Jordan Brown 
wrote:

> On 6/6/2018 12:11 PM, Sanjaya Joshi wrote:
>
> I understood that when DHE ciphers are tried to be used between two
> entities, it's only the server that plays a role about selection of the DH
> parameters. This is not negotiable with the client. For e.g., the server
> can freely use a very low not-recommended DH group with 512 bit key length
> and the client cannot deny it.
>
>
> I'm pretty sure that clients can and do refuse to talk to servers with
> small DH parameters.
>
> Current OpenSSL isn't willing to connect to a server using a DH key size
> below 1024 bits.
>
> https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-
> upcoming-changes/
>
> To protect OpenSSL-based clients, we’re increasing the minimum accepted DH
> key size to 768 bits immediately in the next release, and to 1024 bits soon
> after.
>
>
> --
> Jordan Brown, Oracle Solaris
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-06 Thread Jordan Brown
On 6/6/2018 12:11 PM, Sanjaya Joshi wrote:
> I understood that when DHE ciphers are tried to be used between two
> entities, it's only the server that plays a role about selection of
> the DH parameters. This is not negotiable with the client. For e.g.,
> the server can freely use a very low not-recommended DH group with 512
> bit key length and the client cannot deny it.

I'm pretty sure that clients can and do refuse to talk to servers with
small DH parameters.

Current OpenSSL isn't willing to connect to a server using a DH key size
below 1024 bits.

https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/

To protect OpenSSL-based clients, we’re increasing the minimum
accepted DH key size to 768 bits immediately in the next release,
and to 1024 bits soon after. 


-- 
Jordan Brown, Oracle Solaris

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


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-06 Thread Viktor Dukhovni


> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users 
>  wrote:
> 
> Without commenting on whether or not your understanding is correct (the 
> client gets the params and can see how big the key is, no?), I will point out 
> that the way DHE works is defined by the IETF RFC’s, and they have not 
> changed.

However, in TLS 1.3, the FFDHE groups are pre-defined, and the server
does not get to choose ad-hoc (p, g) pairs.

-- 
Viktor.

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


Re: [openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-06 Thread Salz, Rich via openssl-users
Without commenting on whether or not your understanding is correct (the client 
gets the params and can see how big the key is, no?), I will point out that the 
way DHE works is defined by the IETF RFC’s, and they have not changed.

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


[openssl-users] Selection of DHE ciphers based on modulus size of DH

2018-06-06 Thread Sanjaya Joshi
Hello,
I understood that when DHE ciphers are tried to be used between two
entities, it's only the server that plays a role about selection of the DH
parameters. This is not negotiable with the client. For e.g., the server
can freely use a very low not-recommended DH group with 512 bit key length
and the client cannot deny it.

Is this understanding still correct or this has been changed recently ?

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