Christophe Fergeau píše v St 27. 11. 2013 v 17:48 +0100:
> On Wed, Nov 27, 2013 at 05:39:31PM +0100, David Jaša wrote:
> > From fe1531dfae23baa6dfc8b88e08f273906196e1c5 Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?David=20Ja=C5=A1a?= <djasa@xxxxxxxxxx>
> > Date: Wed, 27 Nov 2013 17:04:41 +0100
> > Subject: [PATCH] Use TLS version 1.0 or better
> >
> > When creating a TLS socket, both spice-server and spice-gtk currently
> > call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
> > protocol version to TLS 1.0 exclusively. The correct way to support
> > multiple protocol versions is to call SSLv23_method() in spite of its
> > scary name. This method will enable all protocol versions deemed secure
> > by openssl project.
>
> This is not what the manpage says
>
> SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
>
> A TLS/SSL connection established with these methods will understand
> the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello
> messages and will indicate that it also understands SSLv3 and TLSv1. A server
> will understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best
> choice when compatibility is a concern.
>
> (nothing about protocol versions deemed secure or not secure)
Actually the documentation is outdated and the method name is
misleading. I was pointed to this fact by Tomáš Mráz, an openssl
developer and Fedora/RHEL maintainer. The thing works as described by
comit message and comment, the test results confirm it.
David
>
> > ---
> > server/reds.c | 10 +++++++++-
> > 1 files changed, 9 insertions(+), 1 deletions(-)
> >
> > diff --git a/server/reds.c b/server/reds.c
> > index 2a0002b..fef666d 100644
> > --- a/server/reds.c
> > +++ b/server/reds.c
> > @@ -3221,6 +3221,14 @@ static int reds_init_ssl(void)
> > SSL_METHOD *ssl_method;
> > #endif
> > int return_code;
> > + /* When some other SSL/TLS version becomes obsolete, add it to this
> > + * variable.
> > + *
> > + * Note that SSLv23_method() even with no SSL_OP_NO_* options uses
> > + * just protocol versions deemed secure by openssl project so the
> > + * SSL_OP_NO_SSLv2 is already redundant
>
> Same comment
>
> > + * and SSL_OP_NO_SSLv3 option is
> > + * present just in order to allow only currently-availabe version or
>
> s/availabe/available
>
> > + * better. */
> > long ssl_options = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
> >
> > /* Global system initialization*/
> > @@ -3228,7 +3236,7 @@ static int reds_init_ssl(void)
> > SSL_load_error_strings();
> >
> > /* Create our context*/
> > - ssl_method = TLSv1_method();
> > + ssl_method = SSLv23_method();
> > reds->ctx = SSL_CTX_new(ssl_method);
> > if (!reds->ctx) {
> > spice_warning("Could not allocate new SSL context");
>
>
>
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
--
David Jaša, RHCE
SPICE QE based in Brno
GPG Key: 22C33E24
Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel