Sorry, the second reference should have been this: https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-to-your-website-39106e2506f9
On Wed, Sep 26, 2018 at 1:50 AM <dinovi...@gmail.com> wrote: > Before moving on from Alt-Svc, one idea that I thought would be great is > adding a new ALPN protocol ID [1] for HTTP/2 over onions, similar to "h2" > for HTTP/2 over TLS. Alec's post [2] reminded me of this and I'm sure > someone has considered this before, but if not now's a good time. > > First, let's all agree that all non-onion websites have to use https, > otherwise none of this matters. > > *Here's the gist of it:* > > Let's consider the case of "h2" ALPN for HTTP/2 over TLS: > 1. browser requests "https://foo.com", receives 'alt-svc: > h2="bar.onion:443"' > 3. browser connects to bar.onion:443 port (this fails if tor socks isn't > set up) > 4. the host must pass authentication [3], which for "h2" means giving a > valid certificate for "foo.com" > 5. if authentication succeeds, browser displays "foo.com" but connects > using "bar.onion" and shows "bar.onion" in the circuit display. > > This scenario is great for common websites because the cookie space is > always "foo.com", so the onion address can be transitory. In particular, > even if the website doesn't own the private key to the onion service, > authentication depends on TLS certificate for "foo.com", which the > website owns. > > > Now, the idea is to add "h2o" ALPN for HTTP/2 over TCP via an onion > service: > 1. browser requests"https://foo.com", receives 'alt-svc: *h2o* > ="bar.onion:80' > 3. normal browsers would ignore this, but Tor Browser connects to > bar.onion:80 > 4. the host *must still pass an authentication* step for "h2o" that Tor > Browser can invent > 5. if authentication succeeds, *Tor Browser redirects to "bar.onion"*, > optionally noting "foo.com" in the circuit display. > > For the "h2o" authentication step, TBB could: > 1. Use a HTTPS Everywhere type extension > 2. Require UI announcement + confirmation > > This scenario is great for websites that want to separate cookie spaces " > foo.com" and "bar.onion" (you probably don't want a whistle-blower logged > in to your onion service suddenly send cookies over an exit node) or don't > want https+onion. Also, this is pretty much compatible with the Alt-Svc > specifications, so it doesn't require adding a new header. > > Note that in this case the onion address is no longer transitory, so it's > important that the website should own the private key. This is critical > because unlike IP addresses, domain names, or even HTTPS certificates, the > private key to onion addresses doesn't expire (until offline/delegate keys > are implemented). > > Thoughts? > > [1] > https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 > [2] > https://medium.com/@alecmuffett/onion-synopsis-for-susan-hennesey-b28a92f0e974 > [3] https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1 > > On Sat, Sep 22, 2018 at 2:55 PM nusenu <nusenu-li...@riseup.net> wrote: > >> (changed the subject to make clear that this is NOT about Alt-Svc anymore) >> >> I assume this is limited to onions for sites that do not aim for server >> side location anonymity. >> >> > FYI: the proposal is now the first Tor Browser proposal: >> > >> https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt >> >> in the light of the fact that this proposal has been started before >> Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF >> jumping on it [0]) >> I'm wondering how you think about it compared to what benefits Alt-Svc >> provides >> over what Onion-Location provides? >> >> Are you unsatisfied with what RFC 7838 - HTTP Alternative Services >> provides or is "onion address is displayed in URL bar" one of your >> goals/requirements of this proposal? >> >> Although Alt-Svc does not work reliably _yet_ and the UI part is missing >> [3] >> I find it addresses some rather important issues that 'Onion-Location' >> does not: >> >> - users get the transport security benefits of .onions without Tor >> Browser displaying >> hard/impossible to remember/recognize randomly looking strings. >> >> Long randomly looking strings in the domain part of the URL that would >> probably >> confuse many users and make it harder to answer the question "Am I still >> on the page I want to be?" >> (I consider it a major UX improvement that you can display the non >> .onion domain name while the traffic actually goes to the .onion) >> >> >> - users will use onions transparently >> without asking them questions they probably don't understand or don't want >> to be bothered with everytime they visit a website [1] >> I believe asking fewer questions, safe defaults and configuration options >> for advanced users >> are some reasonable goals. >> >> - it solves the ".onions can't get DV certs (yet)" issue >> >> >> >> >> >> >> [0] https://blog.cloudflare.com/cloudflare-onion-service/ >> [1] >> https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png >> [2] https://trac.torproject.org/projects/tor/ticket/27590 >> [3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2 >> >> -- >> https://twitter.com/nusenu_ >> https://mastodon.social/@nusenu >> >> >> >> _______________________________________________ >> tor-dev mailing list >> tor-dev@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > > > -- > mahrud <algorithms.jux-foundation.org/~mahrud/blog> > -- mahrud <algorithms.jux-foundation.org/~mahrud/blog>
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev