Page MenuHomePhabricator

Removing vyatta-webproxy module
Open, Requires assessmentPublicFEATURE REQUEST

Description

Per T1730, I'm curious if anyone else believes it might be time to remove the vyatta-webproxy module entirely.

In 2019, a forward proxy basically doesn't work. HTTPS, Certificate pinning, HSTS, etc, all make it obsolete. Squid can do MITM (which is still pretty much hacky and of limited utility), but I don't think VyOS exposes enough config options to even make that work.

It makes me wish we had some sort of population survey to see how often it is used.

I'd be curious to see what other people think about just removing the whole module in future versions.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change

Event Timeline

kroy created this task.Tue, Oct 15, 4:25 AM
syncer added a subscriber: syncer.Tue, Oct 15, 4:29 AM

I will ask on customer survey but i know proxies used in enterprise environments not for caching or blocking but for securing access to public segments

runar added a comment.EditedTue, Oct 15, 4:01 PM

Also, as we are implementing this into the vyos cli, we can only omplement a small subset of the squid functionallity without doing lare efforts on implementing everything.. thats also why i favor to removing this functionallity..

Most enterprises use it still as a cheap authentication method, I'm totally in favor to drop it, not only in vyos. Breaking it off (they generate fitting ssl certs on the fly signed with a private PKI), is questionable as well, since I think https should be end to end encryption, everyone who messes with that idea, well I wouldn't trust them on other items as well.

One might need to differentiate between transparent bump-in-the-wire type squid deployments, and running it as a known proxy (delivered via DHCP and an onboard PAC file). Plus any kind of speedbump captive portal. I know one place specifically uses it to force clients to expose connecting hostname due to the use of the CONNECT command for TLS connections, for passive logging on the wire. Which will get interesting with the emergence of DoH and DoT in mainstream browsers, and enterprise efforts to kill that off.

At one point I was asked to put in DNS country code blocks (as stupid as that sounds, and I explained as such...) though in practice with the current squid/squidguard not being particularly oriented to retrieve external blocklists for ad suppression at least, one wonders what the next steps should be.

pasik added a subscriber: pasik.Wed, Oct 16, 9:00 PM