[Shib-Users] Force SSLv3

[Kristof BAJNOK]

Hi,

I've been trying to force curl to use SSLv3 only, without success. I have a
strange metadata source that is only available on https and ssl handshake
fails:

2009-12-29 16:10:54 ERROR XMLTooling.libcurl.NetAccessor : curl NetAccessor
encountered error from libcurl (35)
2009-12-29 16:10:54 ERROR XMLTooling.ParserPool : fatal error on line 0,
column 0, message: An exception occurred! Type:NetAccessorException,
Message:Internal Error on NetAccessor

After doing an ssldump, I noticed that it's related to the ssl version being
used

ClientHello
Version 3.1
[snip]
1 2 0.0872 (0.0421) S>C Alert
level fatal
value unexpected_message

Manually running curl -3 works, ssldump follows:
ClientHello
Version 3.0
[snip]
ServerHello
Version 3.0

I've tried to set TransportOption 32 to 3 but it seems to have no effect
(these are the magic numbers I've figured out from curl.h). Should this affect
metadata retrieval, I mean, is it a SOAP request in that sense? How should
it be done right?

(After writing all the above, I've tried it with my PC's newer libcurl, and
it worked even with TLSv1, all the older curl's require the -3 switch
though. This makes me think that it's a libcurl issue, however it'd be good
to be able to force SSLv3 only.)

Thanks,
Kristof

[Scott Cantor]

Kristof BAJNOK wrote on 2009-12-29:
> I've tried to set TransportOption 32 to 3 but it seems to have no
> effect (these are the magic numbers I've figured out from curl.h).
> Should this affect metadata retrieval, I mean, is it a SOAP request in
> that sense? How should it be done right?

Well, if you're using a supported version and you put the TransportOption
into the MetadataProvider it might work, but I think the workarounds that
deal with a number of openssl bugs probably end up superseding that
particular option. I no longer try to set the SSL version with curl, I just
disable SSLv2 directly in openssl, among other broken features.

It could be that overriding the SSL cipher suite string and including !SSLv3
might work, but I wouldn't be surprised if the workarounds defeat that too.

> (After writing all the above, I've tried it with my PC's newer libcurl,
and
> it worked even with TLSv1, all the older curl's require the -3 switch
> though. This makes me think that it's a libcurl issue, however it'd be
good
> to be able to force SSLv3 only.)

It's really not good, that's the lesson I've learned. It's a losing game.

-- Scott

[Kristof BAJNOK]

On Tuesday 29 December 2009 18.50.21 Scott Cantor wrote:
> Well, if you're using a supported version

Sorry for the noise.
I was on Debian Lenny's 2.0. Checked it with another machine with 2.2.1, and
it worked, while curl CLI still not being able to connect.

> and you put the TransportOption
> into the MetadataProvider it might work,

Wow. I should've checked it in some of the more recent xsd's.

> but I think the workarounds that
> deal with a number of openssl bugs probably end up superseding that
> particular option. I no longer try to set the SSL version with curl, I
> just disable SSLv2 directly in openssl, among other broken features.

Good to know, thanks.

Kristof

[Scott Cantor]

Kristof BAJNOK wrote on 2009-12-30:
> On Tuesday 29 December 2009 18.50.21 Scott Cantor wrote:
>> Well, if you're using a supported version
>
> Sorry for the noise.
> I was on Debian Lenny's 2.0. Checked it with another machine with 2.2.1,
and
> it worked, while curl CLI still not being able to connect.

Oh, that's far out of date then. There are TransportOption bugs until
probably 2.3, and SSL glitches all through the releases until somewhere past
2.1.

>> and you put the TransportOption
>> into the MetadataProvider it might work,
>
> Wow. I should've checked it in some of the more recent xsd's.

I don't use schemas for the plugins like the IdP does, you can't tell unless
you look at the documentation.

-- Scott