Hi Adriaan,
Adriaan de Jong wrote:
<snip>
+void
+tls_ctx_load_ecdh_params (struct tls_root_ctx *ctx, const char
*curve_name
+ )
+{
+#ifdef USE_SSL_EC
+ if (curve_name != NULL)
+ {
+ int nid;
+ EC_KEY *ecdh = NULL;
+
+ nid = OBJ_sn2nid(curve_name);
+
+ if (nid == 0)
+ msg(M_SSLERR, "unknown curve name (%s)", curve_name);
+ else
+ {
+ ecdh = EC_KEY_new_by_curve_name(nid);
+ if (ecdh == NULL)
+ msg (M_SSLERR, "Unable to create curve (%s)", curve_name);
+ else
+ {
+ const char *sname;
+
+ if (!SSL_CTX_set_tmp_ecdh(ctx->ctx, ecdh))
+ msg (M_SSLERR, "SSL_CTX_set_tmp_ecdh: cannot add curve");
+
What is happening here exactly? Is the same key being reused for
every
connection, or is it magically regenerated by OpenSSL on every
connection?
the function SSL_CTX_set_tmp_ecdh is very similar to SSL_CTX_set_tmp
(for DH keys).
It adds the curve to the SSL CTX (ConTeXt); this CTX is used only when
negotiating the TLS channel - NOT the data channel. It is updated by
the OpenSSL TLS code automagically.
Thanks, I realise this is just about the control channel. Still: for a server setup, multiple control channels are set up (one for each connection).
What I'm reading here, but that could be a mistake is the following:
1. Determine Curve NID
2. Generate a new DH key based on the curve NID (ecdh =
EC_KEY_new_by_curve_name(nid);)
3. For the global context, set that key as the one be used.
Now, if that is correct, the same key is reused across multiple connections for a server setup.
Again, note that my assumptions here might be incorrect, especially in step 2.
Unfortunately, I can't find decent documentation for the OpenSSL functions.
<snip>
What I'm mostly concerned with is the control channel setup. As I understand
it, there's two steps involved that can use elliptic curve crypto:
1. Authentication using ECDSA/RSA/DSA/whatever
2. Anonymous DH/ECDH negotiation to get a session key
What I'm wondering is, if you use ECDSA, how is the curve for ECDSA set? As I understand it, this patch only sets the ECDH curve and key, not the
The main reason for adding this patch is to allow the use of
certificates which are generated with ECDH keys and which are signed
with a SHA2 family hash; without this patch , this is not allowed.
That's what my question boils down to: isn't ECDSA, not ECDH the
certificate-based part of the algorithm? ECDH is anonymous, isn't it?
Finally one more comment: to be accepted into the main branch, this
needs manpage and command line documentation.
very true... but that applies to more patches ;)
Unfortunately true...
I hope that clarifies my concerns a little. Unfortunately, I haven't found a
good authoritative source for the functionality of SSL_CTX_set_tmp_ecdh. If it
works in a similar manner to SSL_CTX_set_tmp_rsa, then you would need to use
SSL_CTX_set_tmp_ecdh_callback instead to generate a new key for every control
channel (see the ssl_openssl.c code for an example of that).
Your questions are all very valid.
The documentation on these functions is indeed atrocious ... from what
I understood the SSL_CTX_set_tmp_ecdh function is very similar to the
SSL_CTX_set_tmp_dh function; there's also a 'set_tmp_dh_callback'
function which is not used very often, as the DH params are static for a
single server.
If you read the openssl code , file ssl/s3_lib.c and look for
SSL_CTRL_SET_TMP_ECDH then you'll find that the s3_lib.c code does treat
the calls pretty much the same - this leads me to believe that the
SSL_CTX_set_tmp_ecdh_callback function does NOT need to be used. To make
sure I will post a question to the openssl developers on this.
The main reason for adding this function to the openvpn server instance
is to ensure that enough 'ECDH entropy' , for lack of a better word, is
available so that SHA2 message signing is possible. Again, this is my
understanding of things, but I'm about as blind as you are when it comes
to understanding this part of the OpenSSL code base.
HTH,
JJK
