client: stop accepting sigs on the truncated messages (sig fix stage 4) #1526
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.
Rebased on #1530. This PR is just the one final commit 70ec51b
This is stage 4 of the signature message truncation fix plan outlined below.
In these commits, client stops accepting sigs on the truncated messages. All servers must be sending the correct sigs i.e. have deployed the stage 3 of the fix.
Full signature fix plan
In some places we were signing and verifying unhashed messages, resulting in truncation of the data we intend to sign and verify. Because the truncation was performed on both sides, we didn't have errors, but the full payloads were not part of the verified message. This included the signatures created and verified in the main comms (i.e. between
Core
andAuthManager
), as well as in DCR and BTC's backends where coin signatures are used to verify ownership of the coins.Note that in the asset coin sign/verify bits, it is always the client signing coins with their wallet keys, and the server verifying. In other comms, both client and server are generating and verifying signatures.
Also note that all comms are end-to-end encrypted with TLS, and most truncated payloads included unique data anyway. The message payloads and client signatures are also not publicly available data, so it is not straightforward to exploit this bug.
This change includes all the commits that will occur in several stages:
Note that stage 2 also fixes
client/core.(*Core).Register
failing to re-set their own pubkey in themsgjson.RegisterResponse
from the server, where it is omitted from the JSON serialization but included in the binary serialization when the payload is signed.In summary, the server commits should land in 0.4.2 (like today), while the client commits should land in master and later in 0.4.3+.
Lastly, a future commit for 0.5 and the "
V0PURGE
" should be drafted that makes server sign outgoing hashed messages to the clients and stop verifying signatures on truncated data from the client, breaking compatibility with older clients.This approach is proposed to minimize disruption to older clients, delaying the breaking changes to 0.5/1.0 and the great v0 API purge.
Discuss. 馃懙
WARNING: I've not tested this interactively yet.