Qubes-corridor-Gateway (a Tor traffic whitelisting gateway)

[adrelanos]

corridor, a Tor traffic whitelisting gateway
https://github.com/rustybird/corridor

Since @rustybird are also a Qubes user... What about Qubes-corridor-Gateway VM? Whatever you may feel like implementing.

• Instructions for (advanced?) Qubes users on how to set up a Qubes-corridor-Gateway VM. One could for example configure sys-whonix NetVM to Qubes-corridor-Gateway. For additional leak protection or for review/auditing reasons.
• A qubes-corridor package that simplifies the above setup.

[rustybird]

I guess there could be a setup where the Whonix gateway first connects to the network directly, then a corridor VM with logging enabled is started which connects to the Whonix gateway's control port via qrexec (to subscribe to Tor consensus updates), and finally the corridor VM is made the Whonix gateways's netvm. Otherwise a second Tor daemon would have to run on the computer, inside the corridor VM.

Not sure though if many people would be interested in using such a thing, even I prefer to have corridor running on my Wifi router...

[adrelanos]

Rusty Bird:

I guess there could be a setup where the Whonix gateway first
connects to the network directly, then a corridor VM with logging
enabled is started which connects to the Whonix gateway's control
port via qrexec (to subscribe to Tor consensus updates), and finally
the corridor VM is made the Whonix gateways's netvm.

Not good, since this would not catch theoretical leaks during Tor
bootstrap. If anything, sys-whonix should always use corridor-gateway as
its NetVM from start to shutdown.

Also I don't think Qubes is technically able to do that yet. I think
there is a Qubes R4.0 ticket about allowing to change NetVM change
without reboot.

Otherwise a
second Tor daemon would have to run inside the corridor VM.

Yes. I am not so much worried about a second Tor daemon in a corridor VM.

An implementation that uses the same Tor daemon from sys-whonix sounds a
lot more complicated. [ Alternatively, perhaps sys-whonix could be
configured to run no own Tor process, but to connect to the Tor process
running in corridor-gateway. ]

Not sure though if many people would be interested in using such a
thing,

Dunno. I would. Perhaps not many indeed. But those who do,
developer/auditor/"paranoid" ones could help to detect theoretical leaks
and prevent damage for everyone else if bugs are reported.

even I prefer to have corridor running on my Wifi router...

Also very useful indeed. Btw did you use corridor to audit TBB, Tails,
Whonix and/or Qubes-Whonix [...] using corridor running on your Wifi router?

[rustybird]

Also I don't think Qubes is technically able to do that yet. I think there is a Qubes R4.0 ticket about allowing to change NetVM change without reboot.

What do you mean? Just now I created a test VM (in Qubes 3.1) connected to a Whonix gw VM, downloaded something over Tor, changed the running test VM's netvm to sys-firewall in Qubes VM Manager, and downloaded something over clearnet. Or actually, the router blocked and logged the latter attempt. B-)

I am not so much worried about a second Tor daemon in a corridor VM.

Ah, okay.

An implementation that uses the same Tor daemon from sys-whonix sounds a lot more complicated.

Well, my half-assed proposal from before definitely was :)... But there's a new commit rustybird/corridor@d925e91 which makes corridor save every consensus to disk; at the next start, this state file is used to initially populate the ipset, which should be good enough to let the client VM's tor daemon connect to its guards and from then on supply consensus updates. (Only the very first start of corridor after installing would have to be done unprotected in this scheme.)

Not sure though if many people would be interested in using such a thing,

Dunno. I would. Perhaps not many indeed. But those who do, developer/auditor/"paranoid" ones could help to detect theoretical leaks and prevent damage for everyone else if bugs are reported.

even I prefer to have corridor running on my Wifi router...

Also very useful indeed. Btw did you use corridor to audit TBB, Tails, Whonix and/or Qubes-Whonix [...] using corridor running on your Wifi router?

Audit no, but I regularly use Qubes-Whonix through corridor. Happy to report no leaks observed, ever. And it did catch some stuff during https://github.com/rustybird/orplug development, so I can see how it might be useful for Whonix development too. I'll try to set up something in the next few days.

[adrelanos]

Work in progress:

• https://www.whonix.org/wiki/Corridor
• debian packaging rustybird/corridor#10

@rustybird

What do you mean?

I confused that. There is (or was) some related bug that a VMs NetVM cannot be restarted. (If restarted using "sudo poweroff" and manual restart, there will be no longer networking.) Anyone know which ticket I mean?

@rustybird

I'll try to set up something in the next few days.

Please elaborate.

[rustybird]

@adrelanos:

I'll try to set up something in the next few days.

Please elaborate.

https://github.com/rustybird/corridor/tree/qubes/qubes

But it looks like we're blocked by #1555.

[rustybird]

@adrelanos was right, it didn't turn out to be a blocker and Qubes support has landed in master: https://github.com/rustybird/corridor#qubes

[adrelanos]

Instructions are now ready for testing:
https://www.whonix.org/wiki/Corridor

[adrelanos]

https://www.whonix.org/blog/using-corridor-tor-traffic-whitelisting-gateway-qubes-whonix

---

There are instructions now on how to set up a sys-corridor VM in Qubes:
https://www.whonix.org/wiki/Corridor

So I think this is closeable. Feel free to create new tickets if there is more interest.