impact of HTTP CONNECT on a mandatory web proxy policy

Consider a firewalled network with the high-level requirement that normal web browsing should work, but nothing else (e.g. ssh and Skype are forbidden). All traffic is blocked, except for outgoing HTTP(S) traffic which goes via a mandatory proxy.

What should the proxy do with HTTP CONNECT traffic? At one extreme, it could allow everything through, which would make the firewall ineffective. At the other extreme, it could be blocked: would this completely block HTTPS (I've noticed that wget uses CONNECT to tunnel https through $https_proxy: is this the universal method?)? (Assume the proxy is not going to play man-in-the-middle hoping that clients wouldn't notice the fake certificates.)

In other words, what is the practical “normal” use of CONNECT (with a proxy in the mix), and what is a good approximation of restricting its use to the “normal” cases?

_{(This is what I meant to ask when I asked my previous question.)}

Solution 1:

CONNECT is used to establish a bidirectionnal connection between the client and the remote server through the proxy. The protocol which passes inside the connection is just a problem between the client and the server, and does not concern the proxy. Most uses are for HTTPS, some uses are for WebSocket, other uses for remote desktop protocols, some people "illegaly" use it for SMTP, SSH, TELNET, or even HTTP in HTTP (to bypass controls).

That's why access to the CONNECT method much be restricted if you're trying to build a secure solution. First you must restrict the outgoing ports (allow only 443) and if your proxy can do that, you should ensure that what is transported really looks like SSL and not something else (eg: some people have an SSH backdoor on their HTTPS servers).