Crossbar.io supports WAMP over Tor

, meejah

Overview

Crossbar.io is a "router" for the WAMP Publish/Subscribe (PubSub) and Remote Procedure Call (RPC) protocol, enabling the connection of components in distributed applications. Tor is a network of machines run by volunteers which work as an overlay network to provide location-anonymity while using the Internet (i.e. a Tor user's IP address remains hidden from the services they access). Tor also has "Onion services" which provide location-anonymity (among other security features) for services (e.g. Web servers). In this post we discuss why Crossbar supports Tor and what benefits users get from that support.

If you are interested in more technical details and a concrete use-case, I have blogged about this topic on the Tor blog ("Secure Messaging with Onion Services, a How-To") and on my own blog ("End-to-End Encrypted RPC/PubSub over Tor").

A Brief Overview of Tor

The Tor Project provides an overlay network that hides the network location of TCP streams. At the core of this is a program called tor which volunteers run on well-connected internet servers. These computers are then called "a Tor relay". Users of the network also run this program and connect to Tor's Directory Authorities to find out where all the relays are. A Tor client then selects a 3-hop route ("a circuit"). This uses layers of cryptography which each relay "unwraps", giving it a subsequent relay or final Internet destination and a payload. Thus each relay only knows who connected to it and to whom it is connecting (for that circuit). So the first relay can see where on the Internet a user is and the third (last) relay can see where on the Internet the traffic is going to (the middle relay just sees traffic coming from and going to other Tor relays).

This means that the user's network location is not known to the ultimate destination server (but the server knows the request came "from Tor"). It also means the user's final destination is not known to the first relay. For more details on how this functions, you should read Tor's overview.

For the "server" side, a somewhat similar process is followed (with a few extra wrinkles). A Tor client creates an Onion service by creating a key-pair, selecting some "Introduction Points" and publishing "a Descriptor" to certain relays on the Tor network. The Introduction Points are where clients "meet" the service so they can't learn where on the Internet the Onion service is. Clients find out about these by downloading Descriptors (and verifying they're valid). Part of this verification is that the .onion hostname is related to the key-pair (so that only someone holding the private key can sign the corresponding Descriptor). See Tor's documentation on onions for more information on how this process works.

This setup brings some extra security properties, discussed in the next section.

Security Benefits of Using Onion Services

Using .onion services give some security advantages -- and in fact, you may run an Onion service in "non-anonymous" mode if you don't care about location anonymity, but do want these security benefits (this involves fewer relays and so can be faster).

There is an idea called Zooko's Triangle which says there are three desirable traits for names in network protocols -- "human-meaningful", "secure" and "decentralized" -- but that you may have only two of these at a time. Onion services give you "secure" and "decentralized" at the expense of "human-meaningful".

Let's look at the security benefits:

verifiable hostnames: as the hostname is tied directly to the key-pair that is required to sign valid Descriptors, you can be sure that you've downloaded the very Descriptor that corresponds to that name. Obviously, if the person running the site lost control of their private key others could be impersonating the site -- but this is true for "normal" HTTPS certificates, too.

end-to-end encryption: without leaving the Tor network at all, you get end-to-end encrypted TCP communication directly to the Tor client of the Onion service operator. This is similar to HTTPS services except that those rely on centralized (and "trusted") Certificate Authorities.

"outbound only" connections for the sever: The only network service the Onion machine needs to operate is a Tor client, which makes outbound connections to Tor relays. This means you may restrict that machine to only make outbound connections. (The machine can still be attacked by malicious users via Tor if those users have the .onion address -- but not via random actors on the Internet as with most Web servers).

These benefits don't come for free. Onion service hostnames (ending in .onion) are not designed for humans to memorize. Further, routing TCP connections via several other machines (as Tor does) results in lower bandwidth and latency than a "normal" direct connection.

Benefits for Crossbar.io Users

All of the above are immediate benefits for various use-cases in Crossbar.io. As support is built-in, you can simply add an endpoint configured to appear via an Onion service. Keys are kept in the .crossbar directory (by default) so re-starting your router maintains the same Onion address.

Clients can connect via this address and be assured they're getting to the correct Crossbar instance (e.g. no DNS poisoning attacks are possible).

A Crossbar instance listing as an Onion service can be running on an otherwise "not visible to the Internet" machine (such as behind a NAT device or firewall).

Because WAMP is distributed, important services could be running on further locked-down (and separate) machines, connecting to the Crossbar instance via local-only IPs. Thus, a malicious actor would have to: obtain the onion URI; break into the Crossbar.io router via Tor; and then leverage this to gain access to the "important service" (which could itself be on a machine that allows no incoming connections). Adding two non-trivial steps an attacker needs to do is a significant security benefit ("defense in depth").

Summary

Adding Tor support in Crossbar.io was very straightforward because of the clean separation between "transports" and other layers of the router.

Being able to use Tor easily and securely with Crossbar is a nice security and deployment upgrade for users that can take advantage of it. On the downside, Tor is generally slower than "plain" Internet and can be more complex to set up.

Recent posts

Atom Feed

Search this Site

Community Support Forums