Debian update repos: transport security and privacy

Some friends and I have started thinking about ways to bring attention to this important issue.

In short, network adversaries can view not only what repositories your server operating system connects to (metadata), when (metadata), but precisely which updates are being applied. This allows a network adversary to not only know what vulnerabilities your operating system and applications are vulnerable to, but they know what applications are installed and likely running.

This critical issue is aside from the fact that most repository signing keys are using 1024-bit keys, some of which created in 2004 and do not expire. This is also aside from the fact that there are many man-in-the-middle attacks that HTTP is vulnerable to that high-grade HTTPS is not.

Further, no different than standard HTTP / HTTPS web browsing, non-Torified traffic is vulnerable to all types of Certificate Authority, Domain Name System, and Border Gateway Protocol attacks. It is equally critical to discuss apt-transport-tor.

Debian claims that HTTPS is not for privacy. In August 2014, B_Meson filed a bug on this issue, and it was closed.

Debian claims that apt-secure is good enough for security. This boils down to: “By adding a key to apt’s keyring, you’re telling apt to trust everything signed by the key.” Debian cannot assure that these keys have not been compromised. In Ubuntu, there is still a 1024-bit master signing key from 2004 in the apt-key keychain that does not expire!

I’ve purchased “” (not active) presuming that this will be the homepage for this initiative. The initiative includes documenting popular repos, grade their SSL/TLS, and shame organizations that are neglecting our security and privacy. Default security and privacy is a requirement.

Below is my initial list of popular repositories. Most fail. I am looking for feedback and advice on how we should document these problems and how we can best influence repository maintainers to care about modern security concerns.


  • http is bad.
  • https is better for security.
  • tor+http is better for privacy.
  • tor+https is better for security and privacy.
  • http .onion is best for security and privacy.


  • Does apt-transport-https support configurations such as PFS, HSTS, HSTS Preload, or HPKP?
  • Can installing apt-transport-tor be configured to automatically replace known repos with an Onion replacement in sources.list?
  • Post-Snowden, why isn’t apt-transport-tor the default for all OS distributions?


Debian OS:

Ubuntu OS:

Tails OS (using apt-transport-tor by default):

Subgraph OS (using apt-transport-tor by default):

Kali OS:


Debian nor Ubuntu distinguishes HTTPS mirrors:

Debian OS mirrors (ideal):
http://m4dcywym6p6poxdm.onion/debian/ (Info: http://onionmirors63y7c.onion/)

Ubuntu PPAs:

Tor Project, Inc apps:


An excellent discussion concerning Tails. Tails is a Debian based client and has different threat models than Debian based servers.

I’ve started a Google Doc list grading mirrors.


Here’s what an improved Ubuntu configuration might look like:

sudo apt-get install apt-transport-tor
sudo vim /etc/apt/sources.list
deb tor+ wily main restricted
deb tor+ wily-updates main restricted
deb tor+ wily universe
deb tor+ wily-updates universe
deb tor+ wily multiverse
deb tor+ wily-updates multiverse
deb tor+ wily-backports main restricted universe multiverse
deb tor+ wily-security main restricted
deb tor+ wily-security universe
deb tor+ wily-security multiverse

Debian example:

sudo apt-get install apt-transport-tor
sudo vim /etc/apt/sources.list
deb tor+http://m4dcywym6p6poxdm.onion/debian/ jessie main
deb tor+http://m4dcywym6p6poxdm.onion/debian/ jessie-updates main
deb tor+ jessie-updates main