Bug#803975: libcrypt-ssleay-perl: Uses SSLv3_client_method()

[Kurt Roeckx]

On Fri, Nov 06, 2015 at 05:48:32PM +0100, gregor herrmann wrote:
> On Tue, 03 Nov 2015 22:35:10 +0100, Kurt Roeckx wrote:
> 
> > On Tue, Nov 03, 2015 at 10:33:21PM +0100, Kurt Roeckx wrote:
> > > On Tue, Nov 03, 2015 at 09:56:36PM +0100, gregor herrmann wrote:
> 
> > > > At a quick glance this looks good, since there's only
> > > > SSLv23_client_method() left. What confuses me a bit is
> > > > - in the .xs file the allow_sslv3 variable
> > > > - in the .pm file the HTTPS_VERSION environmen variable.
> > > 
> > > Since jessie SSLv23_client_method() doesn't support SSLv3 anymore,
> > > SSLv2 was removed before.  So "allow_sslv3" doesn't make sense, at
> > > least in Debian.  If you really wanted to allow SSLv3 the proper
> > > way to do that was by default set the option SSL_OP_NO_SSLv3 (and
> > > SSL_OP_NO_SSLv2) and then don't set SSL_OP_NO_SSLv3 when it's
> > > allowed.  That would be with the SSL_{CTX_}set_options function.
> > > 
> > > The code still seems to have a reference to the library when it
> > > was called ssleay and when TLS didn't exist, at least the version
> > > I looked at, and so seems to pick between SSLv2 and SSLv3.
> > > 
> > > HTTPS_VERSION seems really weird.  There is also a
> > > $DEFAULT_VERSION set to 23 which then makes it use SSLv3, and
> > > setting it to 3 makes it use SSLv2?
> > 
> > There is this text:
> > SSL versions
> >     "Crypt::SSLeay" tries very hard to connect to *any* SSL web server
> >     accomodating servers that are buggy, old or simply not
> >     standards-compliant. To this effect, this module will try SSL
> >     connections in this order:
> > 
> >     SSL v23
> >         should allow v2 and v3 servers to pick their best type
> > 
> >     SSL v3
> >         best connection type
> > 
> >     SSL v2
> >         old connection type
> > 
> >     Unfortunately, some servers seem not to handle a reconnect to SSL v3
> >     after a failed connect of SSL v23 is tried, so you may set before using
> >     LWP or Net::SSL:
> > 
> >         $ENV{HTTPS_VERSION} = 3;
> > 
> >     to force a version 3 SSL connection first. At this time only a version 2
> >     SSL connection will be tried after this, as the connection attempt order
> >     remains unchanged by this setting.
> 
> Thanks for taking the time to look into this.
> 
> I have to admit that I'm still not completely sure if/how this
> affects us packaging-wise. My current understanding is, that the
> library would allow to set SSLv3 via HTTPS_VERSION which will fail
> now on Debian but that it should just work fine with the default
> values. Is this correct?
> 
> If yes I guess we can just take 0.73_04 as is and everything should
> work. (Or maybe we want to patch the documentation to say that SSLv3
> won't work anymore on Debian.)
> 
> In any case I've imported 0.73_04 as 0.73.04-1 and pushed it to
> Alioth.

I'm not sure I understand the question.  So let me try to explain
it from the OpenSSL side.

There are functions like SSLv2_client_method(), SSLv1_client_method(),
TLSv1_client_method().  Those are version specific method that
will only talk that protocol.

Then there is SSLv23_client_method(), which supports multiple
protocol versions.  Behind the scenes ones a protocol version is
selected it will switch the method to one of those others.

The SSLv2_* functions have been removed in Debian in 1.0.0c-2, it
they were never in any 1.* version in unstable.  At that time the
SSLv23_* method also stopped supporting SSLv2.  So that's the case
in wheezy en jessie, but squeeze still has it.

Before the jessie release SSLv3 also got disabled, but only in the
SSLv23_* methods.  That is, the SSLv3_* methods still exists and
you can still create SSLv3 connections with it, but you can't
anymore using the SSLv23_* methods.

Now those SSLv3_* methods have also been removed, completly
removing any SSLv3 (and SSLv2) support.

People should in general stop using the version specific methods
and instead use the SSLv23_* methods.  (It was renamed to
TLS_*_method in openssl's master branch, to avoid confusion.)

There might have been problems a long time ago where talking to a
v2 server didn't work when using a v3 client hello.  This is why
at least in 0.9.8 the client hello that was send with a "SSLv2
compatible" client hello.  It indicated support for SSLv3 but an
SSLv2 *should* be able to understand it.

But there have been many cases of "version intolerance" where
indicating support for a higher version than the server supports
resulted in an error.  I'm guessing that's why perl has this version
rollback mechanism.  But you really shouldn't be doing that, it
can be used in a "version rollback attack" where the attacker can
force you to use a lower version even tough both sides support a
newer version.  If you really want to do that, you should tell
OpenSSL that you're actually doing that using: SSL_set_mode(s,
SSL_MODE_SEND_FALLBACK_SCSV).  It's not perfect, but it's better
than nothing.  You also might want to look at CVE-2014-3566
(POODLE), which is the reason SSLv3 is being disabled and why this
SSL_MODE_SEND_FALLBACK_SCSV workaround has been added.

So my recommendation is to only ever use the SSLv23_* (or TLS_*)
methods, never any version specific method.

If you want to limit the supported ciphers you can use things like
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and so on to disable those
protocol version.  Or you might want to provide options to disable
TLS 1.2 by using SSL_OP_NO_TLSv1_2, but I would not recommend
that.

So I would suggest to only have the SSLv23_* method, remove the
fallback mechanism.  I see no real need to try and add options to
disable protocols, but would disable SSLv2 and SSLv3 by default.

I hope this helps.


Kurt