Changes between Initial Version and Version 1 of Ticket #84


Ignore:
Timestamp:
08/04/2008 11:04:26 PM (16 years ago)
Author:
Brian Warner
Comment:

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

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #84

    • Property Summary changed from RemoteReference.getRemoteTubID is not secure to RemoteReference.getSturdyRef is not secure
  • Ticket #84 – Description

    initial v1  
    1 The getRemoteTubID method (newly introduced in 0.3.0) 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.
     1The getSturdyRef method (which has been present in foolscap since forever) is
     2not yet secure: a malicious remote party can supply an arbitrary string for
     3the URL/sturdyref of each referenceable, and the tubid portion of that string
     4is not validated against the cryptographic connection properties.
    25
    3 I'm not sure that having getRemotetubID is a great idea anyways, but if we have it, it really ought to be secure.
     6(note that the new getRemoteTubID method, introduced in 0.3.0, *is* secure: it is
     7computed from a different place).
    48
    5 The easiest fix will be to get this from the Broker, rather than from the !RemoteReferenceTracker's copy of the per-object FURL.
     9The easiest fix for this will be to validate it during the processing of a
     10my-reference sequence, by comparing it against the broker's remote_tubref.
     11
     12The better long-term fix will be to not include it in the my-reference
     13sequence at all: have the my-reference provide the swissnum, but get the
     14tubid and connection hints from the broker. The tubid is established during
     15negotiation, but this approach will require the connection-hints be set with
     16some other mechanism: perhaps a setMyConnectionHints method on the
     17remote_broker. It would be nice if the hints could change over time and the
     18remote end be updated with current FURLs.
     19
     20It would probably be a good idea to look at !CapTP and see how they handle
     21this. It's closely tied to the three-party-introduction protocol.