[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15035 [Applications/Orbot]: URI format for bridges
#15035: URI format for bridges
--------------------------------+-----------------------
Reporter: eighthave | Owner: n8fr8
Type: task | Status: new
Priority: Medium | Milestone:
Component: Applications/Orbot | Version:
Severity: Normal | Resolution:
Keywords: uri, url, bridge | Actual Points:
Parent ID: #28015 | Points:
Reviewer: | Sponsor:
--------------------------------+-----------------------
Comment (by eighthave):
Here's an outline of the possible URI formats for bridges:
{{{
Bridge meek_lite 0.0.2.0:2 97700DFE9F483596DDA6264C4D7DF7641E1E39CE
url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com
bridge://meek_lite@0.0.2.0:2/97700DFE9F483596DDA6264C4D7DF7641E1E39CE?url=https%3A//meek.azureedge.net/&front=ajax.aspnetcdn.com
http://bridge.onion/97700DFE9F483596DDA6264C4D7DF7641E1E39CE?transport=meek_lite&ip=0.0.2.0&port=2&url=https%3A//meek.azureedge.net/&front=ajax.aspnetcdn.com
https://bridges.torproject.org/97700DFE9F483596DDA6264C4D7DF7641E1E39CE?transport=meek_lite&ip=0.0.2.0&port=2&url=https%3A//meek.azureedge.net/&front=ajax.aspnetcdn.com
Bridge obfs4 104.224.78.19:443 FD9DAEE45A2FDF70D462914A75ADE99A29957920
cert=LSOd9qOffpIFM4az+ueou7sY0eQRAsI/joW4QgCl/LSDo2ecQzAQHNu281oAivLDZuTQNA
iat-mode=0
bridge://obfs4@104.224.78.19:443/FD9DAEE45A2FDF70D462914A75ADE99A29957920?cert=LSOd9qOffpIFM4az%2Bueou7sY0eQRAsI%2FjoW4QgCl/LSDo2ecQzAQHNu281oAivLDZuTQNA
&iat-mode=0
http://bridge.onion/FD9DAEE45A2FDF70D462914A75ADE99A29957920?transport=obfs4&ip=104.224.78.19&port=443&cert=LSOd9qOffpIFM4az%2Bueou7sY0eQRAsI%2FjoW4QgCl/LSDo2ecQzAQHNu281oAivLDZuTQNA
&iat-mode=0
https://bridges.torproject.org/FD9DAEE45A2FDF70D462914A75ADE99A29957920?transport=obfs4&ip=104.224.78.19&port=443&cert=LSOd9qOffpIFM4az%2Bueou7sY0eQRAsI%2FjoW4QgCl/LSDo2ecQzAQHNu281oAivLDZuTQNA
&iat-mode=0
}}}
**bridge: link for use in-app**
The most popular custom scheme that I can think of are `magnet:` links for
torrents. They are a very similar idea as a bridge link. So we should be
able to use BitTorrent apps on all platfroms as an example of how to
handle these links. Using a custom URI scheme makes it easier to make a
link that the browser will never handle, and always look for an app to
send it too. Also, using a custom URI Scheme like `bridge:` means that
clicking these URIs in apps is much less likely to ever go to another app,
since those apps would have to have specifically created the association.
Also, browser let you specific custom handlers for URI Schemes they do not
understand. These can be specified to closely match the `Bridge` lines in
''torrc''. So this collection of fake bridges:
In desktop Firefox, you can add support for bridge: URIs by adding a
custom "Protocol Handler":
1. load about:config
2. Right-click -> New -> Boolean -> Name: ''network.protocol-
handler.expose.bridge'' -> Value -> ''false''
3. Next time you click a link of protocol-type ''bridge'' you will be
asked which application to open it with.
Chromium on Ubuntu will automatically prompt to open with `xdg-open`.
That will then use the standard, cross-distro XDG methods for registering
and using custom schemes that are used in GNOME, KDE, etc. etc. Tor
Browser's ''.desktop'' file should be able to do this. Any Debian/etc.
package can install and configure the ''.desktop'' files and XDG Mime
stuff as part of the package install. Here's a manual example:
{{{
$ cp bridge-url-writer.py /tmp/
$ chmod 0755 /tmp/bridge-url-writer.py
$ mkdir ~/.local/share/applications/
$ cp bridge-url-writer.desktop ~/.local/share/applications/
$ sudo update-desktop-database
$ xdg-mime default bridge-url-writer.desktop x-scheme-handler/bridge
}}}
There are similar mechanisms on Windows and MacOS. For example MacOS has
the `open` util which does was GNU/Linux's `xdg-open` does.
**http: link with fake domain name**
One problem with having the bridge link clickable and having a real domain
name is that it could leak info to the internet that the user is looking
for a bridge. So there could be a fake domain name for these links to
provide a pattern to match for in things like the OS-level URL matchers in
Android and iOS. Something like `http://bridge.onion/` will never exist
but is somehow a reserved domain name. These links would then
automatically show up as clickable on desktop and mobile apps, but should
never cause network traffic.
his will lead to confusing failures since the browser will say
"bridge.onion’s server IP address could not be found."
** https: link with real domain name, like ChatSecure**
Using a real domain name like `https://bridges.torproject.org` provides a
way to provide the user direct feedback when they are trying to add a
bridge via URL. If the user clicks on a bridge URL and it fails to go to
Tor Browser, then they'll see the page on `bridges.torproject.org`. If
the config information is included in the query string, then
`bridges.torproject.org` can automatically generate a proper `bridge:`
URI, which the user can click to send the info out of the browser. The
page can also provide a HOWTO for setting up `bridge:` support for their
OS.
ChatSecure's invite links have a nice feature in that Android and iOS will
automatically route them to the ChatSecure app, even if they are clicked
in the browser. Then if the Zom app is not installed, the link will open
up in the browser with instructions on how to get Zom and use the links.
With these links, the data is included in the URI Fragment, (e.g. stuff
after `#`) which should never be sent to the network. That protects
privacy, but makes it harder for the server to provide useful feedback.
Here is an example URI:
{{{
https://chatsecure.org/i/#YWhkdmRqZW5kYmRicmVpQGR1a2dvLmNvbT9vdHI9M0EyN0FDODZBRkVGOENGMDlEOTAyMEQwNTJBNzNGMUVGMEQyOUI2Rg
}}}
Android has this method of registering a domain name as the official
domain name that is tied to the app. It has the nice feature that any
link with that domain name will go straight to the matching app, and not
be sent to other apps. It does require some setup on the web server. The
big downside is that it only works if that app only claims links with that
domain name and nothing else. We tried using this in F-Droid, but did not
want to give up claiming `market:` and `https://play.google.com` links.
They are known as "Android App Links". iOS also has this, they are known
as "Apple Universal Links".
** Use URL-safe base64!!**
Right now, the data is encoded in standard base64, which means it had to
be encoded and decoded to work in URIs. It would be better to switch to
URL-safe base64 (RFC4648), which replaces the use of the chars **+** and
**/** with **-** and **_**. This is because and **_**. **+** and **/**
have special meaning in URIs. I don't know what all this entails, so for
now, the URL generation will need to know to URL-encode **+**, **/**, and
**=**. (e.g. **%2B**, **%2F**, and **%3D**). Just encoding **+** is often
enough, since **/** often works fine in a URL query string value, and the
base64 padding character **=** does not seem to be often used in bridge
configs.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15035#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs