On 15.09.2013 13:17, Dr Stephen Henson wrote: > > A couple of comments. > > For DH you can get improved server performance by using the length or subprime > q. This isn't well supported in currently released versions of OpenSSL > unfortunately. > > For OpenSSL 1.0 and earlier the dh->length parameter can be set. For 1.0.1 and > later the subprime value 'q' can be used too (q is included in the structure > for > previous versions of OpenSSL but not used). The current master branch of > OpenSSL > supports use of X9.42 DH parameters from a file, that functionality will > probably be back ported to (unreleased) 1.0.2. > > So I'd suggest using parameters where you can set both q and length.
Thanks. At this time, I was rather focusing on how to configure the DHE parameters, and less on their specific values. If we would take the RFC 5114 values (like OpenSSL 1.0.2 does), then we have values for q. dh->length is set to BN_num_bits(r->q) when a DSA struct is converted into a DH struct (DSA_dup_DH()), but I'm not familiar enough with the underlying crypto to tell whether this approach is feasible in all cases? > For ECDH and released versions of OpenSSL the best that can be currently done > is > to set the parameters in the server and hope the client supports them (via > supported curves extension): if not then ECDSA/ECDH wont be negotiated at all. > Use of P-256 is usually safe for this. > > For OpenSSL 1.0.2 you can just call: > > SSL_CTX_set_ecdh_auto(ctx, 1); > > and the most appropriate curve is used automatically. > > The proposed change doesn't permit finer control of EC parameters: e.g. if it > is > desired to use non-default curve preferences. I think you missed the code after the "Similarly, try to read the ECDHE curve name from SSLCertificateFile" in part 2 of the patch. This allows you to configure a curve other than P-256 (either global or per vhost). > While this can be done explicitly > at the Apache level I'd suggest instead that the SSL_CONF support code is > backported instead: which supports a lot more. If there's anything I can do to > help with that let me know. Long term, that's certainly the better option. Being able to configure a list of curve names would probably be useful (from which OpenSSL would then pick the first which intersects with the elliptic_curves extension from the ClientHello). Kaspar
