disable onions by default due to unreliability

Patrick · 2019-01-14 12:50:56 UTC

At the moment we enable both, onions (primary) and clearnet (fallback) apt sources.

Proposed change: disable (comment out) onions by default

Reasons: Enabling it was an experiment which failed. Unreliable, bad usability (many support requests), reflects badly on Whonix.

Once Debian provides onion v3 with onionbalance which works reliable we may reconsider.

Once reliable we may even implement:
use onion sources list exclusively for apt-get updating by default
https://phabricator.whonix.org/T812

TNT_BOM_BOM · 2019-01-15 10:37:26 UTC

Then in this case add ssl/tls to whonix clearnet repo, because using http repo still reflects badly on whonix. (Debian and Qubes both have ssl support repos).

Patrick · 2019-01-15 12:14:17 UTC

deb.debian.org instead of us.debian.org and use https (SSL, TLS) by default
https://phabricator.whonix.org/T721

Qubes uses http, not https by default. See:

github.com

QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-r4.list.in

# Main qubes updates repository
deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@ main
#deb-src http://deb.qubes-os.org/r4.0/vm @DIST@ main

# Qubes updates candidates repository
#deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@-testing main
#deb-src http://deb.qubes-os.org/r4.0/vm @DIST@-testing main

# Qubes security updates testing repository
#deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@-securitytesting main
#deb-src http://deb.qubes-os.org/r4.0/vm @DIST@-securitytesting main

# Qubes experimental/unstable repository
#deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@-unstable main
#deb-src http://deb.qubes-os.org/r4.0/vm @DIST@-unstable main


# Qubes Tor updates repositories
# Main qubes updates repository
#deb [arch=amd64] http://deb.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/r4.0/vm @DIST@ main

This file has been truncated. show original

deb [arch=amd64] http://deb.qubes-os.org/r4.0/vm @DIST@ main

TNT_BOM_BOM · 2019-01-15 14:38:53 UTC

for Qubes this will be changed according to:

and whonix if a new version gonna come up then thats needs to be in the favor of user privacy not reverting things against the user privacy. so if not onion then ssl , but not zero.

also Debian they have V2 onion repos which is better in this case than Whonix even when using HTTPS repos.

and why we should use the default things to be secure? because thats back to the distro design which meant to be secure (&anonymous) in order to protect user privacy as much as possible. and i dont see using onion v2 or v3 or ssl things are impossible to implement by default.

HulaHoop · 2019-01-15 15:05:20 UTC

OK. Makes no sense to use something that works every now and then.

Sounds good.

With how bad TLS breaks apt in some cases we should pass. Also no point if it is not using Let’s Encrypt certs.

Patrick · 2019-01-15 17:20:45 UTC

Not done as per https://github.com/QubesOS/qubes-issues/issues/4415#issuecomment-454470103

Not sure it was clever by me to mention public perception.

If it’s just public perception it’s best to be quiet about it. No one going to dig deep and few going to complain.

https is going to reflect badly due to amazon AWS as per:

But it’s not a popularity contest.

I am not totally convinced that SSL makes things more secure either.
Note: talking about security, not about privacy.

gpg verification: considered strong and not broken
https:
- we don’t trust as per https://www.whonix.org/wiki/Warning#The_Fallible_Certificate_Authority_Model but somehow on subject of apt sources we suddenly trust it
- the many SSL security issues found in webservers and browsers over the recent years - how likely that APT isn’t scrutinized as much and has vulnerabilities related to SSL?
- https://curl.haxx.se/docs/security.html
- https://www.openssl.org/news/vulnerabilities.html
attack surface increased to both, the SSL verification code as well as the gpg verification code
- stacking up code can lead to a bigger code base that has to be trusted
- how could the gpg verification code be even attacked if SSL prevents any MITM from delivering malicious files?
  - Well, the files are provided by mirrors which are considered untrusted. Otherwise if SSL was so great we could in theory rely on SSL only and disable gpg verification.

But it always seems a good idea to combine levels of protections, and well, it’s what everyone is doing.

Do you mean https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build or something else?

https (SSL / TLS) by default broke apt-cacher-ng apt package caching during build is non-trivial but solvable somehow.

HulaHoop · 2019-01-16 15:38:44 UTC

Yes

TNT_BOM_BOM · 2019-01-17 16:07:42 UTC

onion v2 still valid choice and reliable and better than ssl , whether its for whonix or for debian or for both. aws or not , not much to care about since its debian.

0brand · 2019-01-18 02:06:42 UTC

A major issue is users are not updating their system due to .onion unreliability. I’d rather take the time to give a link so a user can add .onion repositories. (then knows where to look to see how to revert to http//uri when .onion repos are down). Less support requests this way too.

.onion repos are for advanced users so this makes sence until v3 has better reliability. Even then, still for advanced users IMO.

Patrick · 2019-01-20 05:00:12 UTC

Patrick · 2019-01-21 07:11:39 UTC

This is now in stretch-testers repository.

Patrick · 2019-02-01 09:45:15 UTC

http://vwakviie2ienjx6t.onion/debian down for me. Works for anyone else?

HulaHoop · 2019-02-01 15:43:41 UTC

Works for me. ™

Patrick · 2019-02-02 07:23:54 UTC

Can you open http://vwakviie2ienjx6t.onion/debian in a browser?

For me:

Not Found

The requested URL /debian was not found on this server.
Apache Server at vwakviie2ienjx6t.onion Port 80

Other onions working.

sheep · 2019-02-02 10:48:11 UTC

No:
http://vwakviie2ienjx6t.onion/debian

Yes:
http://vwakviie2ienjx6t.onion/debian/

The web server probably isn’t configured to try it as a directory without the “/”