Page MenuHomePhabricator

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

Details

Impact
Normal

Event Timeline

Patrick created this task.Jan 18 2017, 2:19 PM
Patrick renamed this task from should use http+tor / apt-transport-tor rather than Acquire::BlockDotOnion "false"; to use tor+http / apt-transport-tor rather than Acquire::BlockDotOnion "false";.Jan 18 2017, 2:25 PM

What about tor-over-tor issue here? And starting tor in template by having apt-transport-tor installed? Are those issues mitigated somehow else?

Patrick reopened this task as Open.Jan 19 2017, 3:50 PM

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:

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 https://github.com/Whonix/qubes-template-whonix/blob/master/whonix-gateway/04_install_qubes_post.sh to onion yet. I guess there we should use onion plus Acquire::BlockDotOnion "false";?

In T610#11722, @Patrick wrote:

I haven't updated whonix_repository_uri= in https://github.com/Whonix/qubes-template-whonix/blob/master/whonix-gateway/04_install_qubes_post.sh 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?

In T610#11722, @Patrick wrote:

I haven't updated whonix_repository_uri= in https://github.com/Whonix/qubes-template-whonix/blob/master/whonix-gateway/04_install_qubes_post.sh 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?

Perhaps it's better to implement this rather minimally inside the https://phabricator.whonix.org/tag/qubes-whonix/ package? A simple one socat listener port 9050 only redirection from whonix-gw TemplateVM to sys-whonix?

You're talking about whonix-gw template here, right? And still cover
whonix-ws with anon-ws-disable-stacked-tor?

As for status files - checking for /var/run/qubes/this-is-templatevm
_and_ some status file signaling whonix-gw should be ok. I'm talking
about putting this in qubes-whonix package.

marmarek (Marek Marczykowski-Górecki):

marmarek added a comment.

Perhaps it's better to implement this rather minimally inside the
https://phabricator.whonix.org/tag/qubes-whonix/ package? A simple
one socat listener port 9050 only redirection from whonix-gw
TemplateVM to sys-whonix?

You're talking about whonix-gw template here, right? And still cover
whonix-ws with
https://phabricator.whonix.org/tag/anon-ws-disable-stacked-tor/?

Good question. Would work either way. I guess simpler for both whonix-gw
and whonix-ws to have this minimal redirection inside the qubes-whonix
package.

As for status files - checking for /var/run/qubes/this-is-templatevm
_and_ some status file signaling whonix-gw should be ok. I'm talking
about putting this in
https://phabricator.whonix.org/tag/qubes-whonix/ package.

Right.

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.

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 changed the task status from Open to Review.Mar 1 2017, 9:23 PM
In T610#11827, @Patrick wrote:

marmarek (Marek Marczykowski-Górecki):

marmarek added a comment.

Perhaps it's better to implement this rather minimally inside the
https://phabricator.whonix.org/tag/qubes-whonix/ package? A simple
one socat listener port 9050 only redirection from whonix-gw
TemplateVM to sys-whonix?

You're talking about whonix-gw template here, right? And still cover
whonix-ws with
https://phabricator.whonix.org/tag/anon-ws-disable-stacked-tor/?

Good question. Would work either way. I guess simpler for both whonix-gw
and whonix-ws to have this minimal redirection inside the qubes-whonix
package.

This is now implemented using systemd socket activation and /lib/systemd/systemd-socket-proxyd.

https://github.com/Whonix/qubes-whonix/commit/eed4d291769be16c518956eea539e3f0b61954b2

pkg-systemd-maintainers question - [Install] for static systemd unit file?:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-March/014376.html

Patrick closed this task as Resolved.Mar 7 2018, 1:11 AM