An HTTP proxy receives a clear text request, and [in most, but not all cases] sends another HTTP request to the remote server, and then returns the information to the client.
An HTTPS proxy is a relay that receives a special HTTP request (CONNECT verb) and builds an opaque tunnel on the target server (which is not necessary even an HTTPS server). The client then sends an SSL / TLS request to the server and continues with SSL confirmation, and then with HTTPS (if required).
As you can see, these are two completely different types of proxies with different behaviors and different design goals. The HTTPS proxy server cannot cache anything because it does not see the request sent to the server. With an HTTPS proxy, you have a channel for the server, and the client receives and verifies the server certificate (and vice versa, vice versa). An HTTP proxy, on the other hand, sees and controls the request received from the client.
Although an HTTPS request can be sent through an HTTP proxy, it is almost never executed, because in this case the proxy server checks the serverβs certificate, but the client can receive and verify only the proxy certificate and as the name in the proxy certificate will not match the address, to which the socket is connected, in most cases a warning will be issued, and SSL-acknowledgment will not be performed (I will not go into details on how to try to solve this problem).
Finally, since an HTTP proxy can view the request, this invalidates the security idea provided by the HTTPS channel, so using an HTTP proxy for HTTPS requests is usually only for debugging purposes (again, we omit cases of paranoid company security policies that require monitoring all HtTPS traffic of company employees).
Addition: also read my answer on a similar topic here .
Eugene Mayevski 'Allied Bits
source share