search

samuong / alpaca

A local HTTP proxy for command-line tools. Supports PAC scripts and NTLM authentication.
Apache License 2.0
184 stars 31 forks source link

Detect proxy.pac diffs #5

Open marcelocantos opened 5 years ago

marcelocantos commented 5 years ago

Alpaca could cache the current proxy.pac and, when it detects that the one being served up is different to the cached version, present the user with a diff and confirm whether to accept the new one, continue with the old one, or exit.

At one level, you kind of expect proxy.pac to be trustworthy, however, in some environments it might be delivered over insecure http and is thus susceptible to MITM attacks. #3

If the proxy.pac is delivered over https, the default could be to always trust new versions, with an option for the paranoid to force diff-prompting even then.

samuong commented 5 years ago

The more I think about this, the more I think that users should just download a PAC file themselves and configure Alpaca to download the PAC file from a file:// URL.

Alpaca currently uses an HTTP transport to download the PAC file, but it would need to use a file transport for local files.

marcelocantos commented 5 years ago

That would create more work for users and more opportunity to accidentally use an old PAC, which would be confusing and difficult to diagnose.

samuong commented 5 years ago

I'd like to avoid any user prompts so that Alpaca can run in daemon mode if needed (e.g. within a Docker container). I can think of a few more options to handle this:

  1. Force them to use a file:// URL, but continue to check the http:// URL for changes. Alpaca could then error out when the PAC file changes.
  2. Instead of having a local copy of the PAC file, a subresource integrity hash could be included in the config file. Error out (and output the new PAC file and integrity hash) when the PAC file changes. This is currently documented in the design doc.

Thoughts?

marcelocantos commented 5 years ago

At the end of the day, this really should be fixed at the source. How about just requiring https:// or --unsafe-proxy-pac-url http://…?

samuong commented 5 years ago

I get that it's a bit of a hassle, but it'd be nice to have a way to detect problems rather than just being helpless. I'm open to the idea of having something like an --i-understand-that-http-is-unsafe switch in addition to an integrity hash. But I think that's what issue #3 is for...

rtfmoz2 commented 2 years ago

If their is an existing proxy PAC it will always be internal to a company. If the company chooses to use http or https is really a security posture of the company. They may not consider the information to be sensitive like the bank I work for. That is because all the PAC file is doing it directing flows to proxies which have their own authentication. As a security consultant we would prefer https but in no way does it lowers the security posture of the organisation by using http. If their inside your network you have much bigger things to worry about than a http PAC file. The overall risk is negligible. Internal PAC policy is the domain of the company hosting it and not something you need to be concerned about.

My professional recommendation is allow either http/https and do not worry about it. The choice of a PAC file and its implementation is outside the scope of the application and part of the organisations security policy. Trying to improve security by taking a stronger position is the role of the CSO and not the application developer.

As for the new PAC file, as soon as you see a new one, validate its contents have no errors, then start using it immediately. Typically %95 of PAC updates are to correct an issue which means they are already late so implement them as soon as possible.

samuong commented 2 years ago

This issue was filed during a period of time when Alpaca was coming together, and I had to think all the design decisions and error cases that could arise. I've since come to a conclusion that's similar to yours: it's not Alpaca's problem to solve, and whoever is hosting the PAC file really needs to fix it. But if someone comes up with a nice way to handle this, it might be nice to build in to Alpaca.

Having said that, the issue here isn't that the PAC file contains sensitive information. An example is if an employee connects to a dodgy wifi hotspot at a coffee shop or a conference. The attacker is running their own DNS server, and sends requests for the PAC server domain to their own web server, which serves a PAC file that points a user at a fake proxy. This proxy could then be used to collect NTLM hashes, which can be trivially cracked via brute force.