Hey All;
I just got Alt-Svc to mostly-work for my blog at https://dropsafe.crypticide.com/
Here's what I did, and why:
I set up a dummy interface on my blogserver (for rationale/instructions, see link below)
$ grep osite0 /etc/hosts
169.254.255.253 *osite0.onion* $ ifconfig dummy0 dummy0: flags=195<UP,BROADCAST,RUNNING,NOARP> mtu 1500 inet 169.254.255.253 netmask 255.255.255.252 broadcast 169.254.255.255 $ ping -c 1 *osite0.onion* PING osite0.onion (169.254.255.253) 56(84) bytes of data. 64 bytes from osite0.onion (169.254.255.253): icmp_seq=1 ttl=64 time=0.167 ms
Set up an onion service, pointing at the dummy interface (rather than localhost or the machine's physical network interface):
HiddenServiceDir /path/to/wherever
HiddenServicePort 80 *osite0.onion*:80 HiddenServicePort 443 *osite0.onion*:443 HiddenServiceVersion 3 HiddenServiceNumIntroductionPoints 3
Configured Apache:
# Set ALT_SVC_PORT explicitly because SERVER_PORT fails curiously
SetEnv ALT_SVC_PORT *443* SetEnv ALT_SVC_ONION *kfq56...trimmed...o6uqd.onion* SetEnv ALT_SVC_MAXAGE 600 # Set the Alt-Svc header if the request has not arrived via EOTK; # You almost certainly do not need to do this, it's specific to EOTK development.
# EOTK sets "*X-From-Onion*: 1" so if that value is empty, set the flag to
true: RewriteCond %{HTTP:*X-From-Onion*} ^$ RewriteRule ^ - [ENV=*USE_ALT_SVC*:true] # ...maybe put other tests here, and then eventually we do: Header set '*Alt-Svc*' '*h2="%{ALT_SVC_ONION}e:%{ALT_SVC_PORT}e"; ma=%{ALT_SVC_MAXAGE}e; persist=1*' env=*USE_ALT_SVC*
Enabled HTTP/2 on my Apache server (it's not enabled by default):
# *a2enmod http2* # ...after adding "*Protocols h2 http/1.1*" to the vhost
config # *systemctl restart apache2*
...then I found this error message in /var/log/apache2/error.log:
*The mpm module (prefork.c) is not supported by mod_http2. The mpm
determines how things are processed in your server. HTTP/2 has more demands in this regard and the currently selected mpm will just not do. This is an advisory warning. Your server will continue to work, but the HTTP/2 protocol will be inactive.*
Bother. I found *mpm_prefork* really was enabled by default, and was a hard dependency for php7.0 operation (necessary for Wordpress):
# apache2ctl -M | grep mpm
Then I found this answer: *https://serverfault.com/a/904115 https://serverfault.com/a/904115* ...which told me how to fix this by swapping over to *mpm_event* and *php_fpm*. I followed the instructions (needed to tweak the cited path for the *ProxyPassMatch *line) and tested that the header was being generated and looks sane, via my TorBrowser's tor daemon:
$ curl --http1.1 -x socks5h://127.0.0.1:9150/ -I
https://dropsafe.crypticide.com/ | grep -i Alt-Svc Alt-Svc: h2="*kfq56...trimmed...o6uqd.onion*:*443*"; ma=600; persist=1
The test required the *--http1.1* option for curl, otherwise if the curl client negotiated a h2 connection, I wouldn't apparently see any of the options in a greppable manner.
Re: the dummy interface, as described elsewhere:
https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-productio...
...the joy of using a dummy interface in this fashion is that all connections from the Tor daemon to a webserver on the same machine will be logged as coming "from" the IP address of the dummy interface. This means that you can track accesses that arrive via the Alt-Svc onion connection, separately from all the others:
$ grep 169.254 www-dropsafe-access.log
*169.254.255.253* - - [22/Sep/2018:23:05:48 +0000] "GET / HTTP/1.1" 200 231583 "-" "curl/7.54.0"
...which provides the otherwise-missing information of *whether the Alt-Svc Onion Link is actually being used*.
Setting up a dummy interface on Ubuntu is fairly easy, but on Raspbian was a pain because *dhcpcd* gets in the way; eventually I just disabled dhcpcd and went back to /etc/network/interfaces, which was okay because my blog server only has static addresses. I'm still not entirely convinced that everything is working as expected/desired, but I'll update again when I am more certain.
The blog is also available via EOTK at https://dropsafe.dropsafezeahmyho.onion/ - requires SSL acceptance.
Best of luck.
- alec
On Sep 22, 2018, at 18:07, Alec Muffett alec.muffett@gmail.com wrote:
I just got Alt-Svc to mostly-work for my blog at https://dropsafe.crypticide.com/
Thanks! This makes it look easy. :)
Is there any way from TorBrowser to verify that I'm indeed using the .onion address? Or is part of the point being that it's undetectable from the client?
Peace...
--Ron
ronqonions@risley.net:
On Sep 22, 2018, at 18:07, Alec Muffett alec.muffett@gmail.com wrote:
I just got Alt-Svc to mostly-work for my blog at https://dropsafe.crypticide.com/
Thanks! This makes it look easy. :)
Is there any way from TorBrowser to verify that I'm indeed using the .onion address? Or is part of the point being that it's undetectable from the client?
currently it is not directly shown in the UI, I made a feature request/comment to change that, let's see what their UI plans are: https://trac.torproject.org/projects/tor/ticket/27590#comment:2
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
On Sun, 23 Sep 2018 at 11:13, Alec Muffett alec.muffett@gmail.com wrote:
- 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.
I should clarify this: *occasionally* the V3 onion would work, but irregularly and perhaps only 15% of the time; once I replaced the V3 Onion Address with a V2 address it became solid, and much more quick and reliable for the client to kick over to using Alt-Svc, generally once the first page load was complete.
In fact I am kinda wondering if there is a coarse lock (or: side effect of HTTP/2 pipelining?) that perhaps inhibits Alt-Svc being picked-up and honoured until after a complete page is finished loading?
-a
tor-onions@lists.torproject.org
-
Alec Muffett -
nusenu -
ronqonions＠risley.net