Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upQubes-corridor-Gateway (a Tor traffic whitelisting gateway) #2108
Comments
andrewdavidwong
added
enhancement
C: other
P: major
privacy
labels
Jun 23, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rustybird
Jun 23, 2016
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...
rustybird
commented
Jun 23, 2016
•
|
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... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jun 23, 2016
Member
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?
|
Rusty Bird:
Not good, since this would not catch theoretical leaks during Tor Also I don't think Qubes is technically able to do that yet. I think
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
Dunno. I would. Perhaps not many indeed. But those who do,
Also very useful indeed. Btw did you use corridor to audit TBB, Tails, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rustybird
Jun 24, 2016
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.
rustybird
commented
Jun 24, 2016
•
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-)
Ah, okay.
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.)
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. |
added a commit
that referenced
this issue
Jun 25, 2016
rustybird
referenced this issue
in QubesOS/qubes-core-agent-linux
Jun 30, 2016
Merged
Order network management units after network-pre.target #17
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 11, 2016
Member
Work in progress:
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?
I'll try to set up something in the next few days.
Please elaborate.
|
Work in progress:
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?
Please elaborate. |
added a commit
that referenced
this issue
Jul 11, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rustybird
Jul 12, 2016
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
commented
Jul 12, 2016
•
https://github.com/rustybird/corridor/tree/qubes/qubes But it looks like we're blocked by #1555. |
added a commit
that referenced
this issue
Jul 13, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rustybird
Jul 13, 2016
@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
rustybird
commented
Jul 13, 2016
|
@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 |
added a commit
that referenced
this issue
Jul 13, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 18, 2016
Member
Instructions are now ready for testing:
https://www.whonix.org/wiki/Corridor
|
Instructions are now ready for testing: |
added a commit
that referenced
this issue
Jul 19, 2016
added a commit
to adrelanos/corridor
that referenced
this issue
Jul 20, 2016
adrelanos
referenced this issue
in rustybird/corridor
Jul 20, 2016
Closed
mention Qubes and Debian version in readme #24
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Jul 20, 2016
Member
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.
|
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: So I think this is closeable. Feel free to create new tickets if there is more interest. |
adrelanos commentedJun 23, 2016
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.