jcnelson
commented
3 years ago We use the HTTP module to serve block and microblock data, and to handle RESTful API requests.
Regarding the former use-case for block/microblock transmission, the peer already knows the hash of the blocks it fetches, and validates them against these hashes in src/net/downloads.rs.
- Blocks are validated against their hashes here: https://github.com/trailofbits/x-audit-blockstack-core/blob/master/src/net/download.rs#L385
- Microblock streams are validated against the parent block they build on here: https://github.com/trailofbits/x-audit-blockstack-core/blob/master/src/net/download.rs#L1268. This verifies that the microblock stream is descended from the Stacks block, is connected to another Stacks block, and is well-formed -- each microblock is signed by a public key whose hash was in its parent Stacks block (preventing a man-in-the-middle from corrupting the stream). The consensus rules additionally ensure that all Stacks blocks have unique microblock-signing keys within their fork.
Now, a man-in-the-middle could truncate a microblock stream while ensuring that the microblocks (and its underlying packet representation) are still well-formed, but this attack is detected by the above validation code.
Alice has access to network traffic between Bob and his peers. Alice can read the content of his Bob's messages, selectively choose to drop them based off of the content, and/or alter replies.
Alice reading the blocks and microblocks Bob downloads is not a concern -- this is public data. In fact, we deliberately avoided TLS in order to make it trivial for CDNs and proxies to cache block and microblock data (which is desirable, since it improves the availability of the blockchain data). Alice cannot trick Bob into accepting corrupt blocks and microblocks, nor can she trick him into accepting a truncated microblock stream due to these extra checks. If Alice is able to corrupt a block or microblock request/response sent between Bob and some remote node Charlie, then HTTPS isn't going to help Bob make progress in processing the blockchain -- Alice can disrupt a TLS packet stream just as easily as a non-TLS packet stream.
The remaining RESTful API endpoints are used by clients of the Stacks blockchain, such as explorers and wallets. Explorers and other "heavy" consumers of this API are expected to run a node locally anyway to improve access latency, obviating the need for TLS. When we deploy the Stacks node as an API endpoint for consumption by downstream clients who do not run their own nodes (like wallets), we put it behind a Nginx server that proxies all data over TLS.
ESultanik
Description
Peer URLs and data URLs are validated using
util/strings.rs:https://github.com/trailofbits/x-audit-blockstack-core/blob/d35ef465e9fa2ce327a181117f8ca7933b9df075/src/util/strings.rs#L286-L316
This validation code allows both http and https URLs, and is used for
data_urls in peer messaging.Moreover,
StacksHTTPMessages are not signed, and their validation is a no-op:https://github.com/trailofbits/x-audit-blockstack-core/blob/d35ef465e9fa2ce327a181117f8ca7933b9df075/src/net/http.rs#L2596-L2600
Exploit Scenario
Alice has access to network traffic between Bob and his peers. Alice can read the content of his Bob's messages, selectively choose to drop them based off of the content, and/or alter replies.
Recommendations
Enforce a messaging protocol that guarantees data integrity, e.g., by tunneling the Stacks HTTP protocol over TLS.