Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wildcards don't seem to work in the exclusions list #7

Closed
dhc02 opened this issue May 19, 2022 · 3 comments
Closed

wildcards don't seem to work in the exclusions list #7

dhc02 opened this issue May 19, 2022 · 3 comments

Comments

@dhc02
Copy link

dhc02 commented May 19, 2022

I've tried both *.dropbox.com and just dropbox.com, and in both cases subdomains continue to generate TLS handshake errors in the log. Adding each offending subdomain fixes it.

I also noticed that the UI says that domains that have handshake failures will be automatically added to the exclusion list, but that doesn't seem to be happening in my case.

Context: MacOS, pre-built binary

@Barre
Copy link
Owner

Barre commented May 19, 2022

I have tried both *.dropbox.com and just dropbox.com, and in both cases subdomains continue to generate TLS handshake errors in the log. Adding each offending subdomain fixes it.

The wildcard exclusion behavior is not exposed to end users by (current) design for three debatable reasons:

  • We use globset which is designed for paths here: https://github.com/Barre/privaxy/blob/main/privaxy/src/server/proxy/exclusions.rs#L9
  • If it is useful to exclude *.example.com, such an exclusion is probably useful to every privaxy user; and should instead be contributed to the project directly.
  • Excluding *.example.com may not be what most users would actually want to achieve if something is not working; it is probably more in the lines of "this website don't work properly, let's try this".

I also noticed that the UI says that domains that have handshake failures will be automatically added to the exclusion list, but that doesn't seem to be happening in my case.

Ah, thanks, I will fix this :)

It is a quirk from where it was the case. I then removed this behavior when the project was not yet published as I thought that it would then be trivial for websites to trigger this behavior and get excluded.

@dhc02
Copy link
Author

dhc02 commented May 20, 2022

It is a quirk from where it was the case. I then removed this behavior when the project was not yet published as I thought that it would then be trivial for websites to trigger this behavior and get excluded.

That's a great point. If this became widespread, the effectiveness of Privaxy could evaporate. Perhaps a good compromise would be to add handshake error domains into a checkbox list in the UI, so that it's quick and easy to add them as exclusions if that's what the user wants.

In this case, a total of 5 dropbox.com and dropboxapi.com domains were getting handshake errors (all from the MacOS client, not from visiting the website).

@Barre
Copy link
Owner

Barre commented Jun 6, 2022

I fixed the explanatory text in d2bfaeb.
I'm closing as of now as it's not really clear if wildcards are useful as a feature, except when done according to a vendor defined list such at what apple does here: https://support.apple.com/en-us/HT210060

@Barre Barre closed this as completed Jun 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants