[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #21952 [Webpages]: .Onion everywhere?: increasing the use of onion services through automatic redirects and aliasing



#21952: .Onion everywhere?: increasing the use of onion services through automatic
redirects and aliasing
----------------------+--------------------------
 Reporter:  linda     |          Owner:  linda
     Type:  project   |         Status:  reopened
 Priority:  Medium    |      Milestone:
Component:  Webpages  |        Version:
 Severity:  Normal    |     Resolution:
 Keywords:  ux-team   |  Actual Points:
Parent ID:            |         Points:
 Reviewer:            |        Sponsor:
----------------------+--------------------------

Comment (by cypherpunks):

 Syverson here. (Gotta get myself a trac ID. Just noticed this ticket
 recently for the first time.)
 This proposal fits under some of the things that I spelled out at a high
 level in "The Once and Future Onion" https://www.nrl.navy.mil/itd/chacs
 /syverson-once-and-future-onion
 and that coincidentally has a section entitled "Onions Everywhere".
 Also Griffin and I discussed even earlier in "Bake in .onion for Tear-Free
 and Stronger Website Authentication"
 https://www.nrl.navy.mil/itd/chacs/syverson-bake-onion-tear-free-and-
 stronger-website-authentication
 (though I think the subdomain onions and integration of onion and TLS keys
 as discussed in the later paper is generally more promising in the long
 run than the PGP approach).
 Short term (before getting fullblown subdomain onions going), I would like
 to get a few things going.
 1. For sites with registered domain names, e.g., foo.com, look at
 usability, etc. of having a subdomain onion.foo.com that redirects to
 foo.com's onion address. This will be more compatible in the long run with
 sites providing self-authenticated access for their users who are not
 coming in via the Tor network (cf. Once and Future Onion), but redirecting
 from foo.com.onion should also be considered. I expect this is best
 accomplished via HTTPS everywhere rulesets, but am open.
 2. For onionsites with or without associated RDN, look at integration of
 TLS with onionsite keys. This won't prevent unknown authority warnings for
 non EV-certified sites (that fix is planned but further down the road) but
 will at least allow familiar HTTPS lock icon interface with any onion
 address and avoid those sorts of warnings. Many pieces here, but will stop
 now to avoid even more of a data dump on people.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21952#comment:42>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs