[openssl-users] DH parameters [was: Vulnerability logjam downgrades TLS connections to 512 Bit]
Hello On 22.05.2015 08:30, Jeffrey Walton wrote: Or are you talking about server certificates with fixed DH parameters? can you please tell me more about this? how do I have to create the certificate request? (using debian 7 latest updates installed: 'apt-get update apt-get upgrade' has nothing to do) Thanks, Walter smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DH parameters [was: Vulnerability logjam downgrades TLS connections to 512 Bit]
On Fri, May 22, 2015 at 5:20 AM, Walter H. walte...@mathemainzel.info wrote: Hello On 22.05.2015 08:30, Jeffrey Walton wrote: Or are you talking about server certificates with fixed DH parameters? can you please tell me more about this? They have a DH group called out by parameters (an not by name as in the Gillmor draft). They also use a static key A = g ^ a. The A is the public key, and the public key is effectively fixed and presented like an RSA key or a DSS key in the certificate. They are being phased out or have been phased out. I don't use them, so I don't really follow them. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: OpenSSL and DH parameters
If the negotiated cipher suite for an RSA encrypted client-server session does not involve using the RSA public keys, then when is RSA used in that session ? Not sure to fully understand your question, but the answer may be : 'Just for [server] authentication' Hope this helps.
RE: OpenSSL and DH parameters
From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Friday, October 25, 2013 09:46 On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote: I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). No, this is optional. Maybe. Assuming only server 'typically' sets keycert, It depends on what you want the server to support. If you want to (maybe need to) support EDH, you must either set_tmp_dh or set_tmp_dh_cb . Ditto for ADH, but that's rare at least on the public net. If your clients/users demand forward secrecy -- which since Snowden has become more popular -- then EDH or EECDH are the only authenticated choices to accomplish this, and as noted recently getting EECDH to interoperate may be an issue. I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. No, this depends on the cipher-suite. Technically DH keys are also public/private pairs (x and y = g^x mod p), but EDH (and ADH) keys are normally ephemeral so people don't notice them. (And the same for EC, except it's point multiply instead of modexp.) akRSA key-exchange uses server RSA keypair for key-exchange; if client-auth is used client (RSA) keypair is used to sign key-exchange data. EDH-RSA uses the server (RSA static) keypair to sign key-exchange data, and both DH keypairs for key-agreement. Static DH (rarely if ever used, and not yet released in OpenSSL but reportedly will in 1.0.2) uses the DH keypairs for key-agreement, and higher (RSA/DSA) publickey to verify the cert. If my understanding is correct, the DH parameters are used for key exchange also. No, not also, rather instead when an EDH cipher-suite is negotiated. Right. (Technically DH parameters and keys are used, but the keys are usually ephemeral, so the application need only care about parameters.) So if public key are used, is there a situation when the DH parameters will be used instead for key exchange.? When an EDH cipher-suite is negotiated. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negotiation will fail No, the server won't negotiate an EDH cipher-suite when it has no DH parameters. Clients don't begin EDH/EECDH key Exchange, servers do. The client doesn't start key-exchange, but what it offers limits what the server can choose. If the client offers only EDH suite(s), and the server doesn't have DH parameters, then negotiation will indeed fail. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL and DH parameters
From: owner-openssl-users On Behalf Of Patrick Pelletier Sent: Friday, October 25, 2013 02:53 On 10/24/13 1:59 PM, Dave Thompson wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? That's what OpenSSL does -- if there is another mutually acceptable suite. In particular if the server has an RSA key/cert and the client offers both ECDHE-RSA but not the server's curve and akRSA, OpenSSL will choose akRSA and work, but without forward secrecy. If the server has ECDSA key/cert (only) and the client offers ECDHE-ECDSA and ECDHE-RSA but not the server's curve and akRSA, none can work and handshake fails. (Similarly for static-ECDH, and AECDH but in most situations anonymous suites aren't acceptable at all.) I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013- October/018330.html It suggests that if the client offers P-256 and P-384, but the server's tmp_ecdh is set to P-521, then the server will pick an elliptic curve cipher suite anyway, try to force P-521 on the client, and the handshake He doesn't say, and I don't know, if the cited servers are OpenSSL. And if they are, what suites they enable. Someone who thinks P-521 is needed today might also try to force forward secrecy. But if OpenSSL server has a choice of EC with unagreed curve and something else, it will go with the something else, which is still better than nothing. (Unless the something else is something badly stupid like export RSA-512 DES-40 MD5.) will fail. Hence his assertion With TLS, no EC is better than crippled EC. This seems very wrong to me! If the client and server can't agree on a curve, shouldn't the server just pick a non-elliptic-curve cipher suite that both it and the client support instead? It seems like offering EC should never be worse than not offering EC! I agree. I think he meant that if the server is mishandling EC nego and thus causing fallback to no SSL at all, better not to try EC. Note an OpenSSL server using the ecdh *callback* could dynamically choose an appropriate curve (and possibly also key) based on what the client offers, but that's more work and for now requires poking directly in the SSL/session structure, although I think I remember a rumor that a better API is coming soon presumably 1.0.2. The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ Is this true? And why? It doesn't seem like it should work that way. I don't think he says that. 1 para 1 says later parameter[s] can negate the initial cipher suite choice, requiring returning to the suite list to try [another]. (Other) implementations might have this wrong, though. I'm also not sure what he means by later; everything is in the one ClientHello message, except possibly the issue he notes later about ECDSA and (E)ECDH with different (but both supported) curves; that isn't apparent until you get the (Server)Cert and ServerKX. In most cases that would make auth stronger or weaker than privacy, which isn't usually desirable, but might be. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
On 10/24/13 1:59 PM, Dave Thompson wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html It suggests that if the client offers P-256 and P-384, but the server's tmp_ecdh is set to P-521, then the server will pick an elliptic curve cipher suite anyway, try to force P-521 on the client, and the handshake will fail. Hence his assertion With TLS, no EC is better than crippled EC. This seems very wrong to me! If the client and server can't agree on a curve, shouldn't the server just pick a non-elliptic-curve cipher suite that both it and the client support instead? It seems like offering EC should never be worse than not offering EC! The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ Is this true? And why? It doesn't seem like it should work that way. --Patrick __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html With respect to the OpenSSL server implementation I was wrong. The issue was a bug in the RedHat OpenSSL package's recently introduced EC support advertising curves it did not implement. The issue is still possible if clients both send SSLv2 compatible HELLO (thus no extensions) and include EC ciphersuites. Since SSLv2 is now disabled by default, one might say they should not do that. The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ That's a deeper set of issues, that are still relevant. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
Hi, I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. If my understanding is correct, the DH parameters are used for key exchange also. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negociation will fail ? Thank you! On Friday, October 25, 2013 4:03 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Oct 24, 2013 at 11:52:36PM -0700, Patrick Pelletier wrote: (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) So, my understanding is that if the tmp_ecdh is set to a curve which is not supported by the client, then OpenSSL ought to just skip the elliptic curve cipher suites and pick the next acceptable cipher suite supported by both the client and server. Is this not the case? I was puzzled by this message: http://www.metzdowd.com/pipermail/cryptography/2013-October/018330.html With respect to the OpenSSL server implementation I was wrong. The issue was a bug in the RedHat OpenSSL package's recently introduced EC support advertising curves it did not implement. The issue is still possible if clients both send SSLv2 compatible HELLO (thus no extensions) and include EC ciphersuites. Since SSLv2 is now disabled by default, one might say they should not do that. The following draft also seems to suggest the same thing, that if client and server both support an elliptic curve suite, they will pick it, and then discover that they don't have any curves in common, and give up, rather than picking a non-EC suite: http://datatracker.ietf.org/doc/draft-gutmann-tls-eccsuites/ That's a deeper set of issues, that are still relevant. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote: I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). No, this is optional. I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. No, this depends on the cipher-suite. If my understanding is correct, the DH parameters are used for key exchange also. No, not also, rather instead when an EDH cipher-suite is negotiated. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange.? When an EDH cipher-suite is negotiated. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negotiation will fail No, the server won't negotiate an EDH cipher-suite when it has no DH parameters. Clients don't begin EDH/EECDH key Exchange, servers do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL and DH parameters
Is it recommended to specify and use DH parameters for server ? I know that RSA encryption/decryption is slow and this is why RSA public keys are used only for establishing the session key which is a symmetric key usually because symetric key encryption is fast. If the negotiated cipher suite for an RSA encrypted client-server session does not involve using the RSA public keys, then when is RSA used in that session ? On Friday, October 25, 2013 4:49 PM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Fri, Oct 25, 2013 at 06:35:08AM -0700, LN wrote: I mean in a typical usage of OpenSSL is it mandatory to call SSL_CTX_set_tmp_dh() if I call SSL_CTX_use_certificate() and SSL_CTX_use_PrivateKey(). No, this is optional. I know that for RSA keys, for example, the session key exchange is done using the public keys of the client and server. No, this depends on the cipher-suite. If my understanding is correct, the DH parameters are used for key exchange also. No, not also, rather instead when an EDH cipher-suite is negotiated. So if public key are used, is there a situation when the DH parameters will be used instead for key exchange.? When an EDH cipher-suite is negotiated. So is my understading correct, that DH might be used if the client uses a protocol for key exchange that is based on DH and if the server doesn't have the DH parameters, the negotiation will fail No, the server won't negotiate an EDH cipher-suite when it has no DH parameters. Clients don't begin EDH/EECDH key Exchange, servers do. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL and DH parameters
Do you mean SSL/TLS the protocols and OpenSSL the implementation? For SSL when an ADH or EDH aka DHE suite is negotiated, the server must send DH parameters and its (nominally one-time) public key, and the client uses or at least matches the parameters and sends its (ditto) public key. Similarly for AECDH or EECDH/ECDHE the server must send an ECC curve and public key and the client uses/checks and sends public key, but for ECC the curve can be and usually(?) is a named curve specified by an OID rather than 'explicit' parameters. Other implementations may have default or auto (EC)DH parameters; OpenSSL library does not. If you are the server and want to support ADH/EDH/DHE or AECDH/EECDH/ECDHE suites, you must configure the respective tmp_dh or tmp_ecdh before handshake, or configure a callback to select/set it during the handshake (which can set the specific key as well). (For EC, the specified curve must also be acceptable to client(s) per ClientHello extension, which encourages using the callback or choosing a popular curve like P-256.) A server may want to support ADH/EDH/DHE on its own, or because its client(s) want that. For the non-anonymous suites, server must configure a server cert/chain and privatekey before handshake. That is along with in the sense that both must be done, but not necessarily at the same place in the code. If you are the client, you do not configure tmp_[ec]dh, and you configure cert/chain and privatekey only if you use client-auth (also called mutual-auth) which is relatively rare. OpenSSL commandline s_server does have defaults, although the default tmp_dh is (still) 512 bits, which is (now) way too small. OTOH it's nominally only a test tool. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of LN Sent: Thursday, October 24, 2013 08:59 To: openssl-users@openssl.org Subject: OpenSSL and DH parameters Hi, When using SSL is it mandatory to specify along with the certificate (chain) and the private key, also the DH parameters ? What's the use for DH parameters when specified to OpenSSL ? Thank you!
Re: OpenSSL: exchanging DH parameters
Hi, I would suggest to have a copy of the same DH params before hand than to exchange during key exchange process because exchanging the key values always exposes you to the man-in-the-middle problem. man-in-the-middle problem. The Diffie-Hellman key exchange is vulnerable to a man-in-the-middle attack. In this attack, an opponent Carol intercepts Alice's public value and sends her own public value to Bob. When Bob transmits his public value, Carol substitutes it with her own and sends it to Alice. Carol and Alice thus agree on one shared key and Carol and Bob agree on another shared key. After this exchange, Carol simply decrypts any messages sent out by Alice or Bob, and then reads and possibly modifies them before re-encrypting with the appropriate key and transmitting them to the other party. This vulnerability is present because Diffie-Hellman key exchange does not authenticate the participants Reference: http://www.hack.gr/users/dij/crypto/overview/diffie.html regards, Prakash Babu www.visolve.com Olia Kerzhner [EMAIL PROTECTED] wrote: Hi all,I have a question about DH parameters. From what Iunderstand, they can either be exchanged during keyexchange, or both Server and Client can have a copy ofthe same DH params before hand.Which way is better -- more efficient and more secure?Since I'm coding both the Server and the Client, Icould easily have a copy available on each.Also, do the DH params ever need to change? In otherwords, is it OK to use the same DH params for years,or is that a security hole?thanks for your help,Olia__Do you Yahoo!?Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakeshttp://hotjobs.sweepstakes.yahoo.com/signingbonus__OpenSSL Project http://www.openssl.orgUser Support Mailing List [EMAIL PROTECTED]Automated List Manager [EMAIL PROTECTED] Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more. Download now.
