XMLTooling - C++

 
50 of 142

Defaults to RSA-SHA1 as signing algorithm

Fixed

Description

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.

Environment

None

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Created August 19, 2024 at 9:50 PM
Updated October 16, 2024 at 4:47 PM
Resolved September 9, 2024 at 5:14 PM

Activity

Scott Cantor 
September 9, 2024 at 4:37 PM
(edited)

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.

Scott Cantor 
August 20, 2024 at 12:07 PM

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.

Scott Cantor 
August 19, 2024 at 11:49 PM
(edited)

No, that’s what I expected. Also why it’s gone unnoticed, signing is rare and post is relatively rare.

Paul B. Henson 
August 19, 2024 at 10:24 PM

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/aa4nVCoXuAR9O1qCui9t6PI81ngRY1Wb6Rhv12smUVu1QXOHV29INrs822HeOWQ84dpZ

Which seems the opposite of what you were thinking but <shrug>?

Scott Cantor 
August 19, 2024 at 9:54 PM

Did you notice if this is XML signing only or also redirects? I looked and I think the latter should definitely be SHA1.