Please don't block Tor users (installer.id.ee Linux Apt Repo)

Please do not configure your web server or upstream proxies to block Tor Exit Nodes. It harms users, blocks them from getting security-critical updates, and there's just no reason to do it.

I've been fighting for the past few hours to figure out why I couldn't install open-eid in Debian 10 running in an AppVM on QubesOS. I was able to access most repos fine, but I got (unclear) errors from the open-eid Ubuntu repos. It kept getting suck on apt update

root@debian-10:~# while true; do apt-get update; done
Hit:1 https://deb.debian.org/debian buster InRelease                                                                   
Hit:2 https://deb.qubes-os.org/r4.1/vm buster InRelease                                                                
Hit:3 https://deb.debian.org/debian-security buster/updates InRelease      
0% [Connecting to HTTP proxy (http://127.0.0.1:8082)]

After some time it would fail with Resource temporarily unavailable

root@debian-10:~# while true; do apt-get update; done
Hit:1 https://deb.debian.org/debian buster InRelease                                                                   
Hit:2 https://deb.qubes-os.org/r4.1/vm buster InRelease                                                                
Hit:3 https://deb.debian.org/debian-security buster/updates InRelease   
Hit:3 https://deb.debian.org/debian-security buster/updates InRelease                            
Ign:4 https://installer.id.ee/media/ubuntu bionic InRelease                
Err:5 https://installer.id.ee/media/ubuntu bionic Release
  Could not wait for server fd - select (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]

I've tried over-and-over, but I kept getting the same error.

Why Tor connectivity matters

While apt is generally one of the most secure ways to download software, it is still vulnerable to some attack surfaces, such as the indefinite freeze attack.

A recommended way to prevent yourself from being targeted by such attacks is to install all of your software via Tor. For this reason, many security-by-design GNU/Linux Operating Systems have built-in settings to install all software updates via Tor.

Using Tor for software updates is recommended by QubesOS since 2017.

In my case, I use QubesOS. Which is arguably one of the most secure Operating Systems available today. I take securing my cryptographic private keys very seriously, and I would only trust using my Estonian ID (Smart Card) on an isolated VM in Qubes limited only to the use of my Estonian ID (security through compartimentaliztaion).

At install time, I configured QubesOS to make all software updates go through my Whonix Gateway VM, thereby offering significant protection against indefinite freeze and other targeted attacks. My Debian TemplateVM does not have access to the Internet. The apt user can access the internet, but only via the Whonix Gateway -- forcing all update traffic through the Tor network.

I'm not sure how to change this post-install, and honestly--for security--I shouldn't have to change this behaviour.

And if I was to change it once so I could install the software, that would mean that I couldn't fetch any updates after I changed it back post-install of open-eid.

Blocking some users from being able to fetch security-critical updates of such a security-critical tool is dangerous and negligent.

Debugging Connection Issues

I tested loading other pages with curl. First I try an http site (no encryption). It loads fine.

user@debian-10:~$ time curl -sx http://127.0.0.1:8082 -Lk http://neverssl.com | head
<html>
    <head>
        <title>NeverSSL - Connecting ... </title>
        <style>
        body {
            font-family: Montserrat, helvetica, arial, sans-serif;
            font-size: 16x;
            color: #444444;
            margin: 0;
        }

real    0m0.878s
user    0m0.008s
sys 0m0.006s
user@debian-10:~$

Next I try an https site (with encryption). It also loads fine.

user@debian-10:~$ time curl -sx http://127.0.0.1:8082 -Lk http://michaelaltfield.net | head
<!DOCTYPE html>
<!--[if IE 6]>
<html id="ie6" lang="en-US">
<![endif]-->
<!--[if IE 7]>
<html id="ie7" lang="en-US">
<![endif]-->
<!--[if IE 8]>
<html id="ie8" lang="en-US">
<![endif]-->

real    0m1.648s
user    0m0.015s
sys 0m0.011s
user@debian-10:~$

Now I try the repo. It fails every time.

user@debian-10:~$ while true; do date; time curl --connect-timeout 6 -x http://127.0.0.1:8082 -Lk https://installer.id.ee/media/ubuntu/; done
Tue 12 Apr 2022 06:49:15 PM CEST
curl: (28) Operation timed out after 6000 milliseconds with 0 out of 0 bytes received

real    0m6.059s
user    0m0.009s
sys 0m0.008s

AppVM test (clearnet)

If I try to connect to the repo over the clearnet from an AppVM, it appears to work fine

user@disp5609:~$ time curl -s https://installer.id.ee/media/ubuntu/ | head
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
 <head>
  <title>Index of /media/ubuntu</title>
 </head>
 <body>
<h1>Index of /media/ubuntu</h1>
  <table>
   <tr><th valign="top"><img src="/icons/blank.gif" alt="[ICO]"></th><th><a href="?C=N;O=D">Name</a></th><th><a href="?C=M;O=A">Last modified</a></th><th><a href="?C=S;O=A">Size</a></th><th><a href="?C=D;O=A">Description</a></th></tr>
   <tr><th colspan="5"><hr></th></tr>

real    0m0.336s
user    0m0.025s
sys 0m0.010s
user@disp5609:~$

Conclusion

Because

I cannot connect to the open-eid apt repo from my TemplateVM (which MUST use Tor),
I can connect to all non-open-eid apt repos fine over Tor, and
I can connect to the open-eid apt repo fine over the clearnet

it appears that the open-eid repo's webserver is blocking traffic from Tor users.

Because:

open-eid is a critically important security tool
Tor is the recommended way to obtain software updates via apt
Not getting updates to security-critical tools like open-eid is a huge risk

It is critically important that the open-eid repository is accessible to Tor users.

Please fix this by allowing Tor users to access the open-eid repository.

Question to the sysadmin: Is there actually a reason that Tor blocking was done? I see no benefit to doing this.

Indeed, it can sometimes make sense to protect a website from Tor traffic if you're hosing sensitive/private information. Or where you need to rate-limit dynamically generated content.

But here we're talking about a simple apt repo. All of its contents in the document root is public. It's static content. There is no DB or dynamic server-side execution at load time.

If load is an issue, my recommendation is to cache the repo on a CDN. As this software is open-source, there are several CDNs that will provide this service for free.

What is the reason that the open-eid repo server is bocking Tor traffic? Is this simply an accidental misconfiguration?

Apologies for the delayed answer. Due to heavy policy regulations, the query needed firm implementation and analysis. All the necessary were made and should be resolved now.

@Counter178 I really appreciate movement here, but unfortunately it's still not possible to fetch updates from your Ubuntu repos over tor.

I tried this today, but I fist got the following error when running the install-open-eid.sh script:

...
### Installing from ubuntu-focal repository
Press ENTER to continue, CTRL-C to cancel

Adding RIA repository to APT sources list (/etc/apt/sources.list.d/ria-repository.list)
deb [signed-by=/usr/share/keyrings/ria-repository.gpg] https://installer.id.ee/media/ubuntu/ focal main
Adding key to trusted key set
0xC6C83D68 'RIA Software Signing Key <signing@ria.ee>'
Installing software (apt-get update && apt-get install open-eid)
Err:1 https://installer.id.ee/media/ubuntu focal InRelease                                  
  Invalid response from proxy: HTTP/1.0 500 Unable to connect  Server: tinyproxy/1.10.0  Content-Type: text/html  Connection: close     [IP: 127.0.0.1 8082]
Hit:2 https://deb.qubes-os.org/r4.1/vm bullseye InRelease                                   
Hit:3 https://deb.debian.org/debian bullseye InRelease
Hit:4 https://deb.debian.org/debian-security bullseye-security InRelease
Reading package lists... Done
E: Failed to fetch https://installer.id.ee/media/ubuntu/dists/focal/InRelease  Invalid response from proxy: HTTP/1.0 500 Unable to connect  Server: tinyproxy/1.10.0  Content-Type: text/html  Connection: close     [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.
user@debian-11-estonia:~/QubesIncoming/estonia$

After that failed, I tried to just do an apt-get update directly. This failed with a 403 Forbidden error response from your servers (note that all other repos work fine; it's just RIA's servers that are broken).

user@debian-11-estonia:~/QubesIncoming/estonia$ sudo apt-get update
Hit:1 https://deb.qubes-os.org/r4.1/vm bullseye InRelease                                   
Err:2 https://installer.id.ee/media/ubuntu focal InRelease          
  403  Forbidden [IP: 127.0.0.1 8082]
Hit:3 https://deb.debian.org/debian bullseye InRelease
Hit:4 https://deb.debian.org/debian-security bullseye-security InRelease
Reading package lists... Done
E: Failed to fetch https://installer.id.ee/media/ubuntu/dists/focal/InRelease  403  Forbidden [IP: 127.0.0.1 8082]
E: The repository 'https://installer.id.ee/media/ubuntu focal InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
user@debian-11-estonia:~/QubesIncoming/estonia$

I tried to use curl to figure out what was going on, and then it became obvious

user@debian-11-estonia:~/QubesIncoming/estonia$ while true; do date; time curl --connect-timeout 6 -x http://127.0.0.1:8082 -Lk https://installer.id.ee/media/ubuntu/; done
Thu 06 Oct 2022 01:23:43 PM CDT
<!DOCTYPE html>
<html lang="en-US">
<head>
    <title>Just a moment...</title>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=Edge" />
    <meta name="robots" content="noindex,nofollow" />
    <meta name="viewport" content="width=device-width,initial-scale=1" />
    <link href="/cdn-cgi/styles/challenges.css" rel="stylesheet" />

</head>
<body class="no-js">
    <div class="main-wrapper" role="main">
    <div class="main-content">
        <h1 class="zone-name-title h1">
            <img class="heading-favicon" src="/favicon.ico"
                 onerror="this.onerror=null;this.parentNode.removeChild(this)" />
            installer.id.ee
        </h1>
        <h2 class="h2" id="challenge-running">
            Checking if the site connection is secure
        </h2>
...

This Checking if the site connection is secure message is clearly CloudFlare. But this is a misconfiguration.

Anti-bot protection, browser fingerprinting, etc should not be turned-on for web servers that communicate with other computers. This technology only makes sense to be turned-on for websites that are accessed by actual humans in a web browser. You can't have CloudFlare ask a user to solve a captcha or try to do fancy javascript things when it's a program like apt trying to speak through to the backend :D

Again, there is no security benefit to be had by turning on anti-bot protections for static site content that's public to the world. CloudFlare has a great CDN. Here's what you need to do:

Turn on CloudFlare's CDN to heavily cache your Ubuntu repo's static content with their varnish servers
Turn off all of CloudFlare's anti-bot protection for your Ubuntu repo endpoints

Again, this doesn't decrease your security at all. But it does increase the security of your users by allowing them to securely fetch updates via Tor to prevent things like targeted indefinite freeze attacks.

Forwarded & validated - the apt-get should be better now through TOR @maltfield

@Counter178 thank you!

I confirmed that I can now successfully install open-eid in a QubesOS TemplateVM

open-eid / linux-installer