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

gregor herrmann gregoa at debian.org
Fri Nov 6 16:48:32 UTC 2015


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.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Ludwig Hirsch: Nicht küssen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital Signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20151106/3a805009/attachment.sig>


More information about the pkg-perl-maintainers mailing list