'difference between http_proxy and https_proxy
I want to understand the difference between http_proxy and https_proxy environment variables.
So my understanding is that http_proxy will be used if I(as client) that sends http request. https_proxy will be used if I(as client) that sends https request.
There are some possible setting to set http_proxy and https_proxy:
1. http_proxy = http://proxy:port
2. https_proxy = http://proxy:port
3. http_proxy = https://proxy:port
4. https_proxy = https://proxy:port
As I understand, Variant 1, 2 may be common settings. What about variant 3, is it a possible setting? How are the requests transmitted? I think 4 is also a possible setting, but I am not clear about the workflow.
Here is my guess:
In first setting, if I send a http request to a destination server, then http_proxy will be used, with this setting, the request will be send as client --(http request) --proxy --(http request) -- server
In second setting, if I send a https request to a destination server, then https_proxy will be used, with this setting, the request will be client --(https request)-- proxy --(https request) --server. In this case, the proxy will just transmit encrypted packets to server, the packets will be decrypted only at server side.
In third setting, if I send a http request to a destination server, with this setting, what will happen? Is it a eligible setting?
In fourth setting, if I send a https request to a destination server, then https_proxy will be used, with this setting, the request will be send with client --(https request) --proxy --(https request) -- server. In this case, does that means the client's https request encrypted with proxy's public key, , which proxy decrypt the request first, then encrypted with destination server's pk, and then forward the request to server? however, in this case, isn't it break the end to end encryption between client and server? If my assumption is wrong, what is the correct picture for this setting?
Concretely, I want to know the workflow about packets flow from client - proxy - server with different proxies(http/https) and proxy setting (set it with http_proxy/https_proxy).
In all cases I assume server can accept both http/https request. What about if server only accept http/https request? What happen regarding the above setting and how they will be activated? I don't have a clear picture regarding to them.
Solution 1:[1]
In short, both http_proxy
and https_proxy
support proxy for either HTTP
or HTTPS
requests.
The difference is that http_proxy
does not encrypt the data transmission between the client and proxies, while https_proxy
does. So https_proxy proxies itself requires a TLS certificate.
Generally speaking, http_proxy
is enough for a local network. If you set the https_proxy
variable with proxies that only supports http_proxy
, the connection will not work properly.
Because there is no uniform regulation, for http_proxy
and https_proxy
variables, different programs may do different things.
In order to be compatible with different applications, we may add different styles, but in fact, as long as one of the following can be recognized by the application, the proxy should work normally (both HTTP and HTTPS request).
- http_proxy=http://user:pass@server:port
- http_proxy=https://user:pass@server:port
- https_proxy=https://user:pass@server:port
https_proxy=http://user:pass@server:port
Solution 2:[2]
I think the picture you have is entirely correct.
http_proxy / https_proxy should both point to a proxy server that can proxy requests upstream. http_proxy
would be used for plain http requests, meaning that the traffic from the client to the proxy would be unencrypted. https_proxy
is used for https requests. In both cases, the client first would send an HTTP CONNECT request for a specific upstream to the proxy (which results in a TCP tunnel being created between the proxy and the upstream), and then sends the actual payload. The actual payload could be either plaintext or TLS encrypted, relayed from the client directly to the upstream by the proxy, without it ever decrypting the packets. The proxy establishes a TCP connection with the upstream. From that point on, the proxy relays every request from the client directly to the upstream over this connection, and likewise delivers every response back to the client. This means, there is no TLS termination or origination happening at the proxy - which is completely unaware of the content.
You can have a TLS-enabled forward proxy server, but the mechanisms are slightly different. With http_proxy
and https_proxy
, your clients are aware of the proxy's presence and suitably change the HTTP request to make it amenable for a proxy. TLS-enabled forward proxies are usually transparent. They decrypt the clients request (TLS termination), initiate a new TLS request to the server using standard client credentials when applicable, and then relays back the response to the client after applying some security policies to the request / response. The http_proxy
/ https_proxy
environment variable don't directly have a role to play - nor is HTTP tunneling (via HTTP CONNECT or otherwise) involved.
In addition, there is another environment variable - NO_PROXY - which can be set to a comma-separated list of addresses, requests to which should not be proxied.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
Solution | Source |
---|---|
Solution 1 | |
Solution 2 |