> > As I'm sure you know, security often involves multiple layers. At the
> > time, the OpenSSL method table we used was still one that would allow
> > fallback to SSLv3.
>
> You refer to using ssl23_client_method()? That function's name is really
> bad because it is the only one that allows negociation of the highest
> protocol available
Not any more. Currently, SSLv23_method is deprecated, and TLS_method is
the preferred way to get multi-version negotiation. Which brings us to
exactly the "compatibility with decade-old versions" morass I mentioned
earlier. Apparently[1] this is the proper initialization sequence as of
a week ago.
#if (OPENSSL_VERSION_NUMBER >= 0x10100000L)
ssl_ctx = SSL_CTX_new(TLS_client_method());
#else
ssl_ctx = SSL_CTX_new(SSLv23_client_method());
#endif
Then we need to apply SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3, assuming
those in turn are defined. If they're not, we should probably fail
altogether. With that done, we could recalculate the default
cipher list to include CBC but not DH. Would we still need to add
code for generating our own DH parameters (and/or allowing users to
do so)?
[1] http://marc.info/?l=openssl-dev&m=143205142609793&w=2
> But SSL_OP_NO_SSLv2 and SSL_OP_NO_SSLv3 options for
> SSL_CTX_set_options() are there to make sure it does cannot happen. At
> least this is how it is fixed in all software I have been looking at.
I don't mean to be snarky here, but it seems like you've spent more
time studying OpenSSL usage across multiple versions and projects than
it would have taken to write a patch. Is that an indictment of our
overly burdensome patch-submission process, or something else? What
can we do to improve this?
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
