Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach <trip...@hackingthe.net> wrote:
> 
> On 03/13/2018 07:14 AM, Alex Dubois wrote:
>>> On 12 Mar 2018, at 18:40, David Hobach <trip...@hackingthe.net> wrote:
>>> 
>>>> On 03/11/2018 03:15 PM, David Hobach wrote:
>>>> An alternative might be to setup the local DNS service in a VM closer to 
>>>> the Internet, i.e. not in the proxy VM which also implements the qubes 
>>>> firewall.
>>>> Something like
>>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>>>> qubes-fw <-- client VM
>>>> I didn't test that though.
>>> 
>>> I just tested that as well now and it works as expected without any of the 
>>> aforementioned caveats.
>>> 
>>> So I'd recommend the one above over the previously discussed
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>>> (at least I was talking about that architecture - maybe the others were 
>>> talking about something different...).
>>> The same holds true for VPN users.
>> This type of architecture is bad practice as the attack surface of DNS is 
>> bigger than Qubes firewall, and an attack on this daemon compromise all 
>> traffic, not just DNS.
>> A better arch is
>> Internet
>> - netVM
>> - - firewallVM
>> - - - Service (ie DNS or VPN)
>> - - - clientVM1
>> - - - clientVM2
> 
> I believe your essential point was not to use proxy VMs for services at all.
> 
> My main point was not to mix a Qubes Firewall VM with local services. I think 
> you basically agree with that.

Yes agree

> 
> I however also disagree with your point wrt proxy VM usage as there's no 
> attack vector for E2E encrypted traffic on proxy VMs except for DoS which 
> you'll notice.

Let’s agree to disagree;). This is possibly true client to VPN, but the attack 
surface VPN to internetVPN is not small, there are a substantial number of line 
of code for the support of various protocols, with negotiation phases, parsing 
of data stream into such control flow. (I.e. some of the long list of OpenSSL 
vuln lead to remote code exec I suspect). 
So my point is you can use proxy if all the clients are going to use the VPN. 
And this apply also only if all the traffic would flow through the service (VPN 
use case OK, dns or http proxy not OK).

> If you're using non-E2E encrypted traffic (except for maybe DNS) you have a 
> different problem altogether and even then I'd trust my proxy VM a lot more 
> than any other hop (your Wifi provider? the 4+ backbone providers you pass?) 
> on the route to the destination.
I may have misunderstood you, but this is outside the subject of the discussion 
or please clarify. 

> 
> Moreover it is rather inconvenient to configure each and every client VM to 
> use that service VM which can also lead to unexpected misconfigurations & 
> leakages.
I agree that it is less trivial to setup but you lower your attack surface 
significantly.

So I agree that it depends on the circumstances, but I think my statement is 
preferable as a general rule, and I think Qubes should move toward supporting 
such setup, making it easier to configure. 

Best Regards
Alex
> 

-- 
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/14B0F388-B653-4981-A8B6-D0901E3B5B18%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to