For sdwdate:
Debian is just one entity. Would could add them here:
But as a single entity that has mirrors. We should give Debian too much power as a time provider by adding them as if they were hosted by different individuals/machines.
So it would be zero new time providers just one time provider with loads of new mirrors.
I’m for adding them as a single provider with many mirrors to avoid giving their servers too much weighting. Unless the infrastructure is hosted by different people with the organization. Do you know if that’s the case?
For mirrors do I put them between these brackets?
Probably not if it was all set up by the same person. Then this hosted
by different persons argument is refuted already.
HulaHoop:
For mirrors do I put them between these brackets?
Yes.
What pool should I put the Debian mirrors in?
SDWDATE_POOL_THREE. One entry with many mirrors so it requires a new grouping.
Debian and Tor Services available as Onion Services | The Tor Project
We, the Debian project and the Tor project are enabling Tor onion services for several of our sites. These sites can now be reached without leaving the Tor network, providing a new option for securely connecting to resources provided by Debian and Tor.
The freedom to use open source software may be compromised when access to that software is monitored, logged, limited, prevented, or prohibited. As a community, we acknowledge that users should not feel that their every action is trackable or observable by others. Consequently, we are pleased to announce that we have started making several of the various web services provided by both Debian and Tor available via onion services.
While onion services can be used to conceal the network location of the machine providing the service, this is not the goal here. Instead, we employ onion services because they provide end-to-end integrity and confidentiality, and they authenticate the onion service end point.
For instance, when users connect to the onion service running at http://sejnfjrq6szgca7v.onion/ using a Tor-enabled browser such as the TorBrowser, they can be certain that their connection to the Debian website cannot be read or modified by third parties, and that the website that they are visiting is indeed the Debian website. In a sense, this is similar to what using HTTPS provides. However, crucially, onion services do not rely on third-party certificate authorities (CAs). Instead, the onion service name cryptographically authenticates its cryptographic key.
In addition to the Tor and Debian websites, the Debian FTP and the Debian Security archives are available from .onion addresses, enabling Debian users to update their systems using only Tor connections. With the apt-transport-tor package installed, the following three lines can replace the normal debian mirror entries in the apt configuration file (/etc/apt/sources.list):
deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main
Likewise, Tor’s Debian package repository is available from an onion service :
deb tor+http://sdscoq7snqtznauu.onion/torproject.org jessie main
Now, my question. Since:
1. Whonix GW and Whonix WS templates show we have the apt-transport-https package installed:
dpkg --get-selections | grep apt
apt-transport-tor install
AND
2. /etc/apt/sources.list.d/debian.list shows:
deb http://security.debian.org jessie/updates main contrib non-free
deb http://ftp.us.debian.org/debian jessie main contrib non-free
Can we simply (and safely) replace the following onion addresses in both templates under a new user.list file as follows?
deb tor+http://vwakviie2ienjx6t.onion/debian jessie main
deb tor+http://vwakviie2ienjx6t.onion/debian jessie-updates main
deb tor+http://sgvtcaew4bxjd7ln.onion/debian-security jessie/updates main
I assume Whonix 14 will update the apt and other sources lists automatically to available .onion addresses so we can benefit from this major security improvement?
Man-in-the-middle attacks are common when using Whonix, as the documentation notes in various places.
It’s true but irrelevant since onion is different from https and the onions are not using https. ( Onion Services - Whonix )
Don’t use apt-transport-tor. In other words, don’t use tor+http. apt-transport-tor is required in Whonix, since apt-get is already pointed to Tor, torified. Just use the onions.
It’s not THAT bad with respect to apt-get since it uses verification. However, onions are good as defense in depth.
We have a ticket for that.
https://phabricator.whonix.org/T399
I am not sure when it’s sane to implement this. I encourage you and others to test updating using the onions. See if Debian keeps them. See how stable them are. If it’s stable we can of course use them, Not sure if in Whonix 14 or Whonix 15. Let’s see.
The worst case here would be we are migrating all Whonix users to the onion repositories and then these are overload and all users are stuck with broken updaters. That would be a small disaster.
I am not sure when it’s sane to implement this. I encourage you and others to test updating using the onions. See if Debian keeps them. See how stable them are. If it’s stable we can of course use them, Not sure if in Whonix 14 or Whonix 15. Let’s see.
why replace the mirrors ? instead add them to the current list , AFAIK apt is able to try one repo after the other (if one fails).
It’s an option (no duplicate sources warning, yay!) but we would loose some advantages.
Perhaps for a transition period.
Perhaps for a transition period.
yes , it seems to be the best option
no apt traffic leaving the Tor network
no Tor exit getting a chance to tamper with the traffic (example attack: send bogus gpg signatures that exploit a hypothetical gpg verification vulnerability)
we would gain those advantages when we do onion mirrors , which are IMHO strong arguments. I had multiple exit nodes mess with my traffic in the past(which made it sometimes almost impossible to update).
Hi Patrick,
Sorry typo there - I meant apt-transport-tor (fixed!)
OK - will test the onions and see how they go. Good to see you have a ticket for this item.
Cheers
I’ve been using the onion mirrors for updates for 3 months now. No issues / outages to report.
That is good to know.
This is implemented for Whonix 14:
⚓ T399 Switch Debian links in sources.list to .onion
Current status summary:
Whonix 13: http apt only
Whonix 14: http apt + onion apt (to see if nothing breaks once turning this on for all users)
Whonix 15: if Whonix 14 test went well - onion apt only
CVE-2016-1252 speaks for https.
Should we go for https for Whonix repository in meanwhile?
We’d not be able to use it everywhere. Debian does not offer https repositories.
May not be without issues. apt-transport-https has some obscure issue. (https://github.com/QubesOS/qubes-issues/issues/2520#issuecomment-267816404)
A Debian Developer making the case against apt-transport-https: Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Any opinions?
Not worth the hassle of going apt-https - since its not suported everywhere it would be of little benefit and because its inadequate against state-level adversaries or anyone who rummaged into a CA’s network.
You are right being cautious in the transition but IMO this recent event calls for onion only in Whonix 14.
should use http+tor / apt-transport-tor rather than Acquire::BlockDotOnion "false";:
⚓ T610 use tor+http / apt-transport-tor rather than Acquire::BlockDotOnion "false";
