Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Setting Up .Onion Addresses for your Enterprise, v3.5

380 views

Published on

Presentation for NLUUG on 2018-05015

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Setting Up .Onion Addresses for your Enterprise, v3.5

  1. 1. setting up .onion addresses …for your website enterprise v3.5 - @alecmuffett 2018
  2. 2. hi!
  3. 3. BBC Radio 4, circa 2012 <cyber type="ominous"/>
  4. 4. "awesome!"
  5. 5. "dark net" not as scary as advertised
  6. 6. <years n=2/>
  7. 7. <years n=2/>
  8. 8. <downshift/>
  9. 9. <bored/>
  10. 10. why .onion? • 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
  11. 11. 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"
  12. 12. tech value of .onion? <see second half of presentation>
  13. 13. desktop? mobile? both? • Mac / Win / Linux • tor browser (integrated tor + custom-tuned firefox) • Android • orbot (tor) + orfox (browser) • iOS • onion browser (integrated) • other iOS in progress
  14. 14. what is .onion? "the top level domain name for the onion namespace"
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. “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
  19. 19. 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"
  20. 20. howto: arbitrary traffic? 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 listening port number
  21. 21. howto: password-protect
 onion network interfaces? Server: /etc/tor/torrc …yields: the following hostname file
  22. 22. how to serve .onion websites? 3 options…
  23. 23. 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 ?
  24. 24. 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)
  25. 25. 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
  26. 26. 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
  27. 27. 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
  28. 28. nits • 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? • payment providers often block tor, this can sometimes lead to poor user experiences…
  29. 29. TECH?
  30. 30. Onion Networking
 as a Layer-3 Network
  31. 31. 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
  32. 32. 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
  33. 33. Important Takeaways
  34. 34. 1) TCP/IP is the
 L2 "data-link layer" of Onionspace
  35. 35. # 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
  36. 36. 2) Onionspace is flat
  37. 37. Onion-flattyness • 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 ?
  38. 38. (2018 - 1994) + 13 = 37
  39. 39. Returning to the disintermediated
 end-to-end Internet
  40. 40. 3) Onionspace is circuit-switched
  41. 41. 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
  42. 42. 4) Rendezvous,
 not Client-Server
  43. 43. 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
  44. 44. "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
  45. 45. 5) Introduction points have redundancy, transience and migrate globally, leading to…
  46. 46. 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
  47. 47. 6) self-authentication
  48. 48. 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…
  49. 49. 7) …and finally…
  50. 50. BGP-Hijack Resistance • Tor is an over-the-top meta-network • It doesn't much care what's happening at the IP layer
  51. 51. If you remember one thing: • Tor "treats censorship as damage, and routes around it" • literally its raison d'être… • …with all these hostile actors it's actually pretty good at (eventually) routing around damage of any kind. • Wasn't the Internet supposed to do this anyway? • Maybe we just got too used to reliable networks?
  52. 52. The Downsides?
  53. 53. Downside 1:
 latency, lag, circuit drops
  54. 54. "good enough for the right kinds of workload"
  55. 55. Four Major Types Of
 Established Tor Connection Rendezvous Rendezvous TorBrowser MiddleGuard WebsiteExit Rendezvous TorBrowser MiddleGuard Middle1 Guard Onion OnionMiddle1 GuardBrowser Tor2web TorBrowser MiddleGuard Onion Browsing Normal Web Over Tor Browsing Onion Site Over Tor Browsing Onion Site From Normal Client Using Tor2web (bad idea) Browsing Single-Hop Onion Site (Facebook, NYT, …) single hop single hophttp Protected only by HTTPS, if that... Middle2 Middle2 Chosen by Client Chosen by Server nb:TorBrowser is simply
 a normal browser with 
 embedded Tor software nb: Onion site is simply
 a normal website with 
 bonded Tor software
  56. 56. Tor as Web CDN: Normal vs Onion TorBrowser MiddleGuard WebsiteExit RendezvousTorBrowser MiddleGuard Onion CDN Normal Web Over Tor CDN Single-Hop Onion Site Chosen by Client Chosen by Server Website X: exit node to webserver Y: onion to rendezvous Z: link to webserver → congestion shim / revproxyfast Generally: (Y+Z) < X (less is better)
  57. 57. Downside 2:
 Learning New Stuff
  58. 58. Learning New Stuff • Tor is not TCP/IP (but feels similar) • Tor is not an in-kernel network • userspace daemons • config files, not ifconfig • Tor is evolving • Just like TCP/IP was in 1992
  59. 59. Example: Wikipedia
  60. 60. entire config file:
  61. 61. eotk config file
  62. 62. resulting tor config
  63. 63. resulting nginx config
  64. 64. resulting nginx config
  65. 65. experiment works!
  66. 66. then: DoS Attack!
  67. 67. <code/>
  68. 68. fixed (enough)
  69. 69. 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
  70. 70. video:
 performance test
  71. 71. tip: long video, questions welcome…
  72. 72. onion Tor vs: plain Tor
  73. 73. for deck PDF,
 twitter search: from:alecmuffett "nluug slides" ...will be posted later today

×