...
With the change from version 0.9.8l, renegotiation is blocked entirely. With version 0.9.8m, a new TLS extension is supported that re-enabled renegotiation if the server is also patched with support for the extension. A future version of the The SP will also include now includes an option to re-enable "unsafe" renegotiation if version 0.9.8m or newer is used, but this is not currently available.
At the IdP end, there are more moving parts because it depends on the web server in use and possibly the OpenSSL version, if Apache+mod_ssl is involved. Newer versions of Tomcat and other Java web servers may include patches that block unsafe renegotiation, or include support for the extension or re-enabling the unsafe code. The latest Apache+mod_ssl patches disable unsafe renegotiation by default, but include a new SSLInsecureRenegotiation option to re-enable it. They also support the TLS extension that allows supporting versions of OpenSSL to work properly regardless.
...
If you're an SP and are affected by this problem, there's not much you can do other than to downgrade to unpatched OpenSSL code . There's no programmatic option at this time to re-enable the original behavior on newer versionsor use a new enough OpenSSL version to allow for the workaround.
If no other work-around is available, an SP deployer may be able to re-establish connectivity by disabling TLS client authentication and enabling signing, if the IdP supports this option. This is achieved by creating a <RelyingParty> element for the IdP like so:
...