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