fix: do not propagate unsigned encrypted messages #5129
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AaronFeickert
force-pushed
the
message-failure-refactor
branch
from
cc23bd7
to
85d3e02
Compare
sdbondi
approved these changes
Jan 20, 2023
stringhandler
pushed a commit
that referenced
this pull request
Jan 31, 2023
Description --- Bans peers who send empty encrypted messages. Significantly updates tests to check for more failure modes and assert ban status for each. Closes [issue 5132](#5132). Motivation and Context --- An [earlier PR](#5123) introduces an error when a peer sends an empty encrypted message, which is not allowed. However, the peer was not banned. Further, [another PR](#5129) updates the handling of unsigned encrypted messages to ensure that bans are done correctly, but does not update tests to check for the bug that led to it. This PR updates the banning logic to ban a peer who forwards an empty encrypted message, which is always detectable. It also significantly refactors and updates tests. For each relevant high-level message failure mode, we test for proper error detection. We also check for the proper ban status of the forwarding peer. How Has This Been Tested? --- [Who tests the testers?](https://en.wikipedia.org/wiki/Quis_custodiet_ipsos_custodes%3F)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Updates message handling to detect and prevent propagation of unsigned encrypted messages. Minor refactoring for clarity and efficiency. Improves comments.
See this issue for more on banning logic.
Motivation and Context
Encrypted messages must include an encrypted signature that verifies the sender and prevents malleability. Currently, this is only checked after an encrypted message reaches its recipient. If the recipient sees that the message does not include a signature, it will ban its forwarding peer. This is technically correct behavior on the part of the recipient, since either the forwarding peer rendered the message invalid, or itself forwarded a known invalid message. However, the forwarding peer will propagate such an invalid message due to the location of this check; even if it is honest, it will be banned as malicious.
This PR moves the check for the presence of an encrypted signature to the initial verification checks, so it will be caught before being propagated and ensure a ban is performed correctly. It also does some minor refactoring to avoid unnecessary computations, and improves comments.
How Has This Been Tested?
Existing tests pass.