Shibboleth SP SSL3_GET_RECORD wrong version number

[Cantor, Scott]

On 6/4/12 10:44 PM, "Coeus[TM]" <coeus.ph at gmail.com> wrote:
>
>But we cannot afford to modify our setup, at this point, since the
>problem only occurs for this Idp only and having said that the SP
>is using the default libcurl settings.

I wasn't suggesting which end should change anything, merely that it's an
issue below the level of any project code, apart from the cipher suites
set by the SP:

"ALL:!aNULL:!LOW:!EXPORT:!SSLv2"

That's all pretty standard. The IdP end is Apache, so it's outside the
scope of the IdP and up to the deployer.

One thing you can't do is override this per-IdP in the SP. You can slap a
new option in to override it globally, but that's it.

The IdP end of course can push attributes and solve the problem that way.

>Lastly, I have tried issuing this command below (via 3 servers, includes
>the two from my previous post - the production and test SPs):
>
>openssl s_client -connect idp.test.org:8443 -ssl3
>
>and received the same error as below:

That would suggest they've blocked all but TLS, I guess. I assume it works
if you specify -tls1. That's not a default Apache choice.

I also happened to take a look at the recent libcurl versions. So far, no
sign they've done anything complicated to handle TLS 1.1 and 1.2, and I
don't know if that's going to break stuff at some point. Our use of TLS is
not vulnerable to the BEAST attack, so I haven't been paying close
attention. It's possible this will get worse at some point. That's yet
more reason we're trying to avoid the back channel.

-- Scott