Setting up an .onion address allows websites to be accessed through the Tor network in order to provide greater privacy, security, and accessibility for users. There are several options for serving content on .onion addresses, including creating a dedicated onion site, configuring content management systems to be onion-aware, or installing an onion shim to rewrite requests and responses between a normal website and its onion domain. Considerations for onionifying a website include certifications, content leakage prevention, and whether to restrict certain features like payments over Tor.

1. setting up a
.onion address
…for your website
v1.5 - @alecmuffett 2017

2. why .onion?
• you have an audience, or you have a community
• 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

3. how does onion help?
• greater assurance
• facebookcorewwwi.onion => genuine facebook
• greater availability
• .onion => hard to block, hard to monitor
• fewer digital footprints
• people using onions are perforce using tor browser
• tor browser is generally better at data "hygiene"

5. mobile ux? yes!
• mac / win / linux
• tor browser (integrated)
• android
• orbot (tor) + orfox (browser)
• ios
• onion browser
• other ios in progress

7. so: what is .onion?
top level domain name for the "onion" namespace

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

9. 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 tor browser
• …they all connect you to a remote computer

10. 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: it is 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

11. wait, 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

12. how do you
choose addresses?
• ipv4 addresses: you take what you are given (mostly)
• ipv6 addresses: ditto
• dns addresses: you choose a name, & register it
• …unless someone beats you to it…
• onion addresses: you "mine" one, a little like bitcoin
• more mining => "better quality" address

13. how to serve .onion?
several options:
1. set up a dedicated website with duplicate content
• e.g.: various dedicated onion sites
2. make your CMS aware of ".onion" domain/traffic
• e.g.: facebook
3. install an onion shim
• e.g.: propublica, new york times

14. 1. dedicated server
• hypothetical: you have a separate web server, and it…
• is configured to know about its onion address
• serves duplicate content where necessary
• essentially runs as a standalone service

15. 2. onion-aware CMS
• hypothetical: you have a web server, and it…
• serves content to .com, .co.uk, .za, .in, …
• distinct content for each domain / different URLs
• why not just add yet another domain name?
• tag all requests arriving from your .onion
• ensure that such tagged requests are properly
responded-to, citing your onion address(es)

16. 3. onion shim
• hypothetical: you have a web server, and it…
• primarily serves content as (say) nytimes.com
• install a shim between it and tor
• which bidirectionally rewrites requests & responses
• nytimes.com <=> nytimes3xbfgragh.onion
• via custom engineering, or Enterprise Onion Toolkit
(free, libre, open-source toolkit for enterprise onions)

17. summary
(or: blend these together...)
1. dedicated onion site
• rare, use-case dependent
2. onion-aware CMS
• excellent for primarily-dynamically-generated content
• modest engineering, ongoing commitment, can be 100% solution
3. onion shim
• onionifies all content, including static or static/dynamic mix
• minimal/zero engineering, some edge cases, 95..99%+ solution

18. notes
• don't forget to onionify your CDN where possible
• try to avoid content-leakage between domains
• accidentally wandering-off to the .com site
• e.g. OAuth redirects
• use horizontal load-balancing for backend scale
• free solution (onionbalance) exists
• onions (even via rewriting) are astonishingly efficient

19. finally
• you will almost certainly 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?
• chiefly because payment providers sometimes block
tor, and this can lead to poor user experiences…

20. summary
• this is an evolving environment!
• provide additional access, security & safety opportunities
for your audiences & communities!
• cutting-edge experimental fun!