Hi Jakob and Paul, Thank you so much for the reply. We have the RSA certificates. I wanted to understand how generally DH parameters are generated. Thanks for the detailed answers.
Regards Jayalakshmi On Wed, Dec 6, 2017 at 12:48 AM, Jakob Bohm <jb-open...@wisemo.com> wrote: > On 06/12/2017 07:02, Jayalakshmi bhat wrote: > >> Hi, >> >> We are planning to use DHE_RSA TLS ciphers into our product. I have few >> questions on using DH parameter. We would like to use DH-2048. >> >> our product includes both TLS client and server applications. Thus any >> time there will be considerable number of active connectioons. >> >> I believe we can use same DH parameter for all the server connections. Is >> my understanding correct? Is there any risk in using same parameter for all >> the server connections. >> >> Another question is what is guidelines/document should be followed to >> derive DH parameter. >> >> Any input is appreciated. >> >> >> In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3), > DHE parameters are chosen exclusively by the server, so most rules > will be about servers. > > Current best practice on clients is to reject parameters of less > than 1000 bits, parameters with fewer bits than they pretend (e.g. > parameters claiming to be 1024 bits, but the most significant 32 > bits are all 0, making them really less than 993 bits), parameters > that are glaringly non-prime (e.g. even numbers) and parameters > that cause the DHE calculation to result in an unreasonably number > such as 1 (indicating rigged parameters). I hope that OpenSSL > client code already does such checks by default, otherwise someone > should point out how to make it do so. > > Current best practice on servers is to use DHE parameters such as > those generated by openssl dhparam, or the equivalent API function. > > Current best practice on general purpose servers is to use at least > 2048 bit DH parameters except when talking to clients that can't do > that, such as the TLS code in Oracle Java 6. Going above 2048 bits > is good, but some common clients don't work significantly above > that number (for example, some versions of the Mozilla NSS code > have a built in maximum of 2236 bits). > > Current best practice on servers is to use DHE parameters that are > used by few other servers, at least in a given timespan. Thus for > servers that will be deployed in small numbers, just generate your > own parameters at build time using > openssl dhparam -C xxxx > dhxxxx.inc > then include dhxxxx.inc in your source code. For servers that will > be deployed in large numbers, load the dh parameters from files in > the format generated by > openssl dhparam xxxx > dhxxxx.pem > and include scripts or other code that will replace the file > contents daily or weekly (overwriting the old parameters only after > the new ones are ready). The exim mail server does this if you > follow the instructions. > > 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