Switching from helpers to HTTP(S)¶
- Author:
Matt Traudt
- Date:
25 April 2018
- Last Update:
25 April 2018
- Status:
Draft
Some Problems with the sbws helper concept¶
Twice as many things to keep up to date
Finding helper operators
Trusting helper operators
Home-grown protocol (“but it’s totally secure enough for our needs guys, trust me. And it’s totally implemented correctly too.”)
Ways HTTP(S) is less terrible¶
Standard protocols with established security properties
Easier to “set and forget”
- More flexible in deployment set ups
TLS could be optional, but if present, could allow the web server to be far away from any Tor relay
CDNs could be used … maybe (no promises)
Measurements could still be done 1 relay at a time if there’s a way to specify that the web server should be considered right next to a specific relay(s)
Challenges¶
Measuring 2 relays at a time¶
In the current design, it’s easy to see and believe that sbws only measures one relay at a time.
In an sbws deployment that uses HTTP(S) servers far away from any Tor relay, it’s harder or impossible. So we need to measure more than one relay at once. That means we need to come up with a way to select a pair of relays (where one is an exit, most likely) such that one won’t significantly impact the results for the other.
Idea 1:
Pick a first hop relay.
Collect all exits that have a consensus weight equal or higher to the first hop relay. If there are none, collect the single fastest or select the
X
fastest.Pick one of the collected exits in a weighted random fashion based on their consensus weights
Idea 2:
Same as the first, but consider all exits not just the ones faster than the first hop relay.
Supporting many variations on HTTP(S)¶
By this I mean I would love to support all of the following.
sbws scanner option for using an HTTPS CDN across all exits in the network
sbws scanner option for using a specific HTTPS webserver across all exits in the network (might not be any different than the previous item)
sbws scanner option for using a specific HTTP(S) webserver across a specific list of relays (which may or may not have the Exit flag)
in the cases where TLS is used, optional (enabled by default) verification the certificate is valid or at least pinned
in the cases where TLS is used, the optional use of client certificates for identification
Proposals¶
Replace the concepts of “helpers” and “helper relays” and “sbws servers” with “SOMETHING”. “Measurement methods”? “Avenues”? “Destinations”? I’ll call them destinations for now.
Configuration¶
Replace [helpers]
with [destinations]
. If you don’t remember what this
section is for, it’s for enabling/disabling various helpers (or, now
destinations) without removing their config details.
[destinations]
cloudflare_cdn = on
pastly_relay = on
foobar = off
Replace [helpers.foo]
with [destinations.foo]
. If you don’t remember
what these are for, they are sections for each enabled destination that specify
more specific configuration options for them. In the helper relay world, they
had the relay fingerprint, sbws server host and port, and the password to give
the sbws server.
If there is a combination of options that doesn’t make sense, then sbws should fail to start.
If no destinations are configured, sbws should fail to start.
Sbws should run reachability tests on each destination on startup and then periodically and make sure they are usable as configured. It should only use destinations that are usable. If none are usable, it should sleep for a while and test for usability again later.
Available keys in a [destinations.foo]
section:
relays
: a comma-separated list of relay fingerprints that can be used when using this destination. If unspecified, use all relays with the Exit flag. If specified, at least one relay must be usable. If it isn’t, the destination should be considered unusable. (optional)relay_section_method
: one ofuniform_random
orbw_weighted_random
, defaulting to whichever is a sane default (optional)url
: an HTTP or HTTPS URL for the bandwidth file to download. The URL’s hostname must not be resolved locally; instead, it should be left up to the exit relay to resolve. If the URL does not contain a path, it defaults to/sbws.bin
. (required)weight
: when choosing between which destination to use for the next measurement, give this destination the specified weight. If not given, defaults to 100. Note how if no destinations have a weight value, they are chosen uniformly at random. (optional)
If protocol is https, these additional keys are available in a
[destionations.foo]
. It is a fatal configuration error to specify any of
these if protocol is http.
client_cert
: path to certificate to provide to the server. If none provided, server is only usable if it doesn’t require client authentication. If provided and file doesn’t exist, it is a fatal configuration error. If provided and the server doesn’t accept it, the destination is unusable. (optional)verify_server_cert
: either a boolean or a path to a file. If yes (the default), the server’s certificate must be trusted (as determined by the local machine’s configuration outside of sbws). If no, do no verification of the certificate at all. If a path to a file and the file does not exist, it is a fatal configuration error. Otherwise, the certificate the server users must be present in the file pointed to by this option. (optional)
Example: CDN¶
Relays are not specified because we want to choose from all exits in the network.
This CDN provides /sbws.bin
so we are allowed to leave off the file part.
HTTPS for the protocol, and no further HTTPS options because this CDN has a widely-trusted certificate and doesn’t care about only allowing our sbws scanners to download files.
[destinations.cloudflare]
url = https://sbwsrocks.cdn.cloudflare.com/
Example: Private Local Destination¶
Here, an authority has decided he doesn’t want to trust anyone but themself. They are running 2 relays on the same machine as a webserver that only they will use.
This authority chooses to use a client TLS certificate to identify their scanner(s), so their webserver must use HTTPS.
On their webserver they generate a self-signed certificate. On the sbws scanner side, they could choose to assume everything will be okay and his server will not change certificates. But they’re paranoid, so they get a copy of the server’s certificate and store it in a local file.
Todo
What file format?
[destionations.secure_bwauth]
relays = AAAA...AAAA, BBBB...BBBB
relay_section_method = uniform_random
url = https://33.33.33.33:4433/sbws.bin
client_cert = ${paths:sbws_home}/secure_bwauth_scanner.cert
verify_server_cert = ${paths:sbws_home}/secure_bwauth_server.cert
Example: “Borrow” bandwidth from unsuspecting mirrors¶
This could be considered unethical and therefore a terrible non-starter idea.
It’s also a cool thing that I think is technically possible.
Pick a Linux distro that provides ISOs or packages over an HTTP(S) server. Ideally many servers under a single DNS name that rotates. (Maybe even one that is geo-aware to give you a close mirror to where you’re resolving the name.)
Then just find a file big enough to service all of our possible request sizes, and add it to the config.
[destination.unsuspecting_linux]
url = http://examplelinux.net/archive/isos/1.2.3/examplelinux-amd64-gnome-destkop.iso