[openssl-users] Selection of DHE ciphers based on modulus size of DH
joshi.sanjaya at gmail.com
Thu Jun 7 06:22:55 UTC 2018
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
>> 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.
On Thu, Jun 7, 2018 at 8:52 AM, Jordan Brown <openssl at jordan.maileater.net>
> 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.
> 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
> Jordan Brown, Oracle Solaris
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openssl-users