Hi Scott,<div><br></div><div>Ok, so our ApplicationDefaults element in shibboleth2.xml looks like this:</div><div><br></div><div><div>&lt;ApplicationDefaults id=&quot;default&quot; policyId=&quot;default&quot;</div><div>        entityID=&quot;<a href="https://www.dev.careverge.com/shibboleth-sp">https://www.dev.careverge.com/shibboleth-sp</a>&quot;</div>
<div>        homeURL=&quot;<a href="https://www.dev.careverge.com">https://www.dev.careverge.com</a>&quot;</div><div>        REMOTE_USER=&quot;eppn persistent-id targeted-id&quot;</div><div>        signing=&quot;false&quot; encryption=&quot;false&quot;&gt;</div>
<div><br></div><div>But this is in the metadata they gave us:</div><div><br></div><div>&lt;md:IDPSSODescriptor WantAuthnRequestsSigned=&quot;true&quot; protocolSupportEnumeration=&quot;urn:oasis:names:tc:SAML:2.0:protocol&quot;&gt;</div>
<div><br></div><div>So I am guessing they are forcing us to sign our requests.  I will see what sort of hell we will have to go through to get them to turn that off (we are very small, they are very big).</div><div><br></div>
<div>Given that we are on a downleveled version of both Shibboleth and Ubuntu, will dropping in the patched version of libxml-security help us close the security hole or will we need to upgrade everything.</div><div><br></div>
<div>Thanks, </div><div><br></div><div>Rob</div><br><div class="gmail_quote">On Fri, Jul 13, 2012 at 11:56 AM, Cantor, Scott <span dir="ltr">&lt;<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 7/13/12 10:07 AM, &quot;Rob Whitener&quot; &lt;<a href="mailto:rob.whitener@audaxhealth.com">rob.whitener@audaxhealth.com</a>&gt; wrote:<br>

&gt;<br>
&gt;I believe the version of libxml-security we are using is 15.0.1 :<br>
<br>
</div>Well, that&#39;s vulnerable to the bug I was talking about, not that I<br>
necessarily think that&#39;s the cause unless your key is extremely large.<br>
<br>
But you can&#39;t be using packages that have security holes. Unless you know<br>
that these include backported patches like Debian&#39;s do, your system is<br>
vulnerable to remote exploit anyway because there are more serious bugs in<br>
the rest of the stack in V2.3.<br>
<div class="im"><br>
&gt;The key we are using is 1675 bytes including the begin and end<br>
&gt;delimitters, and its RSA.<br>
<br>
</div>That&#39;s not the key size I mean, the issue is the size in bits of the<br>
modulus.<br>
<div class="im"><br>
&gt;Also, I am going to try attaching the debugger to try and get a stack<br>
&gt;trace, but first I thought I would try out the simple route of turning<br>
&gt;off the signing to see if that solves it.  If I remove this element:<br>
&gt;<br>
&gt;&lt;PolicyRule type=&quot;XMLSigning&quot; errorFatal=&quot;true&quot;/&gt;<br>
&gt;<br>
&gt;from my &lt;Policy&gt; element, is that what turns off the signing?<br>
<br>
</div>No, that turns off verification. Which is somewhat moot because a<br>
non-patched 2.3 SP is open to signature wrapping attack anyway, as<br>
described in the advisory we issued.<br>
<br>
Turning off signing requires changing the signing property in the<br>
shibboleth2.xml file or adjusting the IdP&#39;s metadata to turn off the<br>
wantAuthnRequestSigned flag.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>