Selection of DHE ciphers based on modulus size of DH

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Selection of DHE ciphers based on modulus size of DH

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

Re: Selection of DHE ciphers based on modulus size of DH

OpenSSL - User mailing list

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

Re: Selection of DHE ciphers based on modulus size of DH

Viktor Dukhovni


> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Selection of DHE ciphers based on modulus size of DH

JordanBrown
In reply to this post by sanjaya joshi
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
Reply | Threaded
Open this post in threaded view
|

Re: Selection of DHE ciphers based on modulus size of DH

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

Re: Selection of DHE ciphers based on modulus size of DH

Matt Caswell-2
In reply to this post by Viktor Dukhovni


On 07/06/18 04:10, Viktor Dukhovni wrote:
>
>
>> On Jun 6, 2018, at 7:15 PM, Salz, Rich via openssl-users <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Selection of DHE ciphers based on modulus size of DH

JordanBrown
In reply to this post by sanjaya joshi
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
Reply | Threaded
Open this post in threaded view
|

Re: Selection of DHE ciphers based on modulus size of DH

Matt Caswell-2


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

Re: Selection of DHE ciphers based on modulus size of DH

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

Re: Selection of DHE ciphers based on modulus size of DH

Jakob Bohm-7
(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 <[hidden email]
> <mailto:[hidden email]>> 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
>     <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
Reply | Threaded
Open this post in threaded view
|

Re: Selection of DHE ciphers based on modulus size of DH

sanjaya joshi
Hi,
Thank you for the clarifications.

Regards,
Sanjaya

On Fri, Jun 8, 2018 at 4:30 PM, Jakob Bohm <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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
    <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


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