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 11 months ago Last modified on Oct 17, 2017, 8:02:47 PM