On Tue, Nov 03, 2015 at 09:56:36PM +0100, gregor herrmann wrote:
> On Tue, 03 Nov 2015 20:50:43 +0100, Kurt Roeckx wrote:
>
> > You really only ever want to use SSLv23_client_method() since that
> > is the only one that supports multiple versions. I suggest you
> > modify your nossl2.patch to just replace all of the above by:
> > ctx = SSL_CTX_new(SSLv23_client_method());
> >
> > ssl_version would then become an unused variable.
> >
> > Just like SSLv2 has already been removed, SSLv3 is now also
> > removed because it's insecure.
>
> Some findings:
> - nossl2.patch doesn't exist anymore in git, since it was merged
> upstream, and we have 0.72 in git but never uploaded due to some
> packaging glitches (and then the freeze)
> - 0.72 is the last upstream release and contains this code
> - upstream has in the meantime changed it in a dev release on the
> CPAN (0.73_04) [0] and in git [1]:
>
> [0]
> https://metacpan.org/diff/file?target=NANIS%2FCrypt-SSLeay-0.73_04%2F&source=NANIS%2FCrypt-SSLeay-0.72%2F#SSLeay.xs
> [1] https://github.com/nanis/Crypt-SSLeay/blob/0.73_04/SSLeay.xs
>
>
> 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?
Kurt
