[tor-onions] Eventual Success at getting Alt-Svc working for my personal Wordpress blog

[Alec Muffett]

Summary of things that I have learned or experienced in the past 24 hours:

- YOU WILL NEED HTTP/2; the specifications suggest that Alt-Svc can run
over http/1.1 but Firefox/TorBrowser appears to ignore "http/1.1=..."
AltSvc protocol directives.

- If I am correct, this is a tragic shame; Alt-Svc over HTTP/1.1 would
speed adoption.

- HTTP/2 only works in Apache if you enable the module, switch it on
manually, and declare in the Apache configs that you want to accept it. It
is not shipped by default.

- When you switch HTTP/2 on, if you are running PHP on a Debianesque
(Other?) platform, the HTTP/2 module will sulk and refuse to function until
you switch off the `mpm_prefork` module, because thread safety

- `mpm_prefork` is default on SO MANY DEBIAN THINGS even though there are
so many blogposts that describe it as crusty and evil

- Sorting this out is a pain; see previous post, there is a helpful link;
the `php_fpm` module works okay (better?) but it means I can't do an
apples-to-apples comparison

- You will also need to enable the `headers` and `setenvif` modules, of not
already

- Placement of the header-generation in the Apache config file is
*critical*; there are simple some places where you can put `Header`
directives and they will be ignored/dropped

- I am conditionally enabling the header for occasions where another
(EOTK-related) header is not present; you probably don't need to do this
but it might be useful for debugging or something, so I will present the
whole thing; this works for me:

...
# AltSvc: no x-from-onion -> true!
SetEnvIf X-From-Onion ^$ USE_ALT_SVC
SetEnv AS_END l7guvoy4zq2i7xec.onion:443
SetEnv AS_OPT "ma=600;persist=1"
#Header set "Alt-Svc" 'http/1.1="%{AS_END}e";%{AS_OPT}e' env=USE_ALT_SVC
Header  set "Alt-Svc"       'h2="%{AS_END}e";%{AS_OPT}e' env=USE_ALT_SVC
Header set Hello World

<VirtualHost *:443>
#Protocols http/1.1
Protocols h2 http/1.1
LogLevel http2:info
...

- you can see the failed http/1.1 experiment in the above

- In my previous email, I cited a fragment of Tor config which I was using
(0.3.4.8) to create a v3 Onion; I have stopped using v3 onions for the
testing, for the moment.

- I am not sure if it's something that I did wrong with that V3 config
(perhaps `HiddenServiceNumIntroductionPoints 3`? or because the same
0.3.4.8 daemon is also serving the v2 onion address for EOTK?) but I was
finding that connections from my desktop machine to the v3 Alt-Svc onion
were very, very flaky; TorBrowser refused to connect to it, could not
resolve it in the HSDir, restarting TorBrowser did not help, using `nc` via
TorBrowser SOCKS would return `Error 4` even though the same onion service
daemon (running for EOTK) was solidly up.

- as soon as I dropped down to a v2 onion for Alt-Svc, testing became a lot
more stable. I am sure it'll get better in time, but for the moment I am
sticking to v2.

No wonder people are having problems getting this working: between
non-default software on the backend, attempting to use a cutting-edge v3
onion in the middle, and freshly-released client software which doesn't
provide any "success" status/debug information whatsoever, of *course* it's
gonna be tricky.  I have 30 years of daily experience and it took me
several hours to work out what the hell was going on.

This is NOT anyone's fault - there is no blame here, and matters will
doubtless improve - but I am writing this as a reference to quell the
complaints from <people> that <zomg this is hard>.

Of course it's hard: you're standing on the bleeding edge.

    -a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-onions/attachments/20180923/35518931/attachment.html>