wiki:org/meetings/2017Montreal/Notes/IntegratingOnions

Paul S session notes, nine people at start ~1430, 20171012

  • Onion space v the broader internet
  • "subdomain onions"
  • ease of migration and use of onion sites from regular ones
  • based on an upcoming four year project
  • GSA for testbed for govt sites

  • goal: in 8-10 years, onion sites viewed at https site today
  • Trac ticket: onions everywhere like PS's paper name
  • maintain the onion protocols yet redirected like https everywhere
  • usability questions, rulesets v custom rules
  • TLS integration with onion protocol: reusing the keys for the purposes

of binding even with self-signed certificate, even if "authority not recognized" yet

  • YURLs
  • embedding authentication in the URL
  • right now: onion URLs with ed certs
  • alt name with $hash.TLD
  • relation with Zooko's Triangle:
  • reconciling public common DNS, etc with onion world
  • tor2web no protections
  • single-onion use-case
  • TLS certs for .onion addresses
  • Q: is it single direction? A:
  • can be just a regular onion site, or can be "bridged" in a sense
  • www server .well_known for redirection to .onion
  • Q: what is the big picture?
  • usability, but an infrastructure
  • little change for current TB users
  • ease of setting up a .onion site, remove complexity for www admins
  • instead of in the domain name.... but rather as an alt-name
  • in the understood domain name, with appropriate checks
  • not trusting the CA?
  • .onion and TLS keys all valid?
  • what's the attack?
  • TB -> www site public -> alt-service header conveys .onion available
  • a rogue CA
  • there is an evidence trail but can't thrwart compromise
  • HTTPSE an easier issue to resolve, but how do you do without 'baking'

into each client software (eg, www browser)

  • staging it with first phase to the end-game
  • then the alternative solution:
  • fake certificate
  • threat scenario?
  • onion.theintercept.org => checks the cert for alt-name|whatever =>

.onion site

  • stages of implementation
  • ppl freaking out with http redirections
  • wildcard certs and Let's Encrypt
  • loudflare's single cert per massively shared IP
  • TLD cert with .onion alt name

sub of a sub

what can we do now and what can we do later

  • HTTPSE canned solution with rule-based redirection

HSTS bit limit

  • then other idea: TB check .favicon *and* for .well_known and then redirect

(TB-focused solution therefore easy to implement

reasons not to redirect to the .onion, therefore pseudo-TLD (ie, onion.)

comparing public www v .onion to HTTP and HTTPS

how HTTPSE works now, json file, with multiple update channels: updating the list versus updating the extension itself

auditable as an end-goal?

maintenance of .onion site

autoredirect proposal: does it make sense

trade-offs: not like HTTPSE with minimal performance impact

Xsocialnetworksite knows you're using Tor

privacy is about choice, so no to autoredirect?

http < https is easy, public < .onion/https isn't necessarily

defaults matter

nothing stops a www admin from issuing a 302 redirect to .onion site

babysteps: FF extension?

authentication and redirection solved

.well_known, alt-service header on / top level

current FF directs, or NoScript, or TB "browser res" warnings

roadmap:

from / load alt-service with auto-redirect as TB option?

(current scenario is that TCP destination can easily know if source is public Tor IP. What if that changes)

Last modified 3 months ago Last modified on Oct 17, 2017, 8:02:47 PM