julien51
commented
6 years ago In practice the signature probably does not need to be as strong as implied here. In other words, I do not think it is such a big deal that sha1 (or others) are cracked.
Here's my thinking. The signature is used to ensure the "provenance" of the notification. The subscriber uses it to guarantee that the notification is coming from the hub.
Since the signature is a HMAC made with both the secret AND the content, in order to "impersonate" the hub, an attacker would have to then know BOTH the secret AND the content.
Since we recommend (strongly) that subscribers use https, the whole request from the hub to the hub is encrypted, meaning that the content AND the signature themselves cannot be read by the attacker.
So, in order to actually impersonate the hub, someone would have to first break HTTPs to read the signature AND THEN create a body which would have the same HMAC signature. It is possible, of course, but becomes less and less plausible and makes this less "critical" in the short term and I would be in favor of not messing with existing implementation.
However, in the long term, however I think this is right:
I think the long term solution is to allow the subscription to include "hub.hash_algorithms: x", where x is a comma-separated list of names from https://www.w3.org/TR/WebCryptoAPI/#sha-registration or its successors. Subscribers use that to say which algorithms they can validate, then the hub can use the best implemented one of those in sending to that subscriber. This can be added at any time in the future.
aaronpk
How should hubs decide which hash algorithm to use in signing? SHA-1 may be breakable in practice soon (see SHAttered) but how can a hub know which subscribers can do verification with the other ones? Should hubs just assume subscribers can verify sha-256?
The spec avoids saying clients MUST implement all four algorithms, although it's kind of implied. But (1) requesting signing is optional, and (2) checking signatures is also optional. So I see why the requirement to implement all four was left out.
Even if we solved that, what happens when SHA-1, SHA-256, SHA-384, and SHA-512 are all too weak? How can a hub know which subscribers implement whatever new algorithm comes along? Until the hub switches to some new algorithm, it'll be less insecure than some customers want. On the day it does switch, all the subscribers who haven't yet upgraded will break, leaving other customers quite unhappy.
I think the long term solution is to allow the subscription to include "hub.hash_algorithms: x", where x is a comma-separated list of names from https://www.w3.org/TR/WebCryptoAPI/#sha-registration or its successors. Subscribers use that to say which algorithms they can validate, then the hub can use the best implemented one of those in sending to that subscriber. This can be added at any time in the future.
Short term, I see the implementation report showing three hubs (Superfeedr, Mastodon, and Google) send SHA-1 while two others (Promulgate and Switchboard) send SHA-256. That makes me think there are probably subscribers that only understand SHA-1. Does anyone have data about that? The validation suite hasn't been checking that, I guess. @julien51 would you be hesitant to switch Superfeedr to SHA-256 for fear of breaking subscribers? I'll assume so.
Given that, I suggest for now we change https://www.w3.org/TR/2017/CR-websub-20170411/#recognized-algorithm-names :
remove:
replace with:
Another issue for the longer-term pile is what to call the algorithms in the X-Hub-Signature header. FIPS, IETF, and W3C Web Crypto agree on naming like "SHA-1", but pubsubhubbub used "sha1", and this spec has been saying sha256, sha386, and sha512 for a few months, so it's a mess. My best hack idea is that the hub should re-use whatever name the subscriber used in hub.hash_algorithms, and for its own comparison, it ignores case and hyphens. That should work, I think, at some cost in hub complexity.