[tor-bugs] #15035 [Orbot]: URI format for bridges

[Tor Bug Tracker & Wiki]

#15035: URI format for bridges
---------------------------+------------------------------
     Reporter:  eighthave  |      Owner:  n8fr8
         Type:  task       |     Status:  new
     Priority:  normal     |  Milestone:
    Component:  Orbot      |    Version:
   Resolution:             |   Keywords:  uri, url, bridge
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+------------------------------
Description changed by n8fr8:

Old description:

> Right now, according to @n8fr8, this is the URI format for the bridge
> URIs:
>
> `bridge://obfs3+xxx.xxx.xxx.xxx
>
> There is a problem with this format because it doesn't follow the URI RFC
> so that standard URI parsers won't parse it very well.  Adding the `//`
> after `bridge:` makes it a "hierarchical" URI, which means that it has
> the standard sections of authority, user info, host, port, path, query,
> and fragment. But the above URI will just stick all of the text in the
> "authority" part, but that section can't be broken down into the standard
> parts of the "authority", i.e. user info, host, and port.
>
> To keep the same data format, then this URI should be an "opaque" URI.
> That just means removing the `//`.  So that makes it like a `mailto:`
> URI.
>
> Otherwise, the data could be refactored to fit into the standard parts
> for a hierarchical URI, then standard URI parsing classes will be able to
> parse it.  For example, android.net.Uri, java.net.URL, etc.  That would
> make the URI look something like this:
>
> `obfs4://54.66.226.196:18965/95151988dc29fccb4f610a1c700a1ddf7d5ffbd4?cert=3wYo19iAMNbfO7snEeqVBmsIat+RMmMDV5BV4jDvXuz9BaACXt7XffC8Dz8J1MUvLKHKaQ
> &iat-mode=0`
>
> * `getScheme()` would be bridge type
> * `getAuthority()` would be IP and port number
> * `getHost()` would be IP
> * `getPort()` would be port number
> * `getPath()` would be this thing:
> `95151988dc29fccb4f610a1c700a1ddf7d5ffbd4`
> * then `cert=`, `iat-mode=`, etc. would be in the query string
>
> The downside of this approach is that there could only be a single bridge
> per URI, but maybe that's not so bad.

New description:

 Right now, according to @n8fr8, this is the URI format for the bridge
 URIs:

 `bridge://obfs3+xxx.xxx.xxx.xxx

 There is a problem with this format because it doesn't follow the URI RFC
 so that standard URI parsers won't parse it very well.  Adding the `//`
 after `bridge:` makes it a "hierarchical" URI, which means that it has the
 standard sections of authority, user info, host, port, path, query, and
 fragment. But the above URI will just stick all of the text in the
 "authority" part, but that section can't be broken down into the standard
 parts of the "authority", i.e. user info, host, and port.

 To keep the same data format, then this URI should be an "opaque" URI.
 That just means removing the `//`.  So that makes it like a `mailto:` URI.

 Otherwise, the data could be refactored to fit into the standard parts for
 a hierarchical URI, then standard URI parsing classes will be able to
 parse it.  For example, android.net.Uri, java.net.URL, etc.  That would
 make the URI look something like this:

 `obfs4://xx.xx.xxx.xxx:18965/asdasdasldkasjlasjkdd4?cert=3wYasdasdasdasBmsIat+RMmMDV5BV4jDvXuzasdasdasdas8Dz8J1MUvLKHKaQ
 &iat-mode=0`

 * `getScheme()` would be bridge type
 * `getAuthority()` would be IP and port number
 * `getHost()` would be IP
 * `getPort()` would be port number
 * `getPath()` would be this thing:
 `95151988dc29fccb4f610a1c700a1ddf7d5ffbd4`
 * then `cert=`, `iat-mode=`, etc. would be in the query string

 The downside of this approach is that there could only be a single bridge
 per URI, but maybe that's not so bad.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15035#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online