Patrick
January 14, 2019, 12:50pm
#1
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 defaulthttps://phabricator.whonix.org/T812
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
January 15, 2019, 12:14pm
#3
deb.debian.org instead of us.debian.org and use https (SSL, TLS) by defaulthttps://phabricator.whonix.org/T721
Qubes uses http, not https by default. See:
https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes-r4.list.in
deb [arch=amd64] http ://deb.qubes-os.org/r4.0/vm @DIST @ main
for Qubes this will be changed according to:
opened 08:04PM - 21 Oct 18 UTC
closed 10:08AM - 17 Feb 20 UTC
T: enhancement
C: Debian/Ubuntu
### Qubes OS version:
<!-- (e.g., `R3.2`)
You can get it from the dom0 te… rminal with the command
`cat /etc/qubes-release`
Type below this line. -->
Qubes 4
### Affected component(s):
Repositories with HTTP
---
### Steps to reproduce the behavior:
<!-- Use single backticks (`) for in-line code snippets and
triple backticks (```) for code blocks.
Type below this line. -->
Welcome to middle east
### Expected behavior:
To update/upgrade without interference from the ISP.
### Actual horror behavior:
I have discovered that Etisalat (ISP of UAE, so as it has branch in Egypt) names popped up in the middle of the `apt upgrade` inside debian.
```
user@user:~$ sudo apt update && sudo apt dist-upgrade && sudo apt autoremove --purge
Hit:1 https://deb.i2p2.de stretch InRelease
Ign:2 https://cdn-aws.deb.debian.org/debian stretch InRelease
Hit:3 https://cdn-aws.deb.debian.org/debian stretch-backports InRelease
Hit:4 https://cdn-aws.deb.debian.org/debian stretch Release
Get:6 https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=etisalat&ref=http://security.debian.org stretch/updates InRelease [6,505 B]
Err:6 https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=etisalat&ref=http://security.debian.org stretch/updates InRelease
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
Get:7 https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=etisalat&ref=http://deb.qubes-os.org/r4.0/vm stretch InRelease [6,505 B]
Err:7 https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=etisalat&ref=http://deb.qubes-os.org/r4.0/vm stretch InRelease
Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
Fetched 13.0 kB in 10s (1,198 B/s)
Reading package lists... Done
E: Failed to fetch http://security.debian.org/dists/stretch/updates/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
E: Failed to fetch http://deb.qubes-os.org/r4.0/vm/dists/stretch/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?)
E: Some index files failed to download. They have been ignored, or old ones used instead.
```
as we see , all HTTPS requests went through except Qubes and debian security repo which has an issue with their ssl or port configuration (thats why im using the default debian http repo):
```
user@user:~$ sudo apt update
Err:1 https://security.debian.org stretch/updates InRelease
Failed to connect to security.debian.org port 443: Connection refused
W: Failed to fetch https://security.debian.org/dists/stretch/updates/InRelease Failed to connect to security.debian.org port 443: Connection refused
W: Some index files failed to download. They have been ignored, or old ones used instead.
user@user:~$
```
The way that etisalat done the attack:
there is a payment page which is pushed from etisalat effecting only the HTTP request:
the HTTP URL used to manipulate firefox connection:
`https://onlineservices.etisalat.ae/scp/open/osdpages/billPayment.jsp?internetusername=etisalat&ref=http://detectportal.firefox.com/success.txt`
The page will show something like this if you will request any HTTP website through firefox:
Luckily i have used ooni-probe to detect if there is an network tampering for http manipulation and yep there was:
```
0.17s Runtime
Location: ZZ ‪(AS0)‬
Evidence of possible network tampering
When contacting our control servers we noticed that network traffic was manipulated. This means that there could be a “middle box” which could be responsible for censorship and/or traffic manipulation.
Technical measurement data
* ▶
annotations:{} 4 keys
* engine_name:"libmeasurement_kit"
* engine_version:"0.8.3"
* engine_version_full:"v0.8.3"
* platform:"ios"
* data_format_version:"0.2.0"
* id:"04cdfb30-8f78-4ac4-8bb1-77ee33dbdd1b"
* input:null
* input_hashes:[] 0 items
*
* measurement_start_time:"2018-10-21 00:00:00"
* options:[] 0 items
*
* probe_asn:"AS0"
* probe_cc:"ZZ"
* probe_city:null
* probe_ip:"127.0.0.1"
* report_id:"20181021T080301Z_AS0_Zc73b7lwkHuJwB2x1FOcp6Pf9HLXzPDX34IcrQ1lbD2NyajFNx"
* software_name:"ooniprobe-ios"
* software_version:"1.3.2"
* ▶
test_helpers:{} 1 key
* backend:"http://37.218.247.95:80"
* ▶
test_keys:{} 6 keys
* agent:"agent"
* client_resolver:"31.171.251.118"
* failure:null
* ▶
requests:[] 1 item
* ▶
0:{} 3 keys
* failure:null
* ▶
request:{} 5 keys
*
* ▶
response:{} 4 keys
*
* socksproxy:null
* ▶
tampering:{} 4 keys
* header_field_name:null
* header_name_diff:null
* request_line_capitalization:true
* total:true
* test_name:"http_header_field_manipulation"
* test_runtime:0.171327114105225
* test_start_time:"2018-10-21 00:00:00"
* test_version:"0.0.1"
```
### What we learn from this:
We need to use only HTTPS or Onion (or any better if there is alternative) for all the repos inside Qubes OS, from Qubes repos to fedora to debian to ...etc.
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.
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
January 15, 2019, 5:20pm
#6
Not done as per Egypt and UAE HTTP Repository Manipulation/Poison · Issue #4415 · QubesOS/qubes-issues · GitHub
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.
gpg verification: considered strong and not broken
https:
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.
2 Likes
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
January 18, 2019, 2:06am
#9
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.
2 Likes
Patrick
January 20, 2019, 5:00am
#10
https://github.com/Whonix/whonix-repository/commit/f04391c5ad438732c5a9ae886b926530e277e9cd
committed 04:57AM - 20 Jan 19 UTC
https://forums.whonix.org/t/disable-onions-by-default-due-to-unreliablity/6650
1 Like
Patrick
January 21, 2019, 7:11am
#11
1 Like
Patrick
February 1, 2019, 9:45am
#19
http://vwakviie2ienjx6t.onion/debian down for me. Works for anyone else?
1 Like
Patrick
February 2, 2019, 7:23am
#21
Can you open http://vwakviie2ienjx6t.onion/debian in a browser?
For me:
Not Found
The requested URL /debian was not found on this server.vwakviie2ienjx6t.onion Port 80
Other onions working.
sheep
February 2, 2019, 10:48am
#22
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 “/”
2 Likes
nyxnor
October 18, 2022, 5:42pm
#23
Just an “update” to this thread, the problem with onions are still the same, unreliable for updates unfortunately.
1 Like