URL filtering HTTPS proxy

[solene]

Indeed, it might be worth adding both http_proxy and https_proxy too.

I’ll see if it’s possible to add a local firewall rule to redirect all http/https traffic to the proxy port. (this would be useful if you want to proxy everything).

[barto]

@solene

I’ll see if it’s possible to add a local firewall rule to redirect all http/https traffic to the proxy port

Too complicated, im(h)o. Just set all env variables (http_proxy, https_proxy, and all_proxy) to http://127.0.0.1:3128 …

[solene]

Yes, but all programs support using a http(s) proxy unfortunately

[solene]

I was just thinking that a systemd unit could monitor the domain list and automatically reload squid upon change Let’s work on it

[solene]

Podman uses HTTPS_PROXY

[peaceful_faraday]

Hi have not set this up yet. Are you referring to the case sensitivity in this message? If so and you wanted to use this proxy with a container running inside a qube would you alter the environment settings like so to pass the “host” network to the container?

mkdir -p /home/user/.config/environment.d/
cat <<EOF >/home/user/.config/environment.d/proxy.conf
HTTPS_PROXY=http://127.0.0.1:3128/

I’d test it out real quick myself but it sounds like you have experience with it already which might save me some troubleshooting.

Thank you!

[solene]

@peaceful_faraday

case sensitivity in this message?

Yes

@peaceful_faraday

you wanted to use this proxy with a container running inside a qube would you alter the environment settings like so to pass the “host” network to the container?

mkdir -p /home/user/.config/environment

I’m the container, the host’s localhost address is containers.internal from memory. The address would be http://containers.internal:3128/

[peaceful_faraday]

So instead of using podman config files and setting the container settings to host.containers.internal:3128 you would instead set it in proxy.conf file (not podman) to the case sensitive version and use containers.internal:3128 instead of host.containers.internal

Just to clarify, in the scenario I am referring to the container is using the same proxy that the VM uses. The contianer doesn’t need it’s own right? Is that even possible?
Also, I’m assuming you are referring to rootless podman in this scenario as well.

[solene]

@peaceful_faraday

host.containers.internal:3128

This is what you use within the container to use the proxy. I did not remember the hostname correctly in my post.

This is different than podman configuration file or environment variable for podman operations external to the container runtime, like fetching a container image.

[acdep]

One can create many disposable proxy vm using a single dvm with below approach

1. In dvm template add below lines to rc.local file. The script will copy a file with same name as vm to /rw/config/domains.txt

#!/bin/sh

VM_NAME="$(qubesdb-read /name)"

if [ -f "/rw/config/allow-list/${VM_NAME}" ]; then
  cp "/rw/config/allow-list/${VM_NAME}" "/rw/config/domains.txt"
  systemctl enable squid.service
  systemctl start squid.service
fi

2. Let’s say you want to create a proxy for your banking website, create a file ‘disp-bank-proxy’ in /rw/config/allow-list/ folder and create a named disposable disp-bank-proxy using the squid dvm.

When the disposable vm disp-bank-proxy is started, it’ll copy the file /rw/config/allow-list/disp-bank-proxy to /rw/config/allow-list/domains.txt.

With the above approach, you can create multiple named disposable for your different needs using a single dvm.

[solene]

This could go further by putting the domains in the qube settings in dom0, and then read it using qubesdb-read. There is a nice example of this in the guide to setup a hotspot using dev, the disposable is entirely parametric.

[solene]

I fixed the guide:

• squid service was disabled in the template but I didn’t write how to start in the proxy qubes, now it’s using a path condition in squid unit so it only starts when there is a domains.txt config
• fixed a few things

Tested on debian 13 with no issue

[ddevz]

@solene

This could go further by putting the domains in the qube settings in dom0, and then read it using qubesdb-read. There is a nice example of this in the guide to setup a hotspot using dev, the disposable is entirely parametric.

I had a similar idea a while back. Note that the qvm-firewall accepts text, not just accepts ip addresses for the “host” field. So one option would be to give policy permissions to qvm-firewall, then use qvm-firewall {hostname} list. a example might be something like:
qvm-firewall {hostname} --raw list | grep 'action=accept dsthost=' | sed 's/.*dsthost=\([a-z.]*\)/\1/' > /rw/config/allow-list/domains.txt

This would allow entry via the gui, under the firewall tab, making it obvious that it was configured. Of course it would also have a gui “port” and “protocol” field that are unused.

also, depending on how one sets up the netvm, it might conflict with the netvm