Limit available DigestMethods and SigningMethods

Looking at my generated metadata, it seems support is advertised for many different SigningMethods.

<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#ripemd160"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384"/>
<ns1:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/>
<ns1:SigningMethod Algorithm="http,//www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-md5"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha224"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"/>
<ns1:SigningMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/>

It seems this list is generated by checking if each is supported by the xmlsec1 binary. https://github.com/rohe/pysaml2/blob/master/src/saml2/algsupport.py#L36

My concern is that a few of those signing methods here are insecure; for instance MD5. It’s conceivable an assertion could be forged by intercepting a signed assertion and replacing it’s signature with a weaker, cracked one.

Assuming my reasoning isn’t flawed, I think an option to whitelist algorithms would be a good fix here. I also assume it would be more involved than updating SIGNING_METHODS and DIGEST_METHODS via config, as something needs to prevent xmlsec1 from attempting to verify a signature by raising an exception beforehand.

I believe this is a different issue to https://github.com/rohe/pysaml2/pull/396 which (as far as I can tel) affects outgoing assertions only. Is this correct?

I’m not sure if https://github.com/rohe/pysaml2/issues/382 has similar intentions.

Thanks for you time and pysaml2

---

I wonder if the best solution is to simply compile xmlsec1 with a subset of algorithm support: -DXMLSEC_NO_MD5=1"

[c00kiemon5ter]

Hi,

this is something that should be handled by the app (pysaml), not the system (xmlsec might be used by other apps on the same host).

IMO, a configurable blacklist is the correct way to go with this, as one can blacklist old/insecure algs, but automatically be able to use newly supported ones by xmlsec. The opposite would mean that for every update of xmlsec supported algs, a new entry would need to be manually added to the whitelist.

I don’t think this is hard to implement. However there is bigger issue here as discussed in #278 - we shouldn’t be using the xmlsec binary directly, but through bindings. Maybe this issue is good initiative to make that happen too.

[knaperek]

In my opinion, it is nice if pysaml takes its base list of supported algorithms from xmlsec1 - I have nothing against that. But, that doesn’t mean it should automatically allow and list all of them, period. I think it is a valid request for pysaml to accept a custom defined list of algorithms that further filter the default set reported by xmlsec1.