Opened 16 years ago

Last modified 16 years ago

#84 closed defect

RemoteReference.getSturdyRef is not secure — at Version 1

Reported by: Brian Warner Owned by:
Priority: critical Milestone: 0.4.0
Component: unknown Version: 0.2.9
Keywords: Cc:

Description (last modified by Brian Warner)

The getSturdyRef method (which has been present in foolscap since forever) is not yet secure: a malicious remote party can supply an arbitrary string for the URL/sturdyref of each referenceable, and the tubid portion of that string is not validated against the cryptographic connection properties.

(note that the new getRemoteTubID method, introduced in 0.3.0, *is* secure: it is computed from a different place).

The easiest fix for this will be to validate it during the processing of a my-reference sequence, by comparing it against the broker's remote_tubref.

The better long-term fix will be to not include it in the my-reference sequence at all: have the my-reference provide the swissnum, but get the tubid and connection hints from the broker. The tubid is established during negotiation, but this approach will require the connection-hints be set with some other mechanism: perhaps a setMyConnectionHints method on the remote_broker. It would be nice if the hints could change over time and the remote end be updated with current FURLs.

It would probably be a good idea to look at !CapTP and see how they handle this. It's closely tied to the three-party-introduction protocol.

Change History (1)

comment:1 Changed 16 years ago by Brian Warner

Description: modified (diff)
Summary: RemoteReference.getRemoteTubID is not secureRemoteReference.getSturdyRef is not secure

updated: getRemoteTubID now *is* secure, so change this ticket to be about the insecurity of the much older getSturdyRef()

Note: See TracTickets for help on using tickets.