Outlining the hows and whys of using Onion Networking to connect apps, devices and tools securely over the Internet, without suffering blocks, NAT issues, or many forms of security woe.

1. why and how to use
onion networking
v3.7 - @alecmuffett 2018

2. Two things about
the old Internet:

3. 1) in the beginning, all
Internet communication
was "End-to-End" (E2E)

4. E2E is a bit like P2P
except that
there are only two of you

5. …if you only have two ends,
it's a rope, not a net or mesh

7. A
B

8. A
B

9. NO FIREWALLS
B
A

10. B
A
NO INTERMEDIARIES

11. direct connections

12. no "men in the middle"

13. no impediments to
communication

14. it works!

15. let's not talk about
network security
in that era…

16. SECONDLY:

17. 2) …command-names
were embarrassing:

18. /usr/ucb/finger

19. $ finger root
PROBABLY VERY BAD TO SAY IN AUSTRALIA

21. Finger protocol
ran on TCP port 79

22. (port) 79 + 1 = (port) 80
Coincidence? I don't think so...

23. create content

24. content visible to entire network
= personal expression
opportunity

25. proto-blogging

27. https://garbagecollected.org/2017/10/24/the-carmack-plan/

28. proto-flash-animation

31. glib assertion:
E2E networking aids innovation in
distributed computing and
information sharing and helped make
the internet that we know, today

32. 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

33. why use onion networking?
• you're building a disintermediated, distributed, E2E tool
• examples:
• #OnionShare - onionshare.org
• @BriarApp - briarproject.org
• …that IoT home-automation app which you always
wanted to build, but which will suffer from NAT,
firewall, and other security/config issues…

34. adoption?

38. https://perfectoid.space
https://blog.cloudflare.com/welcome-hidden-resolver/
Cloudflare

39. it's not the "dark"
web any more

40. social value of .onion?
• greater assurance
• facebookcorewwwi.onion => genuine facebook
• greater availability & privacy
• .onion => hard to block/surveil (if sometimes a little flaky)
• fewer digital footprints
• people using onions are perforce using tor browser
• tor browser is generally better at data "hygiene"

41. tech value of .onion?
<see second half of presentation>

42. client desktop? mobile?
• Mac / Win / Linux
• tor browser (integrated tor + custom-tuned firefox)
• Android
• orbot (tor) + orfox (browser)
• iOS
• onion browser (integrated)

44. My Tor Development Environment

45. what is .onion?
"the top level domain name
for the onion namespace"

46. 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:21ff:fed8:fbc2
• dns addresses look like: www.foo.com
• onion addresses look like: ylzpg2givhwizoep.onion

47. 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:21ff: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

48. how is .onion unusual?
• "under the bonnet", an onion is a raw network address
• …just like 192.168.1.1 or fe80::226:21ff: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

49. “subdomains”
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

50. how do you
choose addresses?
• 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"

51. how does it work?
HiddenServiceDir /var/lib/tor/onion-1
# => random onion address in "hostname" file
HiddenServicePort 22 127.0.0.1:22
Server: /etc/tor/torrc
Host my-onion
HostName xxxxxxxxxxxxxxxx.onion
ProxyCommand= nc -x localhost:9150 %h %p
# 9150 => builtin SOCKS5 in local TorBrowser
Client: ~/.ssh/config
software-defined
listener port number
what it forwards to

52. how to serve
.onion websites?
3 options…

53. 1. dedicated server
• you have a dedicated web server, and it…
• is configured to know about its onion address
• essentially runs as a standalone service
• perhaps serves duplicate content ?

54. 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)

55. 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

56. examples
(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)
• onionifies all content, including static or static/dynamic mix
• minimal/zero engineering, some edge cases, 95..99%+ solution

57. implementation tips
• don't forget to onionify your CDNs where possible
• try to avoid content-leakage between domains
• accidentally wandering-off 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

58. https nits
• you will probably need to buy a special HTTPS cert
• cost: probably from mid $$$ to low $$$$
• plus: associated paperwork & faff
• 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…

59. TECH?

60. Onion Networking
as a Layer-3 Network

61. 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

62. 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

63. Important Takeaways

64. 1) TCP/IP is the L2
"data-link layer"
of Onionspace

65. # 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

66. 2) Onionspace is E2E
("End-to-End")

67. Onion-E2E-ness
• 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 ?

68. Returning to the
disintermediated
end-to-end Internet

69. 3) Onionspace is
circuit-switched

70. Circuit-switchyness
• Long-term circuits between client/server are established
• Traffic 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

71. 4) Rendezvous,
not Client-Server

72. 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
"Rendezvous",
a safer "Client-Server"
Server
HSDir DHT Ring
Client
Introduction Point
Tor
"Cloud"
2
1
4b
3
4a5
Rendezvous Point
nb: all connections established
"outbound" through the firewall(s);
server can live in "enclave"
firewallfirewall

73. "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

74. 5) Introduction points
have redundancy,
transience and
migrate globally,
leading to…

75. high-availabilityness (H/A)
• 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; flatness = 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

76. 6) self-authentication

77. self-authenticatingness
• 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 faff…

78. 7) Internet Separation

79. BGP-Hijack Resistance
• Tor is an over-the-top meta-network
• It doesn't care what's happening at the IP layer

80. 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?

81. The Downsides?

82. Downside 1:
latency, lag, circuit drops

83. "good enough for the
right kinds of workload"

84. Downside 2:
Learning New Stuff

85. Learning New Stuff
• Tor is not TCP/IP (but feels similar)
• Tor is not an in-kernel network
• userspace daemons with SOCKS5 presentation
• config files, not `ifconfig`
• Tor is evolving
• Just like TCP/IP was in 1992

86. Example: Wikipedia

87. entire
config
file

88. experiment works!

89. Wikipedia Experiment
• Why?
• 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

90. 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!

91. and finally: password-protect
onion "network interfaces"?
Server: /etc/tor/torrc
…yields: the following hostname file

92. @alecmuffett