Re: [qubes-users] ANN: Leakproof Qubes VPN
On 11/09/2016 01:38 PM, SEC Tester wrote: > Hey Rudd-O, > > Thanks for your effort and great contribution to the Qubes community. Not > sure why Chris was critical, especially without specifically showing evidence > of any problems. Maybe just a troll? > > I haven't tried your program out yet, Im keeping it as my backup option, as > im still hoping to find a way to get my AirVPN GUI to work. I would prefer a > GUI over a CLI, especially when i might want to switch servers quickly or > look at my stats. > > As you seem like such an expert on this, i was hoping you could have a look > at my post, and see if you could workout whats going wrong? > > https://groups.google.com/forum/#!topic/qubes-users/T0wbCuIgISg > > If you have the time that would be Awesome! Cheers. I don't really know how that VPN software works, honestly. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f1e99ec5-280d-b131-0d0e-2d5d263fc5ab%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
Hey Rudd-O, Thanks for your effort and great contribution to the Qubes community. Not sure why Chris was critical, especially without specifically showing evidence of any problems. Maybe just a troll? I haven't tried your program out yet, Im keeping it as my backup option, as im still hoping to find a way to get my AirVPN GUI to work. I would prefer a GUI over a CLI, especially when i might want to switch servers quickly or look at my stats. As you seem like such an expert on this, i was hoping you could have a look at my post, and see if you could workout whats going wrong? https://groups.google.com/forum/#!topic/qubes-users/T0wbCuIgISg If you have the time that would be Awesome! Cheers. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b451c810-eba8-4c94-bf0c-237ef7b3678e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/27/2016 12:03 PM, Robert Mittendorf wrote: > Just saw the Qubes VPN project right now. > > Quick-reading the tutorial I have to questions: > > 1) why does the VPN-VM need to be allowed to do DNS, The VPN VM does not need to be allowed to do DNS. You can set an IP in its configuration and then no DNS is needed. I will expand the instructions to indicate that. > if DNS requests are routed through the VPN. Is it just in case the VPN > server it wants to connect to is defined by hostname instead of IP? No. The DNS requests of the chained AppVMs are routed to the DNS servers declared by the VPN server. The DNS requests of the VPN VM itself are routed to the DNS servers of the NetVM that is upstream of the VPN VM. > 2) why is the recommendation to allow all hosts for the VPN server > (and not only the VPN servers IP)? No reason. I will clarify that there's no need to do that. > > thank you > Thank you for helping me clarify the documentation. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1324039e-5a32-e200-b60b-533a9ad56ceb%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
Just saw the Qubes VPN project right now. Quick-reading the tutorial I have to questions: 1) why does the VPN-VM need to be allowed to do DNS, if DNS requests are routed through the VPN. Is it just in case the VPN server it wants to connect to is defined by hostname instead of IP? 2) why is the recommendation to allow all hosts for the VPN server (and not only the VPN servers IP)? thank you -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b4c85024-1da2-f674-5082-801720fde365%40digitrace.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/27/2016 09:15 AM, cyrinux wrote: > > Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no > problem, this seems perfect ;) Thank you very, very much. You are very kind for taking the time to give public appreciation for my work :-) This is the stuff I live for. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e9c69164-c780-7755-8c1f-fb258676900b%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
Le mercredi 26 octobre 2016 14:38:24 UTC+2, Manuel Amador (Rudd-O) a écrit : > Apologies for the reply to self, but I have received great news. > > The first piece of great news is that a user of Qubes VPN found a bug > that made it impossible for Qubes VPN to work with tun-style VPN > providers. We have fixed that bug thanks to his cooperation, and you > can see the result of our bug report and conversation here: > > https://www.reddit.com/r/Qubes/comments/57acz8/add_a_leakproof_vpn_to_your_qubes_os_with_this/ > > The second piece of great news is that, based on what he reported there, > ABSOLUTELY NO TRAFFIC ever leaked from his VPN-protected AppVM to any > sort of network device, as the VPN VM still prevented the traffic from > going anywhere else except over the VPN. > > That means: even under an environment where a critical bug rendered VPN > operation impossible, Qubes VPN still managed to prevent leaks 100%. > > I am quite happy to see that the engineering gone into this thing > actually paid off big time. > > Have you tried Qubes VPN yet? > > -- > > Rudd-O > http://rudd-o.com/ Hi Rudd-o, just for say I use Qubes VPN since 2 weeks, with mullad, and no problem, this seems perfect ;) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7cf989a6-91cf-4281-94b5-32701272fa4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
Apologies for the reply to self, but I have received great news. The first piece of great news is that a user of Qubes VPN found a bug that made it impossible for Qubes VPN to work with tun-style VPN providers. We have fixed that bug thanks to his cooperation, and you can see the result of our bug report and conversation here: https://www.reddit.com/r/Qubes/comments/57acz8/add_a_leakproof_vpn_to_your_qubes_os_with_this/ The second piece of great news is that, based on what he reported there, ABSOLUTELY NO TRAFFIC ever leaked from his VPN-protected AppVM to any sort of network device, as the VPN VM still prevented the traffic from going anywhere else except over the VPN. That means: even under an environment where a critical bug rendered VPN operation impossible, Qubes VPN still managed to prevent leaks 100%. I am quite happy to see that the engineering gone into this thing actually paid off big time. Have you tried Qubes VPN yet? -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/667e45a5-0278-ca7a-0cd4-3bc0101ff045%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Oct 13, 2016 at 11:22:08PM -0400, Chris Laprise wrote: > On 10/13/2016 09:31 PM, Manuel Amador (Rudd-O) wrote: > > > > Oops about what? Unlike the official Qubes VPN documentation, which > > counsels people to write scripts that make non-atomic modifications to > > their firewall, which actually and demonstrably have a leak between > > Qubes firewall updates and VPN rules setup, my work doesn't leak traffic > > in-between the addition of iptables rules. > > The qubes-firewall-user-script is a feature of Qubes firewall. And its one > of the original Qubes docs that encourage people to use it. So, yes, there > is a vulnerability in Qubes firewall, and it should be noted foremost in the > Known Issues for the project. ip_forwarding is disabled for the time of reloading rules. Anyway, guys, please. Both solutions are fine. One is easier to understand, convert to other VPN software and apply to ProxyVM without modifying any template. The other one is OpenVPN specific (at least currently) and easier to package (so do not require copying any script by the user manually). Technical details here (more iptables modifications vs separate route table) are just technical details. Both approaches should work. The nice thing of manual one (in current shape) is also blocking traffic going from ProxyVM itself (and not originated by VPN software). But it should be trivial to add the same to the other one. This should not affect AppVMs behind such ProxyVM in anyway. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYAMmSAAoJENuP0xzK19csNroIAJpPS2jnDHdUBMKImgEMTzJZ AWtgDbMpUpYDT7aX+LC8W84DrNHciDfbOhbNaVwxOgLX2iSd5iafv62M73D3oSsr 2+nO5isSnpY72CnJZgxPiS5jZ0R6WoF5zQcuDx3PREgU4Nr0hKCUQbITAMRhW6I+ XF3lemLX9InUzowYFgLFxc+8x1N0FSBToFor73W1tBFZI5SuS0mYoTCLsncFTBDC QGOGd74V24aoQv3y++gD/wwaME8+oRLv5wqun75DuKx+hcSXUJEfwouemfKsyEva 8R42R1ZaF671jL+POORZPKL+AnLvrxwFC+FnArOQtt2STL5lrIcKW64PR5Iju8k= =CCiA -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161014120331.GW15776%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 09:31 PM, Manuel Amador (Rudd-O) wrote: Oops about what? Unlike the official Qubes VPN documentation, which counsels people to write scripts that make non-atomic modifications to their firewall, which actually and demonstrably have a leak between Qubes firewall updates and VPN rules setup, my work doesn't leak traffic in-between the addition of iptables rules. The qubes-firewall-user-script is a feature of Qubes firewall. And its one of the original Qubes docs that encourage people to use it. So, yes, there is a vulnerability in Qubes firewall, and it should be noted foremost in the Known Issues for the project. The VPN use case is probably one of the least-vulnerable examples of leakiness in Qubes firewall, because it requires multiple failures to line up in a small window. That means non-VPN use cases are probably at least as vulnerable. Its the underlying problem which is my overriding concern. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9f1744c7-7eb1-f240-731c-7ccbd86179b0%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/14/2016 12:32 AM, Chris Laprise wrote: > On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote: > * Interdependent packet marking, detection and routing rules are > needlessly complex FWMARK was the only way to get blackholing to work reliably without interference from the Qubes OS firewalling system. >>> So you added complexity where simply blocking all forwarding to/from >>> eth0 would have sufficed. >> Not really. I implemented the simplest and least-invasive solution I >> could think of. It's four directives: >> >> 1. Instruct the routing engine to route all packets from downstream VMs >> to use table 78. This happens very early during boot, right after the >> Qubes OS default firewall rules are loaded, and so it happens that VMs >> cannot leak. >> 2. Tell table 78 to route all traffic to the VPN if the VPN interface is >> active, and to blackhole all traffic if the VPN interface goes down. >> This is actually quite cool, because there's no need to clean up >> anything if the VPN fails — the routes disappear when the TUN/TAP device >> goes away, leaving the blackhole route active. >> 3. Add two firewall rules directing all DNS requests from downstream VMs >> to the DNS servers of the VPN. >> >> I think, in my humble opinion, that this compares /quite favorably/ with >> (the doc) asking the user to write several scripts, all of which make >> much more invasive iptables modifications, while still allowing the VPN >> server to muck with the system routing table, a practice which under >> some circumstances could cause the ProxyVM itself to use the wrong DNS >> servers, or to fail to reconnect to the VPN. >> >> Additionally, I see that some of the tables that the doc's scripts >> modify are actually tables that the Qubes firewall may revert to their >> original state, so it's quite easy for a firewall config change to blow >> those rules up, leaving the user with a leaky VPN. Granted, the >> firewall config change will only last about a half a second, because the >> user firewall script will be invoked afterwards, but during that >> half-second, traffic can leak via the eth0 route. OOPS! > > Now that is something interesting. So the Qubes firewall is supposedly > bad. Nope. It's actually pretty good, and it was the inspiration for my work. Getting leakproof VPNs is a hard job. The official documentation for the firewall is as good as you can get, without hard core networking work. > And we can let most users suffer whatever consequences when they block > traffic with sys-firewall, because only our specific VPN application > matters?? I don't know what you mean. "Most users", "suffer", "consequences" when they "block traffic". I have zero idea what this means with regards to my work. Most users don't actually write shell scripts to do basic things like VPN. "Most users" are not even the target of work like VPN systems. The target market for such work is users who want provable privacy. That is the sort of work that I endeavored to do, and now I have delivered it. > > Keeping in mind that the default policy of FORWARD is DROP, we should > also consider whether a stream of iptables commands is too slow to be > secure. Yes, the document should probably be updated to reflect that. > And if so, ask why 1) the user firewall rules are in script format; That isn't the case within Qubes OS. Qubes OS firewall adds / changes rules atomically via iptables-restore. > Or why 2) the commands aren't all combined for an iptables-restore; They are in Qubes OS. IF you are critiquing my work again, then I have to say you are technically correct, as the DNS rules my work adds (during OpenVPN "up") are not atomically added via iptables-restore. That fact is not relevant to the promise of leak-proofness that my work makes. The only *relevant* rules that get added during VPN connection, are two DNS rules. Any DNS packets sent by downstream VMs will be blackholed in the meantime, so, well, leakproof like I said from the beginning. It's okay to flush the specific routing table for DNS that my program creates, and then to add rules non-atomically, as DNS packets coming in between the flush and the rules will get dropped and not routed anywhere useful. If you look closely at my work — this is not an accident, but a deliberate outcome of my study of the problem — during OpenVPN "up", the DNS rules are added before the routes are added, which has the side effect of DNS packets being routed nowhere until the routes are added. So non-atomic modifications to the firewall are fine in this case. It's all in the `qubes-vpn-interface-control.in` script for anyone to see. You are welcome to verify these claims with tcpdump (I did it too). You are also welcome to send pull requests to make the rule addition atomic. > Or why 3) the chains aren't started with a temporary REJECT while they > are being populated. ANY. ONE. Of these will address the issue for > VPNs and all the other use
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote: * Interdependent packet marking, detection and routing rules are needlessly complex FWMARK was the only way to get blackholing to work reliably without interference from the Qubes OS firewalling system. So you added complexity where simply blocking all forwarding to/from eth0 would have sufficed. Not really. I implemented the simplest and least-invasive solution I could think of. It's four directives: 1. Instruct the routing engine to route all packets from downstream VMs to use table 78. This happens very early during boot, right after the Qubes OS default firewall rules are loaded, and so it happens that VMs cannot leak. 2. Tell table 78 to route all traffic to the VPN if the VPN interface is active, and to blackhole all traffic if the VPN interface goes down. This is actually quite cool, because there's no need to clean up anything if the VPN fails — the routes disappear when the TUN/TAP device goes away, leaving the blackhole route active. 3. Add two firewall rules directing all DNS requests from downstream VMs to the DNS servers of the VPN. I think, in my humble opinion, that this compares /quite favorably/ with (the doc) asking the user to write several scripts, all of which make much more invasive iptables modifications, while still allowing the VPN server to muck with the system routing table, a practice which under some circumstances could cause the ProxyVM itself to use the wrong DNS servers, or to fail to reconnect to the VPN. Additionally, I see that some of the tables that the doc's scripts modify are actually tables that the Qubes firewall may revert to their original state, so it's quite easy for a firewall config change to blow those rules up, leaving the user with a leaky VPN. Granted, the firewall config change will only last about a half a second, because the user firewall script will be invoked afterwards, but during that half-second, traffic can leak via the eth0 route. OOPS! Now that is something interesting. So the Qubes firewall is supposedly bad. And we can let most users suffer whatever consequences when they block traffic with sys-firewall, because only our specific VPN application matters?? Keeping in mind that the default policy of FORWARD is DROP, we should also consider whether a stream of iptables commands is too slow to be secure. And if so, ask why 1) the user firewall rules are in script format; Or why 2) the commands aren't all combined for an iptables-restore; Or why 3) the chains aren't started with a temporary REJECT while they are being populated. ANY. ONE. Of these will address the issue for VPNs and all the other use cases. 'OOPS!' Here is bog-standard advice for properly handling firewall rules in Fedora: https://fedoraproject.org/wiki/How_to_edit_iptables_rules Or how about: $ cat internal-qubes-rules qubes-user-rules iptables-commit-cmd | iptables-restore At this point, we all need to know if Qubes firewall will be fixed in a timely fashion. I am wondering what the heck "reasonably secure OS" is supposed to mean in this context. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/95b5e003-c4a9-ae0b-823c-70d276c7a69d%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 02:14 PM, Chris Laprise wrote: > > So this is dependent on OpenVPN's features, again. Yes, I make no secret of the fact that my software depends on OpenVPN. I accept contributions to make it work with other VPN solutions. > > And is forcing your routing schema on an unknown VPN topology wise? I don't know what you mean by "forcing" or "my schema" or "wise". I know that my program creates a private routing table for the VPN, so the system routing table is not affected. This is less unsafe than, for example, what NetworkManager VPN does — which alters your system routing table. > > Routing tables should be irrelevant to whether non-VPN traffic is > blocked by a proxyVM. This is a nice opinion, and you are entitled to it. However, it turns out that using a blackhole routing rule is quite effective at blocking any and all non-VPN traffic. > A VPN server should be able to push down whichever routes it sees fit, > without any risk of leakage even if those rules are malicious... or > simply a configuration you can't anticipate. Oh, that's true. And Qubes-VPN supports that. Because it uses a separate routing table, the system's operation is not affected even if the VPN server sends malicious or nonsensical routes. > > Making the solution dependent on routing tables just makes the > security *and* the operation more precarious. While Qubes VPN does not depend solely on routing tables, I would like to see you prove these allegations. This allegation of yours sounds like something you can prove by reasoning or by example. Why not do it? Let's also get one thing out of the way here, because what you're saying here is borderline FUD. ALL VPN solutions depend upon routing tables. There are no VPNs that do not use routing tables on the client to direct traffic. Qubes VPN merely uses a *separate* routing table, not the system routing table (table #0). So when you say that "making the solution dependent on routing tables" is somehow bad, you're attacking *all* VPN software. > >> >>> * Interdependent packet marking, detection and routing rules are >>> needlessly complex >> FWMARK was the only way to get blackholing to work reliably without >> interference from the Qubes OS firewalling system. > > So you added complexity where simply blocking all forwarding to/from > eth0 would have sufficed. Not really. I implemented the simplest and least-invasive solution I could think of. It's four directives: 1. Instruct the routing engine to route all packets from downstream VMs to use table 78. This happens very early during boot, right after the Qubes OS default firewall rules are loaded, and so it happens that VMs cannot leak. 2. Tell table 78 to route all traffic to the VPN if the VPN interface is active, and to blackhole all traffic if the VPN interface goes down. This is actually quite cool, because there's no need to clean up anything if the VPN fails — the routes disappear when the TUN/TAP device goes away, leaving the blackhole route active. 3. Add two firewall rules directing all DNS requests from downstream VMs to the DNS servers of the VPN. I think, in my humble opinion, that this compares /quite favorably/ with (the doc) asking the user to write several scripts, all of which make much more invasive iptables modifications, while still allowing the VPN server to muck with the system routing table, a practice which under some circumstances could cause the ProxyVM itself to use the wrong DNS servers, or to fail to reconnect to the VPN. Additionally, I see that some of the tables that the doc's scripts modify are actually tables that the Qubes firewall may revert to their original state, so it's quite easy for a firewall config change to blow those rules up, leaving the user with a leaky VPN. Granted, the firewall config change will only last about a half a second, because the user firewall script will be invoked afterwards, but during that half-second, traffic can leak via the eth0 route. OOPS! > >>> * Hardly a model for 'fail closed': I forgot to mention that the software I wrote is 100% fail-closed. If the VPN fails, traffic from VMs will always be blackholed. There's no way that this rule can be altered by VMs or the VPN itself. >>> Instead of being steady-state, The steady fail-safe state is established very early on boot by the qubes-vpn-forwarding.service unit file. That steady fail-safe state — represented by the blackhole rule in table 78 and the firewall rule routing downstream traffic to table 78 — is never removed during any state transition. >>> blocking is dependent on state transitions in fw/routes (even worse, >>> ones that are initiated by OpenVPN events). Blocking should not >>> require active measures initiated by client software. >> Check the code again. Blocking happens way before VPN and Qubes >> Firewall starts. If there's a failure in the VPN, even if the >> re-blackholing fails, no traffic from the VMs will be routed, simply >> because
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 01:08 AM, Manuel Amador (Rudd-O) wrote: On 10/13/2016 03:13 AM, Chris Laprise wrote: Here is a rundown of initial concerns... * Routing tables should not be manipulated when VPN clients will surely do this as well The program prohibits OpenVPN from manipulating routing tables. So this is dependent on OpenVPN's features, again. And is forcing your routing schema on an unknown VPN topology wise? * Unknown side-effects with different VPN topologies (i.e. atypical routing commands pushed down to the VPN client) Almost no routing instructions are obeyed. Those which are obeyed, are applied to routing table 78, which prevents malicious server manipulation of ProxyVM routing tables. Routing tables should be irrelevant to whether non-VPN traffic is blocked by a proxyVM. A VPN server should be able to push down whichever routes it sees fit, without any risk of leakage even if those rules are malicious... or simply a configuration you can't anticipate. Making the solution dependent on routing tables just makes the security *and* the operation more precarious. * Interdependent packet marking, detection and routing rules are needlessly complex FWMARK was the only way to get blackholing to work reliably without interference from the Qubes OS firewalling system. So you added complexity where simply blocking all forwarding to/from eth0 would have sufficed. * Hardly a model for 'fail closed': Instead of being steady-state, blocking is dependent on state transitions in fw/routes (even worse, ones that are initiated by OpenVPN events). Blocking should not require active measures initiated by client software. Check the code again. Blocking happens way before VPN and Qubes Firewall starts. If there's a failure in the VPN, even if the re-blackholing fails, no traffic from the VMs will be routed, simply because everything is FWMARKed to go to routing table 78, which is dead by the time VPN fails. I can see the code where 'up' and 'down' are reconfiguring both iptables and routing tables. That is using OpenVPN events to shift between states, one of which is the so-called "blackhole" mode... which looks more like the makings for a zombie process. OTOH, its possible that Qubes proxyVMs might leak packets before Qubes firewall starts, as you claim. That has implications for *most* use cases involving proxyVMs. Did you think to test that and submit an issue? * Specific to Fedora template and hard-coded for OpenVPN Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is the standard ...is presumptuous. * Not /rw based; Adds more services to template Partially true. Config goes in /rw as it should. Services are optional and need to be specifically enabled. They need to be enabled, but they are still there. That does negatively affect security from the Qubes perspective; Why should we have even more privileged code laying around in multiple VMs just because one of them uses a VPN? Frankly, much better than an instruction manual, or putting all of the stuff in /rw/config/firewall stuff, because it being a package, it can be updated regularly, given a repo containing the packages. Yes, you were suggesting that people incorporate your repo, while pretending the Qubes-approved solution didn't exist. * Not tested with Whonix/Tor True. Then again, Whonix has its own "VPN" solution called TOR. Oh, OK. * Uncommented code There are a few comments now. Surely not enough to satisfy your standards, but I welcome pull requests. * A full throttle busy-wait loop in 'qubes-vpn-forwarding.in' Please point out the line of code where that happens. I don't think I have done that. Its the /only/ loop in that script ...and boy is it ugly. :) * Marketing hyperbole like "leak-proof" should be replaced with terms like "anti-leak" If you think it's possible to have this VPN leak, then prove you can cause a leak, and — if you succeed — I will plug the leak. Why move the goalposts? You explain why the existing solution, which is very unlike your complex set of rules, is insufficient *other* than not being packaged. * Critique of existing solution stops at 'No packaging'[1]; Oddly, nothing pertaining to anti-leak abili Sorry, gotta go to bed. I have a suggestion: I think we will collaborate better w.r.t bringing a standardized leak-proof solution to Qubes, if we approach the issue in a non-confrontational and collaborative way. I'm happy to have criticisms because they tend to improve the software, but I fail to see valid criticisms here, which makes me feel like you jumped to critiquing without trying what you were critiquing. Let's get some more solid criticisms based on facts and not on opinions or hunches. Lets "collaborate"? How disingenuous... We already have a Qubes-approved solution that is considered secure. You did not seek to package, improve, criticize or even /acknowledge/ it before you started suggesting
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 03:13 AM, Chris Laprise wrote: > Here is a rundown of initial concerns... > > * Routing tables should not be manipulated when VPN clients will > surely do this as well The program prohibits OpenVPN from manipulating routing tables. > > * Unknown side-effects with different VPN topologies (i.e. atypical > routing commands pushed down to the VPN client) Almost no routing instructions are obeyed. Those which are obeyed, are applied to routing table 78, which prevents malicious server manipulation of ProxyVM routing tables. > > * Interdependent packet marking, detection and routing rules are > needlessly complex FWMARK was the only way to get blackholing to work reliably without interference from the Qubes OS firewalling system. > > * Hardly a model for 'fail closed': Instead of being steady-state, > blocking is dependent on state transitions in fw/routes (even worse, > ones that are initiated by OpenVPN events). Blocking should not > require active measures initiated by client software. Check the code again. Blocking happens way before VPN and Qubes Firewall starts. If there's a failure in the VPN, even if the re-blackholing fails, no traffic from the VMs will be routed, simply because everything is FWMARKed to go to routing table 78, which is dead by the time VPN fails. > > * Specific to Fedora template and hard-coded for OpenVPN Yes, this is specific to Fedora and hard-coded for OpenVPN. OpenVPN is the standard these days. I welcome pull requests to enhance it for other VPN solutions. > > * Not /rw based; Adds more services to template Partially true. Config goes in /rw as it should. Services are optional and need to be specifically enabled. Frankly, much better than an instruction manual, or putting all of the stuff in /rw/config/firewall stuff, because it being a package, it can be updated regularly, given a repo containing the packages. > > * Not tested with Whonix/Tor True. Then again, Whonix has its own "VPN" solution called TOR. > > * Uncommented code > There are a few comments now. Surely not enough to satisfy your standards, but I welcome pull requests. > * A full throttle busy-wait loop in 'qubes-vpn-forwarding.in' Please point out the line of code where that happens. I don't think I have done that. > > * Marketing hyperbole like "leak-proof" should be replaced with terms > like "anti-leak" If you think it's possible to have this VPN leak, then prove you can cause a leak, and — if you succeed — I will plug the leak. > > * Critique of existing solution stops at 'No packaging'[1]; Oddly, > nothing pertaining to anti-leak abili Sorry, gotta go to bed. I have a suggestion: I think we will collaborate better w.r.t bringing a standardized leak-proof solution to Qubes, if we approach the issue in a non-confrontational and collaborative way. I'm happy to have criticisms because they tend to improve the software, but I fail to see valid criticisms here, which makes me feel like you jumped to critiquing without trying what you were critiquing. Let's get some more solid criticisms based on facts and not on opinions or hunches. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b7c01ccc-7a85-e86d-b1d8-97a8bfc3b101%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/13/2016 12:00 AM, Chris Laprise wrote: > On 10/12/2016 06:18 PM, Marek Marczykowski-Górecki wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On Wed, Oct 12, 2016 at 09:35:45PM +, Manuel Amador (Rudd-O) wrote: >>> It gives me great pleasure to release the first iteration of the >>> leakproof Qubes VPN. >>> >>> https://github.com/Rudd-O/qubes-vpn >>> >>> This package allows you to set up a leakproof OpenVPN VM on your Qubes >>> OS system. All VMs attached to the VPN VM are automatically and >>> transparently routed through the VPN. DNS requests do not hit the NetVM >>> they get routed through the VPN instead. >>> >>> Users and developers welcome to contribute to the project in any way >>> you >>> can! >> Nice! I've briefly reviewed it and it looks good :) >> >> I think it would be good to have it in standard repository. See >> "Packaging 3rd-party software" message on qubes-devel I just sent. >> >> - -- > > Although I like a packaged solution, I think anyone should be wary of > manipulating routing tables to create a "leak-proof" environment. > Hyperbole aside, VPN clients frequently change routing tables directly. My program directs openvpn not to change any routing tables and, in fact, tells openvpn to run in unprivileged mode where openvpn cannot change any routing tables itself. > > The firewall is more reliable for this application. It makes sense to > package the existing solution since we know its relatively client > agnostic and more importantly fills Patrick's requirements for Tor > isolation. Though I do not understand what you mean by "the firewall is more reliable", as my program runs under a ProxyVM fine, that solution should be packaged too, perhaps under a different name. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/571c7c4c-28c2-fcea-14f1-6b2bdaec06ff%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/12/2016 10:18 PM, Marek Marczykowski-Górecki wrote: > On Wed, Oct 12, 2016 at 09:35:45PM +, Manuel Amador (Rudd-O) wrote: > > It gives me great pleasure to release the first iteration of the > > leakproof Qubes VPN. > > > https://github.com/Rudd-O/qubes-vpn > > > This package allows you to set up a leakproof OpenVPN VM on your Qubes > > OS system. All VMs attached to the VPN VM are automatically and > > transparently routed through the VPN. DNS requests do not hit the NetVM > > they get routed through the VPN instead. > > > Users and developers welcome to contribute to the project in any way you > > can! > > Nice! I've briefly reviewed it and it looks good :) > > I think it would be good to have it in standard repository. See > "Packaging 3rd-party software" message on qubes-devel I just sent. > Thank you. You may want to review the new update I just made. Gained new features and improved security. -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/021e8b58-491a-4efa-dbe9-a7f6c6aef439%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/12/2016 06:18 PM, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Oct 12, 2016 at 09:35:45PM +, Manuel Amador (Rudd-O) wrote: It gives me great pleasure to release the first iteration of the leakproof Qubes VPN. https://github.com/Rudd-O/qubes-vpn This package allows you to set up a leakproof OpenVPN VM on your Qubes OS system. All VMs attached to the VPN VM are automatically and transparently routed through the VPN. DNS requests do not hit the NetVM they get routed through the VPN instead. Users and developers welcome to contribute to the project in any way you can! Nice! I've briefly reviewed it and it looks good :) I think it would be good to have it in standard repository. See "Packaging 3rd-party software" message on qubes-devel I just sent. - -- Although I like a packaged solution, I think anyone should be wary of manipulating routing tables to create a "leak-proof" environment. Hyperbole aside, VPN clients frequently change routing tables directly. The firewall is more reliable for this application. It makes sense to package the existing solution since we know its relatively client agnostic and more importantly fills Patrick's requirements for Tor isolation. Chris -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2e6fcda3-c2bb-8a91-aac1-4ce877e2d74d%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Oct 12, 2016 at 09:35:45PM +, Manuel Amador (Rudd-O) wrote: > It gives me great pleasure to release the first iteration of the > leakproof Qubes VPN. > > https://github.com/Rudd-O/qubes-vpn > > This package allows you to set up a leakproof OpenVPN VM on your Qubes > OS system. All VMs attached to the VPN VM are automatically and > transparently routed through the VPN. DNS requests do not hit the NetVM > they get routed through the VPN instead. > > Users and developers welcome to contribute to the project in any way you > can! Nice! I've briefly reviewed it and it looks good :) I think it would be good to have it in standard repository. See "Packaging 3rd-party software" message on qubes-devel I just sent. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJX/rbOAAoJENuP0xzK19csrj0H+wXOEA0dvApo1TCQynJ1LImc +IPUu3cm8PrWa86+RQ5UsL7YKO+vhAjB2eW9KzCObKimWwd3UhGpXHQdlc4keEdy d8SLr7ipZm4Yl9L3ap/z/TMzf/tO9gGpNfNAloH8BJrlCh7Lf8+xhLqQ7ryFlplZ cxg+cXxpanxQbqc4ty395sfAznvLB040maxgJ9HX5zMi1hKBtdbfNcdGaHEsy3RI MdCvNr7JETj49InUuLbgSXhUZFyyZccN3EnZcSRhnRZ+VaGSTAEuFrczv7SA8GnF qYY1Te2pziMVOJwZA4ccm4MVXV8utRCjBygJe8MWBEDuAFZZF4W4myjP1sLAW8Q= =kxUp -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20161012221855.GI15776%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ANN: Leakproof Qubes VPN
On 10/12/2016 09:35 PM, Manuel Amador (Rudd-O) wrote: It gives me great pleasure to release the first iteration of the leakproof Qubes VPN. https://github.com/Rudd-O/qubes-vpn This package allows you to set up a leakproof OpenVPN VM on your Qubes OS system. All VMs attached to the VPN VM are automatically and transparently routed through the VPN. DNS requests do not hit the NetVM they get routed through the VPN instead. Users and developers welcome to contribute to the project in any way you can! (Nice documentation!) TU, Sir! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f182d02e-b143-ad31-7d93-b1f4076baf2f%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] ANN: Leakproof Qubes VPN
It gives me great pleasure to release the first iteration of the leakproof Qubes VPN. https://github.com/Rudd-O/qubes-vpn This package allows you to set up a leakproof OpenVPN VM on your Qubes OS system. All VMs attached to the VPN VM are automatically and transparently routed through the VPN. DNS requests do not hit the NetVM they get routed through the VPN instead. Users and developers welcome to contribute to the project in any way you can! -- Rudd-O http://rudd-o.com/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d9f52529-10df-b397-a45c-9f09056d874b%40rudd-o.com. For more options, visit https://groups.google.com/d/optout.
