Privaxy only binds to 127.0.0.1

[chrisbensch]

I know this is currently on purpose, however, many of us would like to use this in our home environments. I've built a docker container with privaxy, but it doesn't work correctly with your restriction. Please remove this restriction.

[aequis]

You can change the line

privaxy/privaxy/src/server/main.rs

Line 38 in 1f6f968

let ip = [127, 0, 0, 1];

to 0.0.0.0, then build the backend again and it should work inside the docker container. At least until the developer adds a way to configure the IP address.

[gcormier]

I've changed line 38 to be 0.0.0.0, but now I get this upon startup.

thread 'main' panicked at 'no CA certificates found', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-rustls-0.23.1/src/config.rs:48:9

Did either of you run into this issue?

EDIT : Fork supports docker https://github.com/deetungsten/webui-privaxy

[mzy2240]

Any updates on this?

[andrioid]

I've been planning to install it on my ARM based router, so that house hold members can opt in for some adblocking. No rush though.

[Barre]

I previously didn't want to include configuration for this as it would also mean adding a setting to expose the web GUI which would have been a pretty major security risk as there was no authentication on the gui.

Since a few releases, the web GUI is now a desktop app and the "no_gui" binary has no GUI (though, privaxy is still configurable through editing ~/.privaxy/config) which makes it ok to build this.

I'll implement configuration for this soon.

[psycoxer]

Any updates on this?
I've built the NOGUI version while changing the IP to 0.0.0.0 in the source and run it from the local server. It does "work" as intended while connecting from other devices with the CA cert installed (found in config file), but with a few caveats:

1. Much slower than running locally (Tested with full gigabit ethernet , so network speed is not the bottleneck)
2. Need to constantly restart browsers (Some sites don't load at all with unknown cert error, but suddenly work fine upon restarting the browser (tested on chrome and firefox, from debian and windows) ) {problem persists even after rebooting}
3. It does not like android apps at all 😢 (with certificates installed) {Even tested with WSA running local proxy, no luck}
4. No official docker image

Are there any fixes to these problems? Anything planned?

[r0ckyjoe]

Any updates on this?

I've built the NOGUI version while changing the IP to 0.0.0.0 in the source and run it from the local server. It does "work" as intended while connecting from other devices with the CA cert installed (found in config file), but with a few caveats:

1. Much slower than running locally (Tested with full gigabit ethernet , so network speed is not the bottleneck)

2. Need to constantly restart browsers (Some sites don't load at all with unknown cert error, but suddenly work fine upon restarting the browser (tested on chrome and firefox, from debian and windows) ) {problem persists even after rebooting}

3. It does not like android apps at all 😢 (with certificates installed) {Even tested with WSA running local proxy, no luck}

4. No official docker image

Are there any fixes to these problems? Anything planned?

I am also interested in knowing more on this issue. Anybody's experiencing the same behavior?

[tjames192]

just to add, i am also looking forward to a release where binding privaxy to 0.0.0.0 is possible through a config file.
as a brand new user to privaxy and wanting network wide blocking, i just hex edited the windows privaxy.exe.
in your favorite hex editor find 7f 00 00 01
change
7f 00 00 01
to
00 00 00 00

[sheckandar]

just to add, i am also looking forward to a release where binding privaxy to 0.0.0.0 is possible through a config file. as a brand new user to privaxy and wanting network wide blocking, i just hex edited the windows privaxy.exe. in your favorite hex editor find 7f 00 00 01 change 7f 00 00 01 to 00 00 00 00

Thanks @tjames192

That worked beautifully.

This is, of course, a standard feature for all apps I've ever used.

I should be able to select interfaces or IP addresses I want the app to listen on.

[Wyk72]

I have a workaround for this, a bit ugly but works:

• run privaxy on any linux machine without interface, it will bind to 127.0.0.1:8100 as usual (.pem certs in .privaxy/config)

• download FRP (fast reverse proxy) here on github

• on your linux router (i.e. OpenWRT) or a Linux machine run the frps server, IP 192.168.1.1 in this example:

./frps -p 8100

• assuming your "network-wide" machine is 192.168.1.1 on the privaxy machine run something like

" ./frpc tcp -l 8100 -n privaxy -r 9100 -s 192.168.1.1 -P 8100"

Just point any machine in your network with "192.168.1.1:9100" as a filtering-https-proxy

I do this on my OpenWRT router (x86-64 based) with privaxy running into a small LXC container and works like a charm.

You can also do it easily in a Windows machine/virtual machine/whatever, but frpc/frps are difficult to use on windows because the dumb-as-fck defender antivirus keeps on deleting frpc/frps binaries.

I can hack the iptables of the main OpenWRT router to act as a full transparent proxy, I'll try that later today.

[klingon888]

I have a workaround for this, a bit ugly but works:

WOW.. this actually works! Thank you for the workaround. Response times are good too. I'm now able to use privoxy network-wide.

I can hack the iptables of the main OpenWRT router to act as a full transparent proxy, I'll try that later today.

Interested in any progress on this as i'm also using Openwrt. TQ.

[chrisbensch]

Many of us have switched to this repo https://github.com/deetungsten/webui-privaxy . Allows any IP and also retains the webui instead of being forced to use the app.

[Wyk72]

Yes, but you need docker to run it.

[candybars2021]

I really am still waiting for the day this will be implemented. On windows, I am unable to connect from other devices, it remains a proxy for itself only

[chrisbensch]

https://github.com/deetungsten/webui-privaxy This is a solid alternative I've been using for a little while. Built from an older version of Privaxy that doesn't require a desktop app, retains the webui, and is dockerized.

…

On Sat, May 18, 2024 at 12:02 PM candybars2021 ***@***.***> wrote: I really am still waiting for the day this will be implemented. On windows, I am unable to connect from other devices, it remains a proxy for itself only — Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHYPPAXACPZGGBYYJH7MP3ZC6QUHAVCNFSM5WQF6J5KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJRHA4TOMRTGE2A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[candybars2021]

I previously didn't want to include configuration for this as it would also mean adding a setting to expose the web GUI which would have been a pretty major security risk as there was no authentication on the gui.

Since a few releases, the web GUI is now a desktop app and the "no_gui" binary has no GUI (though, privaxy is still configurable through editing ~/.privaxy/config) which makes it ok to build this.

I'll implement configuration for this soon.

Any change of this promise being fulfilled if not "very soon" then after a year +++? Would save me a lot of previous wasted time and would be greatly appreciated

[Wyk72]

Any change of this promise being fulfilled if not "very soon" then after a year +++? Would save me a lot of previous wasted time and would be greatly appreciated

Be nice with developers of FREE software or hire/pay someone to solve your problems, if you can't do it yourself.
Your attitude is the worst.

[Barre]

If I haven't managed to do this yet, there's a good reason for it. We need authentication, but it's not happening over an encrypted channel since the client-proxy server connection occurs over HTTP. Therefore, currently, privaxy is not adequately protected to safely use outside of a local machine. I've been considering a new design that involves exposing privaxy as a WireGuard peer, but I haven't yet had time to complete it.

Doing this the right way is unfortunately not as easy as exposing a config option. I'll try to release something soon(ish).

[gcormier]

I find it counter productive you're deleting comments from people trying to help despite them not having the same ideas as you.

I don't have any need for authentication. I would never expose this outside my LAN, ever.

[Barre]

Who said you don't need encryption in your LAN? :)

[gcormier]

There's many other ways I can sniff my own traffic, I don't need privaxy to do so.

[joshrmcdaniel]

We need authentication, but it's not happening over an encrypted channel since the client-proxy server connection occurs over HTTP.

If an unknown person is able to sniff traffic on your LAN, there's a much bigger problem at hand than an unsecured proxy.

Assuming Privaxy is being ran on a server (per the comment you deleted, I run that on my HomeLab), my biggest concern is unauthenticated access to the frontend. Until proper user authentication is supported on the frontend, HSTS can be used as a quasi-auth to prevent connection without the presence of the root certificate (which is present in the comment deleted)

It seems in the past 2 years a solution for this has not been found, and I post a version here with the primary focus of it being ran on a server, just for it to be deleted does not seem right to the users wanting to run Privaxy as such

[Barre]

We need authentication, but it's not happening over an encrypted channel since the client-proxy server connection occurs over HTTP.

If an unknown person is able to sniff traffic on your LAN, there's a much bigger problem at hand than an unsecured proxy.

Assuming Privaxy is being ran on a server (per the comment you deleted, I run that on my HomeLab), my biggest concern is unauthenticated access to the frontend. Until proper user authentication is supported on the frontend, HSTS can be used as a quasi-auth to prevent connection without the presence of the root certificate (which is present in the comment deleted)

It seems in the past 2 years a solution for this has not been found, and I post a version here with the primary focus of it being ran on a server, just for it to be deleted does not seem right to the users wanting to run Privaxy as such

Spamming the issues with low-effort forks and expecting them to be embraced isn’t the way open-source projects work. If you have meaningful contributions, submit a pull request. Otherwise, don’t expect every half-baked solution to be welcomed.

Claiming that no solution has been found in two years is misleading. Privaxy is a very spare-time project, not a full-time job. If you want a feature, how about contributing to the codebase instead of complaining?

[joshrmcdaniel]

Spamming the issues with low-effort forks and expecting them to be embraced isn’t the way open-source projects work. If you have meaningful contributions, submit a pull request. Otherwise, don’t expect every half-baked solution to be welcomed.

Removing comments referencing forks that fix multiple "complaints" while insulting a user who breathes new life into a project last updated Jan 25, 2023 is not the way of open-source. I am one of many who wanted this as a server application.

Claiming that no solution has been found in two years is misleading.

Solution meaning this project, Privaxy, having the ability to advertise to addresses other than 127.0.0.1.
I'm aware of other "half-baked" solution (that you've done this too as well).

Privaxy is a very spare-time project, not a full-time job.

I'm aware this is not a full-time project, nor have any expectations of updates on it.

If you want a feature, how about contributing to the codebase instead of complaining?

What do you think my fork is for? I'm not complaining of the lack of features, I wanted numerous features, and I wrote those features.

The complaint is not about privaxy itself, the complaint is the removal of my comment.

[Barre]

Spamming the issues with low-effort forks and expecting them to be embraced isn’t the way open-source projects work. If you have meaningful contributions, submit a pull request. Otherwise, don’t expect every half-baked solution to be welcomed.

Removing comments referencing forks that fix multiple "complaints" while insulting a user who breathes new life into a project last updated Jan 25, 2023 is not the way of open-source. I am one of many who wanted this as a server application.

Claiming that no solution has been found in two years is misleading.

Solution meaning this project, Privaxy, having the ability to advertise to addresses other than 127.0.0.1. I'm aware of other "half-baked" solution (that you've done this too as well).

Privaxy is a very spare-time project, not a full-time job.

I'm aware this is not a full-time project, nor have any expectations of updates on it.

If you want a feature, how about contributing to the codebase instead of complaining?

What do you think my fork is for? I'm not complaining of the lack of features, I wanted numerous features, and I wrote those features.

The complaint is not about privaxy itself, the complaint is the removal of my comment.

The server version of Privaxy existed before, and it was I who wrote it. Instead of trying to promote your fork, you could have simply contributed a pull request to reintegrate the server functionality while keeping the GUI version intact. This would have benefited everyone without the unnecessary drama.

While I appreciate all contributions, your actions make it clear that you’re not here to support the project but to hijack attention for your own version. This is why your comments, which served more as self-promotion than constructive feedback, were removed. They did nothing to advance the project’s development and were simply attempts to redirect users to your fork.
Open-source communities thrive on collaboration, not on individuals trying to appropriate the work of others for personal gain.

If you’re serious about contributing, submit a detailed pull request. Otherwise, stop using this platform for self-promotion.