[tor-talk] Draft: Different Ways To Add Tor Onion Addresses To Your Website

[Alec Muffett]

I've spent the morning pulling together a bunch of draft thoughts regards
the technical pros/cons of differing forms of site onionification;
thoughts, comments & feedback are warmly welcomed:

https://medium.com/@alecmuffett/different-ways-to-add-tor-onion-addresses-to-your-website-39106e2506f9

- alec (ps: apologies if you see 2+ copies of this, I am treating maillists
separately)

[Roman Mamedov]

On Sat, 22 Sep 2018 13:45:33 +0100

Post by Alec Muffett
I've spent the morning pulling together a bunch of draft thoughts regards
the technical pros/cons of differing forms of site onionification;
- alec (ps: apologies if you see 2+ copies of this, I am treating maillists
separately)

I hoped this would finally describe how to actually deploy Alt-Svc on
a .onion+clearnet website. Right now it feels like, OK, CloudFlare knows how
to do this, and the rest of us don't matter. Not a single HOWTO or guide on
how to actually set it up. Asked on the mailing list before, complete silence.

[Ben Tasker]

Post by Roman Mamedov
I hoped this would finally describe how to actually deploy Alt-Svc on
a .onion+clearnet website. Right now it feels like, OK, CloudFlare knows how
to do this, and the rest of us don't matter. Not a single HOWTO or guide on
how to actually set it up. Asked on the mailing list before, complete silence.

Which part are you struggling with?

The following is assuming you've got a site - www.example.com - that's
accessible at 1234.onion.

Configure your nginx server block (or apache config) for www.example.com to
include an Alt-Svc header to advertise the onion:

Alt-Svc: h2="1234.onion:443"; ma=3600; persist=1

(The Ma there tells the browser to remember this for an hour).

In Nginx config that would be

add_header Alt-Svc 'h2="1234.onion:443"; ma=3600; persist=1';

In Apache with mod_headers that *should* be

Header set Alt-Svc 'h2="1234.onion:443"; ma=3600; persist=1';


So far so easy. The next bit is a little less obvious though.

You need to configure your onion server block to respond on port 443 _and_
to handle your clearnet host header (and serve a publicly trusted
certificate matching that name). Alt-Svc tells the browser to use the
alternate address as a trusted origin for the service it's connecting to,
so it'll connect to 1234.onion and request www.example.com

You can, of course, continue to also serve your onion over port 80 as well
if you wish for direct visitors (as you still can't trivially get a cert
for an onion name).

HTH - hopefully I haven't missed anything

Ben

[Roman Mamedov]

On Sat, 22 Sep 2018 15:28:19 +0100

Post by Ben Tasker
Which part are you struggling with?
The following is assuming you've got a site - www.example.com - that's
accessible at 1234.onion.
Configure your nginx server block (or apache config) for www.example.com to
Alt-Svc: h2="1234.onion:443"; ma=3600; persist=1

Well for instance my backend server is HTTP/1.1 only. I do run a nginx
frontend to it for HTTP/2, but due to a number of reasons I want Tor's hidden
service to point at the backend directly.

For whatever reason everyone just assumes all web servers are HTTP/2 now, and
uses "h2" like you do. What to use in case of 1.1? It almost feels like nobody
actually knows and everyone just keep reposting the same "h2" examples they
saw on the Internet.

And most importantly, how to test that the header I serve is valid and it all
actually works? I suppose there isn't any online test suite like there's
https://www.ssllabs.com/ssltest/ for general HTTPS. If not, for testing do I
load the clearnet site in the Tor browser aaaaaand then expect what to happen?
(Is there any indication in the UI that alt-svc is being used)

[Roman Mamedov]

On Sat, 22 Sep 2018 15:28:19 +0100

Post by Ben Tasker
You need to configure your onion server block to respond on port 443 _and_
to handle your clearnet host header (and serve a publicly trusted
certificate matching that name). Alt-Svc tells the browser to use the
alternate address as a trusted origin for the service it's connecting to,
so it'll connect to 1234.onion and request www.example.com

Also, do you mean there's no way to have an Alt-Svc with "[...].onion:80",
directing to a plain HTTP connection to the hidden service? (Assuming the
initial request to the clearnet site was on HTTPS.)

There is no point in running HTTPS-over-Tor-hidden-service, as .onion traffic
is already authenticated and encrypted, it only adds useless overhead. If
there's no way around that with the alt-svc scheme, that seems like a huge
oversight.

[Alec Muffett]

Post by Roman Mamedov
There is no point in running HTTPS-over-Tor-hidden-service, as .onion traffic
is already authenticated and encrypted, it only adds useless overhead.

I see your point, but there are a couple of additional perspectives to be
considered:
https://medium.com/@alecmuffett/onions-certs-browsers-a-three-way-mexican-standoff-7dc987b8ebc8
- especially regarding new functionality that will be locked to HTTPS


If

Post by Roman Mamedov
there's no way around that with the alt-svc scheme, that seems like a huge
oversight.

Respecting AltSvc on port 80 would be as dangerous, possibly more
dangerous, than cleartext HTTP already is; and regards the notion of making
"onion" into a widely respected secure source equivalent to a HTTPS site,
please see the above essay.

-a

[Traumschule]

Thanks for your work on this and the explanations on this list. When
things cleared up a bit, i'll add them to the manual:

#27820 new task
Explain the different approaches to onionify a website
http://ea5faa5po25cf7fb.onion/projects/tor/ticket/27820
https://bugs.torproject.org/27820

On Sat, 22 Sep 2018 16:15:08 +0100

Post by Alec Muffett

Post by Roman Mamedov
There is no point in running HTTPS-over-Tor-hidden-service,
as .onion traffic
is already authenticated and encrypted, it only adds useless
overhead.

I see your point, but there are a couple of additional perspectives
- especially regarding new functionality that will be locked to HTTPS
If

Post by Roman Mamedov
there's no way around that with the alt-svc scheme, that seems like
a huge oversight.

Respecting AltSvc on port 80 would be as dangerous, possibly more
dangerous, than cleartext HTTP already is; and regards the notion of
making "onion" into a widely respected secure source equivalent to a
HTTPS site, please see the above essay.
-a

--
traumschule.org

gpg fingerprint:
9356 4DED 8546 8D9A C290 3605 12EE 7D70 7111 2056

/otr info
OTR: ***@irc.indymedia.org fingerprint:
OTR: 35AACA83 4564616C B6EBEC66 56B6B2FC C8D572F1
OTR: ***@irc.oftc.net fingerprint:
OTR: D1CCD207 B60C1866 56A975AE ACE090E9 45E90846
OTR: ***@chat.freenode.net fingerprint:
OTR: 51BF8BB9 434840CC 24F264BC 76450C27 A6AADB12

[Ben Tasker]

Post by Roman Mamedov
Also, do you mean there's no way to have an Alt-Svc with "[...].onion:80",
directing to a plain HTTP connection to the hidden service? (Assuming the
initial request to the clearnet site was on HTTPS.)

Correct.

It has to go to HTTPS because the cert served by the new origin is used as
a mechanism to authenticate that it is actually authorised to act as an
origin. The primary aim being to ensure that if I (somehow) manage to
inject an Alt-Svc header into your responses, I cannot simply redirect
users via my service _unless_ I can also obtain a valid certificate for
your original name.

Post by Roman Mamedov
There is no point in running HTTPS-over-Tor-hidden-service, as .onion

traffic is already authenticated and encrypted, it only adds useless
overhead

See above. Without HTTPS the onion service is authenticated as being that
onion service, but is absolutely not authorised as an authorised origin for
www.example.com. It's not an oversight, it's a deliberate rational design
decision to help prevent various attacks that would otherwise be possible.

Post by Roman Mamedov
What to use in case of 1.1?

I've not checked Browser support for downgrading to 1.1, but the Alt-Svc
header expects a RFC7301 ALPN name - so the name here would be http/1.1.
However, you also need to percent encode (RFC 7838 section 3), so it'd be
http%2F1.1


I should add - depending on the browser you *may* find you need to only
inject the header when the user is coming from a Tor exit. Otherwise direct
clearnet users might try and connect out.

It *shouldn't* happen (the RFC makes it very clear that alt services are
optional, and should be used when the alt origin becomes available - "the
client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available"). But as with anything, plan
for the dumbest user-agent you could possibly imagine.

[TNT BOM BOM]

"Right now it feels like, OK, CloudFlare knows how to do this, and the
rest of us don't matter. Not a single HOWTO or guide on how to actually
set it up"

Fishy CloudFlare....

Post by Roman Mamedov
On Sat, 22 Sep 2018 13:45:33 +0100

Post by Alec Muffett
I've spent the morning pulling together a bunch of draft thoughts regards
the technical pros/cons of differing forms of site onionification;
- alec (ps: apologies if you see 2+ copies of this, I am treating maillists
separately)

I hoped this would finally describe how to actually deploy Alt-Svc on
a .onion+clearnet website. Right now it feels like, OK, CloudFlare knows how
to do this, and the rest of us don't matter. Not a single HOWTO or guide on
how to actually set it up. Asked on the mailing list before, complete silence.

[Alec Muffett]

Post by TNT BOM BOM
"Right now it feels like, OK, CloudFlare knows how to do this, and the
rest of us don't matter. Not a single HOWTO or guide on how to actually
set it up". Fishy CloudFlare....

Well, if you want to take that attitude, you can, but it's not terribly
constructive.

Perhaps you should write the document that you want to read, and then share
it with us all.

-a