regression: Policy server signatures are applied too aggressively #1815
Labels
No labels
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity#1815
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As of #1487, policy server checks are applied too aggressively. In #offtopic, my server has resolved the current policy server state event to the one pointing at
asgard.chat, not correctlycontinuwuity.org. ellis.link is getting signatures from continuwuity.org, but my server doesn't care, since as far as it is concerned, .org isn't the policy server. It is then asking asgard.chat for a signature on the fly, which is correct behaviour, and doesn't get one back as the room is not protected by that server anymore. However, the unexpected behaviour is that this then fails a signature check, which is weird, because there isn't a signature to check? This then results in the event being soft-failed and/or not upgraded from an outlier to timeline event.potential problem area:
handle_policy_server_errorreturns a fail-openOk(()), indicating that the request was "allowed" by the policy server:| StatusCode::NOT_FOUND => {debug_info!(via = %via,event_id = %pdu.event_id(),%room_id,"Policy server is not actually a policy server or is not protecting this room: {}",error.message());Ok(())However,
policy_server_allows_eventexpects an error to be returned if there was no signature. This would cause the event to be soft-failed as it was "rejected" as "spam", however when it does not receive an error, it assumes the event was signed, and always callsverify_policy_signaturewith the expected policy server data (which we have established isn't correct in this scenario):self.fetch_policy_server_signature(pdu, pdu_json, &ps.via, outgoing, room_id, ps_key, 0).await?;// Verify that the policy server signature was made with the same public key as// is in the state event, not just that it was signed.if verify_policy_signature(&ps.via, ps_key, pdu_json, &room_version_rules.redaction) {Ok(())} else {Err(Error::Request(ErrorKind::Unknown,"Policy server signature was made with a different key to the one advertised".into(),StatusCode::BAD_GATEWAY,))}to further note:
policy_server_allows_eventprobably shouldn't return that differing-key error when checking incoming events, it should return forbidden instead, so that the event gets soft failed instead of left as an outlier, per server-server § 27.2 Validating Policy Server signatures. The "key differs" M_UNKNOWN is meant to prevent us creating events that fail that check, not persisting incoming ones.