use tor+http / apt-transport-tor rather than Acquire::BlockDotOnion "false";

phabricator-migrator · February 19, 2024, 5:44pm

Information

ID: 610
PHID: PHID-TASK-7rjclyhav2wybztfybsa
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754242#54.

Comments

Patrick

2017-01-18 13:43:02 UTC

Patrick

2017-01-19 12:07:08 UTC

marmarek

2017-01-19 12:18:31 UTC

Patrick

2017-01-19 14:50:25 UTC

I am glad I tagged you for this ticket. This can use scrutiny indeed. Haven’t thought of that yet.

Tor over Tor in Qubes TemplateVM is generally sorted out by:

https://github.com/Whonix/qubes-whonix/blob/master/lib/systemd/system/tor.service.d/40_qubes.conf

https://github.com/Whonix/qubes-whonix/blob/master/lib/systemd/system/tor%40default.service.d/40_qubes.conf

In Qubes TemplateVM tor+http is currently broken.

Failed to connect to localhost port 9050: Connection refused

Perhaps it should be fixed by running #anon-ws-disable-stacked-tor in Qubes whonix-ws TemplateVM? That would be easy. Will think that through (any adverse effects by running anon-ws-disable-stacked-tor in template.)

What about Qubes whonix-gw TemplateVM? There is no anon-ws-disable-stacked-tor. Perhaps anon-ws-disable-stacked-tor should be installed in whonix-ws template also but only be run in whonix-ws template but not in sys-whonix.

I haven’t updated whonix_repository_uri= in qubes-template-whonix/whonix-gateway/04_install_qubes_post.sh at master · Whonix/qubes-template-whonix · GitHub to onion yet. I guess there we should use onion plus Acquire::BlockDotOnion "false";?

marmarek

2017-01-21 00:12:10 UTC

! In T610#11722, @Patrick wrote:
I haven’t updated whonix_repository_uri= in qubes-template-whonix/whonix-gateway/04_install_qubes_post.sh at master · Whonix/qubes-template-whonix · GitHub to onion yet. I guess there we should use onion plus Acquire::BlockDotOnion "false";?

In Qubes Whonix case, I think this is the easiest thing to do, for both whonix-ws and whonix-gw. Both have other mechanism to prevent updating over clearnet, so IMHO no real reason for using tor+http. Not sure about not-Qubes cases. #anon-ws-disable-stacked-tor and tor+http may be the answer for whonix-ws (if going that way, IMO it can be also for both Qubes and non-Qubes - to ease maintenance).
But then we still need a solution for whonix-gw. Running #anon-ws-disable-stacked-tor in template only? How would that affect non-Qubes case? Can it be done in uniform way to make maintenance reasonably easy?

Patrick

2017-01-21 10:19:18 UTC

! In T610#11819, @marmarek wrote:

! In T610#11722, @Patrick wrote:
I haven’t updated whonix_repository_uri= in qubes-template-whonix/whonix-gateway/04_install_qubes_post.sh at master · Whonix/qubes-template-whonix · GitHub to onion yet. I guess there we should use onion plus Acquire::BlockDotOnion "false";?

In Qubes Whonix case, I think this is the easiest thing to do, for both whonix-ws and whonix-gw. Both have other mechanism to prevent updating over clearnet, so IMHO no real reason for using tor+http.

The reason for tor+http was not clearnet leak prevention. Only the recommendation to use it here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754242#54

Not sure about not-Qubes cases. #anon-ws-disable-stacked-tor and tor+http may be the answer for whonix-ws (if going that way, IMO it can be also for both Qubes and non-Qubes - to ease maintenance).
But then we still need a solution for whonix-gw. Running #anon-ws-disable-stacked-tor in template only? How would that affect non-Qubes case? Can it be done in uniform way to make maintenance reasonably easy?

For #anon-ws-disable-stacked-tor there would have to be some rules when it runs and when not. Perhaps implemented using status files and systemd unit file conditions.

if workstation is detected → run it

if Qubes is detected
** if gateway is detected
*** if Template → run it
*** otherwise → do nothing

if Qubes is not detected
** if gateway is detected → do nothing

Not immediately obvious to me how to express that in systemd terms.

Running #anon-ws-disable-stacked-tor in whonix-gw template was perhaps a premature idea of mine anyhow. It prevents installation of Tor after all. So the socat redirection part would have to be factored out into a separate package.

Perhaps it’s better to implement this rather minimally inside the Qubes-Whonix package? A simple one socat listener port 9050 only redirection from whonix-gw TemplateVM to sys-whonix?

marmarek

2017-01-21 22:15:17 UTC

Patrick

2017-01-22 12:38:21 UTC

Patrick

2017-02-21 21:11:10 UTC

We should probably also set a socks user name for better Tor stream isolation. (IsolateSOCKSAuth) I am considering to add this to the #uwt package.
Acquire::tor::proxy "socks5h://apt-transport-tor@127.0.0.1:9050";
(From reading zless /usr/share/doc/apt-transport-tor/README.md.gz.)

I was considering to change the port from 9050 to another one, but I am vary of this. It might look better but would also make the implementation more complicated. (Another Tor SocksPort. Not redirect 9050 from TemplateVM to gateway but another port.) Without any actual benefit.

Patrick

2017-03-01 00:52:53 UTC

! In T610#12427, @Patrick wrote:
We should probably also set a socks user name for better Tor stream isolation. (IsolateSOCKSAuth) I am considering to add this to the #uwt package.
Acquire::tor::proxy "socks5h://apt-transport-tor@127.0.0.1:9050";
(From reading zless /usr/share/doc/apt-transport-tor/README.md.gz.)

I was considering to change the port from 9050 to another one, but I am vary of this. It might look better but would also make the implementation more complicated. (Another Tor SocksPort. Not redirect 9050 from TemplateVM to gateway but another port.) Without any actual benefit.
Not needed. Tor control command SETEVENTS CIRC revealed that apt-transport-tor sets SOCKS_USERNAME="apt-transport-tor" SOCKS_PASSWORD="sgvtcaew4bxjd7lnonion" etc. anyhow.

Patrick

2017-03-01 20:23:01 UTC

Patrick

2017-03-01 20:50:00 UTC

Patrick

2017-03-02 16:44:46 UTC