E2E networking aids innovation in
distributed computing and
information sharing and helped make
the internet that we know, today
why use onion networking?
• you have a community, or you have an audience
• for some, ability to access content is hampered
• for some, risk of fake websites, credential theft,
or political repercussions for accessing content
• for some, privacy, assurance & trust is paramount
why use onion networking?
• you're building a disintermediated, distributed, E2E tool
• #OnionShare - onionshare.org
• @BriarApp - briarproject.org
• …that IoT home-automation app which you always
wanted to build, but which will suﬀer from NAT,
ﬁrewall, and other security/conﬁg issues…
social value of .onion?
• greater assurance
• facebookcorewwwi.onion => genuine facebook
• greater availability & privacy
• .onion => hard to block/surveil (if sometimes a little ﬂaky)
• fewer digital footprints
• people using onions are perforce using tor browser
• tor browser is generally better at data "hygiene"
tech value of .onion?
<see second half of presentation>
client desktop? mobile?
• Mac / Win / Linux
• tor browser (integrated tor + custom-tuned ﬁrefox)
• orbot (tor) + orfox (browser)
• onion browser (integrated)
what is .onion?
"the top level domain name
for the onion namespace"
what is a namespace?
• namespace is "an address + what it means/looks like"
• ipv4 addresses look like: 192.168.1.1
• ipv6 addresses look like: fe80::226:21ﬀ:fed8:fbc2
• dns addresses look like: www.foo.com
• onion addresses look like: ylzpg2givhwizoep.onion
how do addresses work?
• all these addresses can be typed into a web browser:
• http://192.168.1.1/- ipv4, supported everywhere
• http://[fe80::226:21ﬀ:fed8:fbc2]/ - ipv6, variable
• http://www.foo.com/ - dns, supported everywhere
• http://ylzpu2givhwizoep.onion/ - needs a Tor browser
• …they all connect you to a remote computer
how is .onion unusual?
• "under the bonnet", an onion is a raw network address
• …just like 192.168.1.1 or fe80::226:21ﬀ:fed8:fbc2
• but: formatted like a traditional dns domain name
• ".onion" looks like ".com" or ".co.uk"
• this means browsers treat the addresses equitably
• including subdomains: www.facebookcorewwwi.onion
on a network address?!?
• yes! this would never work with ipv4 …
• www.192.168.1.1 would not mean anything sensible
• but www.facebookcorewwwi.onion is meaningful to HTTP
• …still means facebookcorewwwi.onion
• …the "www." bit is transported in the Host: header
• thus: standard HTTP/HTML/browser behaviour
how do you
• ipv4 addresses: you take what you are given (eg: DHCP)
• ipv6 addresses: ditto (mostly)
• dns addresses: you choose a name, & register it
• …unless someone beats you to it…
• onion addresses: get a random one, or else "mine" one
• more mining => "better quality"
how does it work?
# => random onion address in "hostname" file
HiddenServicePort 22 127.0.0.1:22
ProxyCommand= nc -x localhost:9150 %h %p
# 9150 => builtin SOCKS5 in local TorBrowser
listener port number
what it forwards to
1. dedicated server
• you have a dedicated web server, and it…
• is conﬁgured to know about its onion address
• essentially runs as a standalone service
• perhaps serves duplicate content ?
2. onion-aware CMS
• you have a web server, and it…
• serves content to .com, .co.uk, .in, …
• why not just add yet another domain name?
• tag requests arriving from .onion reverse proxy
• ensure that tagged requests are consistently
responded-to, citing only your onion address(es)
3. onion shim
• you have a web server, and it…
• primarily serves content as (say) nytimes.com
• install a shim between it and the tor reverse proxy…
• shim bidirectionally rewrites requests & responses
• nytimes.com <=> nytimes3xbfgragh.onion
• custom engineering, or EOTK / Enterprise Onion Toolkit
open-source shim for enterprise onions
(or: implement a blend…)
1. dedicated onion server (eg: various SecureDrop sites)
• use-case dependent, probably involves anonymity
2. onion-aware CMS (eg: Facebook)
• excellent for primarily-dynamically-generated content
• modest engineering, ongoing commitment, can be 100% solution
3. onion shim EOTK (eg: NYT)
• onioniﬁes all content, including static or static/dynamic mix
• minimal/zero engineering, some edge cases, 95..99%+ solution
• don't forget to onionify your CDNs where possible
• try to avoid content-leakage between domains
• accidentally wandering-oﬀ to the cleartext/.com site
• e.g. OAuth redirects, tracker embeds…
• use horizontal load-balancing for scale
• free solution: OnionBalance (EOTK supports)
• onions (even via shim) are generally faster for Tor
• you will probably need to buy a special HTTPS cert
• cost: probably from mid $$$ to low $$$$
• plus: associated paperwork & faﬀ
• if you take payments / subscriptions?
• you may want to restrict access to payments over tor?
• payment providers often block tor, this can sometimes
lead to poor user experiences…
How IP→Ethernet Works
• Server: publishes mapping of IP to MAC address
• Gratuitous ARP → populate ARP tables
• Client: resolves mapping of IP to MAC address
• Checks local ARP table (or makes ARP query)
• Client: issues Ethernet frames to MAC address
• Frames transport packets yielding TCP connections
How Onion→IP Works
• Server: publishes mapping of Onion to IP address
• Descriptor Publication → populate HSDir DHT Ring
• Client: resolves mapping of Onion to IP address
• Checks HSDir DHT Ring (source of truth)
• Client: issues TCP connection to Tor relay
• Connections transport Tor cells yielding Tor circuits
1) TCP/IP is the L2
# OSI Name Internet Onion
7 Application https, ssh, etc… https, ssh, etc…
6 Presentation socket* socks5 proxy
5 Session tcp/udp socket* tcp socket via socks5
4 Transport tcp/udp protocol tcp circuit
3 Network packet to IP addr cell to Onion addr
2 Data Link frames/MAC/LLC cells over tcp
1 Physical bit bit
• NAT/Firewalls are not an issue
• Connections pretend to be direct, local-network TCP.
• Services & Ports are published, not ad-hoc/promiscuous
• Onionspace port-scanning is restricted to services
and ports which are published by the owners:
• HiddenServicePort 44422 localhost:22
• "consent-based networking", cf: NSAPs in X.25 ?
Returning to the
• Long-term circuits between client/server are established
• Traﬃc tunnels over circuits
• A bit like X.25 Networking
• sometimes circuits break
• but then, so does TCP (i.e.: RST)
• Circuits may carry multiple TCP/IP streams, be reused
• Presentation: as a SOCKS5 relay
1 server sets up introduction point
2 server publishes descriptor
3 client looks-up descriptor / intro-point
4a client sets up rendez-point
4b client tells server "meet me at rendez-point"
5 data exchanged via circuit via rendez
a safer "Client-Server"
HSDir DHT Ring
nb: all connections established
"outbound" through the ﬁrewall(s);
server can live in "enclave"
"Rendezvous" at L7?
• All this is hidden behind SOCKS5 for app presentation
• Your app thinks that it is talking to a TCP/IP stream
• Truth = more complex
5) Introduction points
• DDoS Resistance
• Harder to hit a moving target, key resources "at 1+ remove"
• Built-in "GSLB" (global server load balancing)
• You have little control of where Introduction, or Rendezvous Points
are created, but they are distributed globally
• Servers can be replicated globally, too; ﬂatness = simpler
• "DNSRR" equivalent (DNS Round Robin)
• "OnionBalance" enables recombination of descriptors, shares load
over servers like DSR (direct server return); or full H/A replicas
• Onion addresses are literally cryptographically-trustable
layer-3 network addresses
• If you type the address correctly, you are guaranteed to be
communicating with someone who has the private key
• Built-in IPsec ESP and AH
• No PSK hassle
• No CA hassle
• No revocation, no X.509, no OpenSSL, no faﬀ…
• Tor is an over-the-top meta-network
• It doesn't care what's happening at the IP layer
If you remember one thing:
• Tor "treats censorship as damage, and routes around it"
• literally its raison d'être…
• Tor is actually pretty good at (eventually) routing around
damage of pretty much any kind, nowadays.
• Wasn't the Internet supposed to do this anyway?
• qv: John Gilmore
• Perhaps we got lazy and stopped aiming for that?
Learning New Stuff
• Tor is not TCP/IP (but feels similar)
• Tor is not an in-kernel network
• userspace daemons with SOCKS5 presentation
• conﬁg ﬁles, not `ifconfig`
• Tor is evolving
• Just like TCP/IP was in 1992
• Short-term test to prove the concept
• Cheap, low resource-usage, borrowed hardware
• Was DoS'd by <some asshole with bots>
• Sustained few-hundreds of hits per second
• Hardly noticeable impact on single quad-core server
summary: why onion?
• build apps, tools, & devices which don't have to fret
about NAT, and which don't need a $$$ central server
• provide additional access, security & safety opportunities
for your audiences & communities!
• cutting-edge, experimental fun!
and ﬁnally: password-protect
onion "network interfaces"?
…yields: the following hostname ﬁle