Defaults to RSA-SHA1 as signing algorithm
Description
Environment
Activity
I’m not that shocked, but the obvious fix didn’t change the algorithm in testing.
ETA: Ugh, Windows no longer detects when shibd binds to a port when shibd is already running. Lovely. The obvious fix did in fact work.
For my purposes later, the bug I spotted that I assume is the cause is in the XMLSignatureImpl class in xmltooling, one of the two marshallers doesn’t have the SHA-2 conditional.
I assume the code base must just end up calling that one instead of the Document-based one that does have it.
No, that’s what I expected. Also why it’s gone unnoticed, signing is rare and post is relatively rare.
I was testing signed authn requests with the POST binding, it looked like this with no explicit sp config and no algorithm list in the idm metadata:
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<ds:Reference URI="#_97d29e8f685e11b9cf62e8dd225f2815">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<ds:DigestValue>mBMUj/mrrsbu/Oyud8ZexLAlF6XefjTPAwwszNNvZ7M=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>Interestingly, the exact same config but using the redirect binding does use RSA-SHA256 by default:
SAMLRequest: fZLRTsIwFIZfZek9tNskjIYtQbiQBHVh0wtvTLcdXJOunT0d6Ns7GCrGhNv29PvP/6VzFI1q+aJztd7CewfovI9GaeSni5h0VnMjUCLXogHkruTZ4n7DgzHjrTXOlEYRb4EI1kmjl0Zj14DNwO5lCU/bTUxq51rklGI7qmA/bov6ICyMS9PQrJZFYRS4eoxo6JEc0PQxy4m36leRWhyhvwhZ/Wf0Z7TfZCcVnAFbqKSF0tEseyTeehWT1zCczoIJMFaxSrAyLMNiMvWL2XQi2I5FUT+G2MFaoxPaxSRgwc2IRSN/lgcB9yM+CV6Il54L30pdSf123U4xDCG/y/N0NJR6BounQv0ASeZHx/wUbC+sX8eKb9UkuSIWf8TO6UXKENnyhx67XqVGyfLTWyhlDksLwkFMfEKT4cnfX5F8AQ==
RelayState: cookie:1724105932_9936
SigAlg: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
Signature: oIyeSIvLKVyfNcmiE2LnxQbe75HMSbXY3SxY4Mz21ALs8A+c6FWI4R/klJ2+a7b555uqE4YR3ulkVJOHghunZx3Bew2sF1poiqkx36HA69gut3jbM2h/Ouix8xWkH3LM9NmMpQM03oBe3zHBJWlftPd4hxJdCP9At/BGflIXvM9RAjhjxRVbDOKNxao+rQEsjlDZfc0/NgnjlMnYRYKiwtFgm71c7Ap8LcjgY100A7VLSJjT1mJka0KVDolv+xc780lU8vKUk0dXuvfcUrMO+zKPYTJFHBwcv6/gimLta4lGkrG+AztUQJPnzOMtyPCaPVS22hJ69QJJXmluoclfXrO6lmitVIeQ7S4uGqqpLkLdi09D1rubKjgiklFVgkiReeseS1H65UNgnvkqb0KtVWpDSho+WHROZSrb6yx0Y+2ikiEHhUD0w6GEaWd/aa4nVCoXuAR9O1qCui9t6PI81ngRY1Wb6Rhv12smUVu1QXOHV29INrs822HeOWQ84dpZWhich seems the opposite of what you were thinking but <shrug>?
Did you notice if this is XML signing only or also redirects? I looked and I think the latter should definitely be SHA1.
The documentation for ApplicationsDefaults (https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2063695997/ApplicationDefaults) indicates the default signing/digest algorithms are RSA-SHA256 and SHA256, but the documentation for RelyingParty (https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065334363/RelyingParty) indicates the default signing/digest algorithms are RSA-SHA1 and SHA1.
Empirically, for an SP not specifying either attribute working with an
idp without the algsupport extension in its metadata, it appears to use
RSA-SHA1 as the signature algorithm and SHA256 for the digest algorithm.
Given SHA1 is deprecated, ideally the SP signing algorithm default can be updated to RSA-SHA256 and the RelyingParty documentation fixed.
Per the mailing list (http://shibboleth.net/pipermail/users/2024-August/055340.html) this might be an issue in a library.