Changes between Initial Version and Version 1 of org/meetings/2017Montreal/Notes/IntegratingOnions


Ignore:
Timestamp:
Oct 17, 2017, 8:02:47 PM (19 months ago)
Author:
alison
Comment:

added notes

Legend:

Unmodified
Added
Removed
Modified
  • org/meetings/2017Montreal/Notes/IntegratingOnions

    v1 v1  
     1Paul S session notes, nine people at start
     2~1430, 20171012
     3
     4* Onion space v the broader internet
     5
     6* "subdomain onions"
     7
     8* ease of migration and use of onion sites from regular ones
     9
     10* based on an upcoming four year project
     11
     12* GSA for testbed for govt sites
     13
     14****
     15
     16* goal: in 8-10 years, onion sites viewed at https site today
     17
     18* Trac ticket: onions everywhere like PS's paper name
     19
     20* maintain the onion protocols yet redirected like https everywhere
     21
     22* usability questions, rulesets v custom rules
     23
     24* TLS integration with onion protocol: reusing the keys for the purposes
     25of binding even with self-signed certificate, even if "authority not
     26recognized" yet
     27
     28* YURLs
     29
     30* embedding authentication in the URL
     31
     32* right now: onion URLs with ed certs
     33
     34* alt name with $hash.TLD
     35
     36* relation with Zooko's Triangle:
     37
     38* reconciling public common DNS, etc with onion world
     39
     40* tor2web no protections
     41
     42* single-onion use-case
     43
     44* TLS certs for .onion addresses
     45
     46* Q: is it single direction? A:
     47
     48* can be just a regular onion site, or can be "bridged" in a sense
     49
     50* www server .well_known for redirection to .onion
     51
     52* Q: what is the big picture?
     53
     54* usability, but an infrastructure
     55
     56* little change for current TB users
     57
     58* ease of setting up a .onion site, remove complexity for www admins
     59
     60
     61* instead of in the domain name.... but rather as an alt-name
     62
     63* in the understood domain name, with appropriate checks
     64
     65* not trusting the CA?
     66
     67* .onion and TLS keys all valid?
     68
     69* what's the attack?
     70
     71* TB -> www site public -> alt-service header conveys .onion available
     72
     73* a rogue CA
     74
     75* there is an evidence trail but can't thrwart compromise
     76
     77* HTTPSE an easier issue to resolve, but how do you do without 'baking'
     78into each client software (eg, www browser)
     79
     80* staging it with first phase to the end-game
     81
     82* then the alternative solution:
     83
     84* fake certificate
     85
     86* threat scenario?
     87
     88* onion.theintercept.org => checks the cert for alt-name|whatever =>
     89.onion site
     90
     91* stages of implementation
     92
     93* ppl freaking out with http redirections
     94
     95* wildcard certs and Let's Encrypt
     96
     97* loudflare's single cert per massively shared IP
     98
     99* TLD cert with .onion alt name
     100
     101sub of a sub
     102
     103what can we do now and what can we do later
     104
     105* HTTPSE canned solution with rule-based redirection
     106
     107HSTS bit limit
     108
     109* then other idea: TB check .favicon *and* for .well_known and then redirect
     110(TB-focused solution therefore easy to implement
     111
     112reasons not to redirect to the .onion, therefore pseudo-TLD (ie, onion.)
     113
     114comparing public www v .onion to HTTP and HTTPS
     115
     116how HTTPSE works now, json file, with multiple update channels: updating
     117the list versus updating the extension itself
     118
     119auditable as an end-goal?
     120
     121maintenance of .onion site
     122
     123autoredirect proposal: does it make sense
     124
     125trade-offs: not like HTTPSE with minimal performance impact
     126
     127Xsocialnetworksite knows you're using Tor
     128
     129privacy is about choice, so no to autoredirect?
     130
     131http < https is easy, public < .onion/https isn't necessarily
     132
     133defaults matter
     134
     135nothing stops a www admin from issuing a 302 redirect to .onion site
     136
     137babysteps: FF extension?
     138
     139authentication and redirection solved
     140
     141.well_known, alt-service header on / top level
     142
     143current FF directs, or NoScript, or TB "browser res" warnings
     144
     145roadmap:
     146
     147from / load alt-service with auto-redirect as TB option?
     148
     149(current scenario is that TCP destination can easily know if source is
     150public Tor IP.  What if that changes)
     151