high-level target: templates should default update over Tor

[mfc]

whonix-gateway (or similar) should be default for all package traffic. This would reduce fingerprinting of apps, versions (and potential vulnerabilities) of a user. This should work also for dom0 updates, currently it does not.

I don't know if this is relevant, but Debian has apt-transport-tor and has recently created .onion repo mirrors.

whonix-gateway (or similar) need to be in a state that we can start more fully integrating Tor workflows into Qubes, given that it reduces information leakage and attack surface.

[unman]

It's already easy to do this now using a torVM, both for dom0 and template updates. Anyone who wishes to do it can do so right now with minimal fuss.
Whether it should be the default is a different matter. I think the answer to that will depend on what direction the project is going to take. For mainstream acceptance, (and corporate buy in), I seriously doubt that tor workflows will be a selling point. So maybe there should be different qubes flavours, or perhaps installing whonix templates should involve reconfiguration of the default updateVM to a VM behind a tor gateway: that sounds like a plausible path to me.

[unman]

It's already easy to do this now using a torVM, both for dom0 and template updates. Anyone who wishes to do it can do so right now with minimal fuss.
Whether it should be the default is a different matter. I think the answer to that will depend on what direction the project is going to take. For mainstream acceptance, (and corporate buy in), I seriously doubt that tor workflows will be a selling point. So maybe there should be different qubes flavours, or perhaps installing whonix templates should involve reconfiguration of the default updateVM to a VM behind a tor gateway: that sounds like a plausible path to me.

[bnvk]

It's already easy to do this now using a torVM, both for dom0 and template updates. Anyone who wishes to do it can do so right now with minimal fuss.

@unman I highly disagree with that it is easy. 90% of time I can't get TemplateVMs or dom0 to update over my TorrifiedVM

For mainstream acceptance, (and corporate buy in), I seriously doubt that tor workflows will be a selling point. So maybe there should be different qubes flavours

I highly agree that this should be a simple option to choose during setup as not all users will want deep Tor integration, but I suspect a majority of Qubes users will care + want this sort of thing. Hopefully, user testing data will help clarify this sort of thing!

[bnvk]

It's already easy to do this now using a torVM, both for dom0 and template updates. Anyone who wishes to do it can do so right now with minimal fuss.

@unman I highly disagree with that it is easy. 90% of time I can't get TemplateVMs or dom0 to update over my TorrifiedVM

For mainstream acceptance, (and corporate buy in), I seriously doubt that tor workflows will be a selling point. So maybe there should be different qubes flavours

I highly agree that this should be a simple option to choose during setup as not all users will want deep Tor integration, but I suspect a majority of Qubes users will care + want this sort of thing. Hopefully, user testing data will help clarify this sort of thing!

[unman]

@bnvk

I highly disagree with that it is easy. 90% of time I can't get TemplateVMs or dom0 to update over my TorrifiedVM

Really? I run all my VMs and updates through Tor and have done so for some time without issues.
Why not raise your problem on qubes-users?

[unman]

@bnvk

I highly disagree with that it is easy. 90% of time I can't get TemplateVMs or dom0 to update over my TorrifiedVM

Really? I run all my VMs and updates through Tor and have done so for some time without issues.
Why not raise your problem on qubes-users?

[mfc]

To be clear we are saying by default, which is currently not what happens. Saying it's easy because you have manually configured it is not the same thing.

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

re: our target users, they are targeted/at-risk users, not corporate users -- the same users or communities who would be interested in Tails (or Subgraph). So non-Tor traffic should be the exception, not the rule.

The project has already shifted in focus to this audience due to corporate customers not caring about security (not interested in funding/supporting Qubes), and our funding coming from folks interested in the security of at-risk users, not corporate users.

[mfc]

To be clear we are saying by default, which is currently not what happens. Saying it's easy because you have manually configured it is not the same thing.

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

re: our target users, they are targeted/at-risk users, not corporate users -- the same users or communities who would be interested in Tails (or Subgraph). So non-Tor traffic should be the exception, not the rule.

The project has already shifted in focus to this audience due to corporate customers not caring about security (not interested in funding/supporting Qubes), and our funding coming from folks interested in the security of at-risk users, not corporate users.

[unman]

@mfc
well, obviously you should raise the issue if you can't get these updates running through a torVM. I'd suggest the mailing list rather than raising a ticket straight off, but that's your call.

I made it clear that I see a difference between the manual configuration that can be done right now, and what the default should be. My question was whether the proposal would be an appropriate default.

As to whether the project has shifted in focus, I have no idea: that's why I raised the issue. I'm aware of the recent funding, but I don't think this in itself determines where things will go in the future, who the target users might be, or what features should be defaults. When I look at the road map, I see reference to corporate editions and other customized editions, and there are features going in that seem to indicate that that remains an important focus.

It's a mistake to say that corporate customers don't care about security, just because some of them don't share your concerns. You only need to look at the take up of Bromium to see that the isolation model is very attractive in that context, and that Qubes can play a part.

[unman]

@mfc
well, obviously you should raise the issue if you can't get these updates running through a torVM. I'd suggest the mailing list rather than raising a ticket straight off, but that's your call.

I made it clear that I see a difference between the manual configuration that can be done right now, and what the default should be. My question was whether the proposal would be an appropriate default.

As to whether the project has shifted in focus, I have no idea: that's why I raised the issue. I'm aware of the recent funding, but I don't think this in itself determines where things will go in the future, who the target users might be, or what features should be defaults. When I look at the road map, I see reference to corporate editions and other customized editions, and there are features going in that seem to indicate that that remains an important focus.

It's a mistake to say that corporate customers don't care about security, just because some of them don't share your concerns. You only need to look at the take up of Bromium to see that the isolation model is very attractive in that context, and that Qubes can play a part.

[adrelanos]

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

I'll likely implement this for Whonix 12.
make Qubes-Whonix-Gateway able to function as UpdateVM out of the box:
https://phabricator.whonix.org/T401

[adrelanos]

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

I'll likely implement this for Whonix 12.
make Qubes-Whonix-Gateway able to function as UpdateVM out of the box:
https://phabricator.whonix.org/T401

[adrelanos]

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

I'll likely implement this for Whonix 12.
make Qubes-Whonix-Gateway able to function as UpdateVM out of the box:
https://phabricator.whonix.org/T401

Done.

[adrelanos]

To support @bnvk I am not able to update dom0 over a whonix-gw vm nor torvm, and am only able to update templates with whonix-gw vm, not torvm. I agree that I should probably create a ticket about the dom0 issue.

I'll likely implement this for Whonix 12.
make Qubes-Whonix-Gateway able to function as UpdateVM out of the box:
https://phabricator.whonix.org/T401

Done.

[adrelanos]

I don't know if this is relevant, but Debian has apt-transport-tor and has recently created .onion repo mirrors.

• a) Torified updates, i.e. connecting to repositories over Tor is one thing.
• b) Accessing repositories over Tor hidden services is related, above a) is a pre-condition, but probably worth a separate ticket.

a) Is simple to implement/switch settings. (Set TemplateVMs to use Whonix-Gateway as NetVM + set Whonix-Gateway as dom0 updatevm.)

b) Looks not so simple to implement. I would argue, that this makes most sense, if you do it for all repositories. (In case of Debian templates: Qubes apt repo, Debian apt repo.) (In case of Whonix templates: plus additionally the Whonix apt repo and The Tor Project apt repository.) But that would require more infrastructure maintenance. Setting up a Qubes and a Whonix apt repository that is accessible through a Tor hidden service. Switching it on/off could be more difficult, i.e requiring changes in apt sources.list. Requires research.

b) has recently been requested at Whonix tracker.
Switch Debian links in sources.list to .onion:
https://phabricator.whonix.org/T399
I set it to wishlist and planned not to work on it myself, because running such infrastructure would cause additional maintenance effort. When we at Whonix were running a hidden service for whonix.org, we were not so amazed by it. Back then, issues that got no attention from The Tor Project for years. (Full story: hidden service for whonix.org taken offline) And I would also have to convince @QubesOS and The Tor Project to provide hidden services for their apt repositories. If you are convinced it's worthwhile at this point, we can go for it.

[adrelanos]

I don't know if this is relevant, but Debian has apt-transport-tor and has recently created .onion repo mirrors.

• a) Torified updates, i.e. connecting to repositories over Tor is one thing.
• b) Accessing repositories over Tor hidden services is related, above a) is a pre-condition, but probably worth a separate ticket.

a) Is simple to implement/switch settings. (Set TemplateVMs to use Whonix-Gateway as NetVM + set Whonix-Gateway as dom0 updatevm.)

b) Looks not so simple to implement. I would argue, that this makes most sense, if you do it for all repositories. (In case of Debian templates: Qubes apt repo, Debian apt repo.) (In case of Whonix templates: plus additionally the Whonix apt repo and The Tor Project apt repository.) But that would require more infrastructure maintenance. Setting up a Qubes and a Whonix apt repository that is accessible through a Tor hidden service. Switching it on/off could be more difficult, i.e requiring changes in apt sources.list. Requires research.

b) has recently been requested at Whonix tracker.
Switch Debian links in sources.list to .onion:
https://phabricator.whonix.org/T399
I set it to wishlist and planned not to work on it myself, because running such infrastructure would cause additional maintenance effort. When we at Whonix were running a hidden service for whonix.org, we were not so amazed by it. Back then, issues that got no attention from The Tor Project for years. (Full story: hidden service for whonix.org taken offline) And I would also have to convince @QubesOS and The Tor Project to provide hidden services for their apt repositories. If you are convinced it's worthwhile at this point, we can go for it.

[adrelanos]

Created a related ticket...
implement dom0 -> right click -> VM settings / easy way to configure updatevm setting
#1165

[adrelanos]

Created a related ticket...
implement dom0 -> right click -> VM settings / easy way to configure updatevm setting
#1165

[adrelanos]

create a Tor hidden service for deb.torproject.org [ .onion apt-get ]:
https://trac.torproject.org/projects/tor/ticket/17937

[adrelanos]

create a Tor hidden service for deb.torproject.org [ .onion apt-get ]:
https://trac.torproject.org/projects/tor/ticket/17937

[adrelanos]

Just now talked to Marek.

• We're going for a) Torified updates, i.e. connecting to repositories over Tor only in this ticket.
• If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

[adrelanos]

Just now talked to Marek.

• We're going for a) Torified updates, i.e. connecting to repositories over Tor only in this ticket.
• If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

[marmarek]

On Sun, Dec 27, 2015 at 07:48:07AM -0800, Patrick Schleizer wrote:

• We're going for a) Torified updates, i.e. connecting to repositories over Tor only in this ticket.

And in R3.1 we already have something like this - an firstboot option
for connecting everyting through sys-whonix.
Is that all, or we need something more here? @mfc

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?

[marmarek]

On Sun, Dec 27, 2015 at 07:48:07AM -0800, Patrick Schleizer wrote:

• We're going for a) Torified updates, i.e. connecting to repositories over Tor only in this ticket.

And in R3.1 we already have something like this - an firstboot option
for connecting everyting through sys-whonix.
Is that all, or we need something more here? @mfc

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?

[mfc]

nope that's perfect, I will close this issue. thanks patrick & marek!

[mfc]

nope that's perfect, I will close this issue. thanks patrick & marek!

[adrelanos]

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14. At least for a transitional period (Whonix 14) we will be using both, onions and regular http repositories in apt sources lists. (If that works out great, regular http repositories will be removed in Whonix 15.)

Accessing repositories over Tor hidden services (onions) may be mostly possible for Qubes also.

Debian, The Tor Project, and Whonix now all allow apt-get updating using Tor hidden services (onions).

• https://onion.debian.org
• https://onion.torproject.org

Afaik Fedora does not offer updating using Tor hidden services (onions), but we could post a feature request.

If b) Accessing repositories over Tor hidden services (onions) seems worth going for in Qubes, we should create a new ticket for that.

[adrelanos]

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14. At least for a transitional period (Whonix 14) we will be using both, onions and regular http repositories in apt sources lists. (If that works out great, regular http repositories will be removed in Whonix 15.)

Accessing repositories over Tor hidden services (onions) may be mostly possible for Qubes also.

Debian, The Tor Project, and Whonix now all allow apt-get updating using Tor hidden services (onions).

• https://onion.debian.org
• https://onion.torproject.org

Afaik Fedora does not offer updating using Tor hidden services (onions), but we could post a feature request.

If b) Accessing repositories over Tor hidden services (onions) seems worth going for in Qubes, we should create a new ticket for that.

[mfc]

If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14.

you want to create a separate ticket to track onion service repo implementation?

[mfc]

If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14.

you want to create a separate ticket to track onion service repo implementation?

[adrelanos]

Michael Carbone:

If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14.

you want to create a separate ticket to track onion service repo implementation?

If we want to go for it... Yes, a new ticket should be created. This was
a), and done, but b) is related and different.

[adrelanos]

Michael Carbone:

If you want b) Accessing repositories over Tor hidden services, please create a separate ticket.

b) Accessing repositories over Tor hidden services (onions) will be implemented for Whonix 14.

you want to create a separate ticket to track onion service repo implementation?

If we want to go for it... Yes, a new ticket should be created. This was
a), and done, but b) is related and different.

[andrewdavidwong]

Created: #2265.

[andrewdavidwong]

Created: #2265.