RemoteReference.getSturdyRef is not secure

[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.

[Brian Warner]

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

[Brian Warner]

Done, in [062e476f71b32828280dcbd207ca6beeec0eab66], by comparing the proposed FURL against the inbound Broker's tubid and rejecting any mismatch.