This package registers the http.handlers.forward_proxy module, which acts as an HTTPS proxy for accessing remote networks.
This module is EXPERIMENTAL. We need more users to test this module for bugs and weaknesses before we recommend its use from within surveilled networks or regions with active censorship. Do not rely on this code in situations where personal safety, freedom, or privacy are at risk.
You can help by:
- Safely deploying this module
- Trying to break it
- Contributing to the code and tests in this repo to make it better
We are also seeking experienced maintainers who have experience with these kinds of technologies and who are interested in continuing its development.
Expect breaking changes.
- HTTP/1.1 and HTTP/2 support
- Authentication
- Access control lists
- Optional probe resistance
- PAC file
This Caddy module allows you to use your web server as a proxy server, configurable by numerous HTTP clients such as operating systems, web browsers, mobile devices, and apps. However, the feature set of each client varies widely, as does their correctness and security guarantees. You will have to be aware of each clients' individual weaknesses or shortcomings.
First, you will have to know how to use Caddy.
Build Caddy with this plugin. You can add it from Caddy's download page or build it yourself with xcaddy:
$ xcaddy build --with github.com/caddyserver/forwardproxy@caddy2
Most people prefer the Caddyfile for configuration. You can stand up a simple, wide-open unauthenticated forward proxy like this:
example.com
route {
# UNAUTHENTICATED! USE ONLY FOR TESTING
forward_proxy
}
(Obviously, replace example.com with your domain name which is pointed at your machine.)
Because forward_proxy is not a standard directive, its ordering relative to other handler directives is not defined, so we put it inside a route block. You can alternatively do something like this:
{
order forward_proxy before file_server
}
example.com
# UNAUTHENTICATED! USE ONLY FOR TESTING
forward_proxy
to define its position globally; then you don't need route blocks. The correct order is up to you and depends on your config.
This plugin enables Caddy to act as a forward proxy, with support for HTTP/2.0 and HTTP/1.1 requests. HTTP/2.0 will usually improve performance due to multiplexing.
Forward proxy plugin includes common features like Access Control Lists and authentication, as well as some unique features to assist with security and privacy. Default configuration of forward proxy is compliant with existing HTTP standards, but some features force plugin to exhibit non-standard but non-breaking behavior to preserve privacy.
Probing resistance—one of the signature features of this plugin—attempts to hide the fact that your webserver is also a forward proxy, helping the proxy to stay under the radar. Eventually, forwardproxy plugin implemented a simple reverse proxy (upstream https://user:[email protected] in Caddyfile) just so users may take advantage of probe_resistance when they need a reverse proxy (for example, to build a chain of proxies). Reverse proxy implementation will stay simple, and if you need a powerful reverse proxy, look into Caddy's standard proxy directive.
For a complete list of features and their usage, see Caddyfile syntax:
The simplest way to enable the forward proxy without authentication just include the forward_proxy directive in your Caddyfile. However, this allows anyone to use your server as a proxy, which might not be desirable.
Using the order directive you must give the order in which forward_proxy and other directives should be used.
In the Caddyfile the addresses must start with :443 for the forward_proxy to work for proxy requests of all origins.
Simple example that uses forward_proxy as first priority and as second just shows a webpage (using file_server directive) to hide that this is a proxy:
:443, example.com
route {
forward_proxy {
basic_auth user1 0NtCL2JPJBgPPMmlPcJ
basic_auth user2 密码
ports 80 443
hide_ip
hide_via
probe_resistance secret-link-kWWL9Q.com # alternatively you can use a real domain, such as caddyserver.com
serve_pac /secret-proxy.pac
dial_timeout 30
upstream https://user:[email protected]
acl {
allow *.caddyserver.com
deny 192.168.1.1/32 192.168.0.0/16 *.prohibitedsite.com *.localhost
allow ::1/128 8.8.8.8 github.com *.github.io
allow_file /path/to/whitelist.txt
deny_file /path/to/blacklist.txt
allow all
deny all # unreachable rule, remaining requests are matched by `allow all` above
}
}
file_server
}
-
basic_auth [user] [password]
Sets basic HTTP auth credentials. This property can only be supplied once. Note that this is different from Caddy's built-inbasic_authdirective. BE SURE TO CHECK THE NAME OF THE SITE THAT IS REQUESTING CREDENTIALS BEFORE YOU ENTER THEM.
Default: no authentication required. -
probe_resistance [secretlink.tld]
Attempts to hide the fact that the site is a forward proxy. Proxy will no longer respond with "407 Proxy Authentication Required" if credentials are incorrect or absent, and will attempt to mimic a generic Caddy web server as if the forward proxy is not enabled.
Probing resistance works (and makes sense) only ifbasic_authis set up. To use your proxy with probe resistance, supply yourbasic_authcredentials to your client configuration. If your proxy client(browser, operating system, browser extension, etc) allows you to preconfigure credentials, and sends credentials preemptively, you do not need secret link.
If your proxy client does not preemptively send credentials, you will have to visit your secret link in your browser to trigger the authentication. Make sure that specified domain name is visitable, does not contain uppercase characters, does not start with dot, etc. Only this address will trigger a 407 response, prompting browsers to request credentials from user and cache them for the rest of the session. Default: no probing resistance.
-
hide_ip
If set, forwardproxy will not add user's IP to "Forwarded:" header.
WARNING: there are other side-channels in your browser, that you might want to eliminate, such as WebRTC, see here how to disable it.
Default: no hiding;Forwarded: for="useraddress"will be sent out. -
hide_via
If set, forwardproxy will not add Via header, and prevents simple way to detect proxy usage.
WARNING: there are other side-channels to determine this.
Default: no hiding; Header in form ofVia: 2.0 caddywill be sent out.
-
ports [integer] [integer]...Specifies ports forwardproxy will whitelist for all requests. Other ports will be forbidden.
Default: no restrictions. -
acl { acl_directive ... acl_directive }
Specifies order and rules for allowed destination IP networks, IP addresses and hostnames. The hostname in each forwardproxy request will be resolved to an IP address, and caddy will check the IP address and hostname against the directives in order until a directive matches the request. acl_directive may be: - allow [ip or subnet or hostname] [ip or subnet or hostname]... - allow_file /path/to/whitelist.txt - deny [ip or subnet or hostname] [ip or subnet or hostname]... - deny_file /path/to/blacklist.txt
If you don't want unmatched requests to be subject to the default policy, you could finish
your acl rules with one of the following to specify action on unmatched requests:
- **allow all**
- **deny all**
For hostname, you can specify `*.` as a prefix to match domain and subdomains. For example,
`*.caddyserver.com` will match `caddyserver.com`, `subdomain.caddyserver.com`, but not `fakecaddyserver.com`.
Note that hostname rules, matched early in the chain, will override later IP rules,
so it is advised to put IP rules first, unless domains are highly trusted and should override the
IP rules. Also note that domain-based blacklists are easily circumventable by directly specifying the IP.
For `allow_file`/`deny_file` directives, syntax is the same, and each entry must be separated by newline.
This policy applies to all requests except requests to the proxy's own domain and port.
Whitelisting/blacklisting of ports on per-host/IP basis is not supported.
Default policy:
acl {
deny 10.0.0.0/8 127.0.0.0/8 172.16.0.0/12 192.168.0.0/16 ::1/128 fe80::/10
allow all
}
Default deny rules intend to prohibit access to localhost and local networks and may be expanded in future.
- dial_timeout [integer]
Sets timeout (in seconds) for establishing TCP connection to target website. Affects all requests.
Default: 20 seconds.
-
serve_pac [/path.pac]
Generate (in-memory) and serve a Proxy Auto-Config file on given path. If no path is provided, the PAC file will be served at/proxy.pac. NOTE: If you enable probe_resistance, your PAC file should also be served at a secret location; serving it at a predictable path can easily defeat probe resistance.
Default: no PAC file will be generated or served by Caddy (you still can manually create and serve proxy.pac like a regular file). -
upstream [
https://username:[email protected]:443]
Sets upstream proxy to route all forwardproxy requests through it. This setting does not affect non-forwardproxy requests nor requests with wrong credentials. Upstream is incompatible withaclandportssubdirectives.
Supported schemes to remote host: https.
Supported schemes to localhost: socks5, http, https (certificate check is ignored).
Default: no upstream proxy.
Linux 64bit binaries are at https://github.com/klzgrad/forwardproxy/releases
- Install Golang 1.14 or above and the
gitclient - Checkout repository:
git checkout https://github.com/klzgrad/forwardproxy.git - Change into directory:
cd forwardproxy - Install caddyservers xcaddy:
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest - Build caddy with forwardproxy:
xcaddy build --with github.com/caddyserver/forwardproxy@master=$PWD - Result is a
caddyexecutable that you can e.g. directly start withsudo ./caddy run(create yourCaddyfilein the same directory)
Manually install Caddy as a service on Linux with these instructions: Systemd unit example
Please be aware that client support varies widely, and there are edge cases where clients may not use the proxy when it should or could. It's up to you to be aware of these limitations.
The basic configuration is simply to use your site address and port (usually for all protocols - HTTP, HTTPS, etc). You can also specify the .pac file if you enabled that.
Read this blog post about how to configure your specific client.
Licensed under the Apache License
USE AT YOUR OWN RISK. THIS IS DELIVERED AS-IS. By using this software, you agree and assert that authors, maintainers, and contributors of this software are not responsible or liable for any risks, costs, or problems you may encounter. Consider your threat model and be smart. If you find a flaw or bug, please submit a patch and help make things better!
Initial version of this plugin was developed by Google. This is not an official Google product.