When a Web browser uses an HTTP proxy, things go the following way. Let's assume that the target URL is http://www.example.com/index.html
. The browser then connects to the proxy and says to it: "I want to get the page at http://www.example.com/index.html
". The proxy complies, get the data, and sends it back to the browser. By construction, the proxy sees all the data. The connection between proxy and browser could be encrypted, but the proxy still sees everything.
If the target URL uses SSL (https://www.example.com/index.html
: mind the s
in https
), then the browser connects to the proxy, and tells it: "I want to connect to port 443 of www.example.com
; do it and then relay all bytes in both directions". Section 5.2 of RFC 2817 describes this mechanism. The proxy then acts as relay for all the bytes between the browser and the Web server, these bytes encoding whatever the browser and Web server wish them to be, i.e. in practice a SSL handshake and subsequent data. In that case, the proxy is outside of the SSL tunnel and cannot see the exchange data. The SSL tunnel is still between the Web server and the browser, and the proxy is a purely transport mechanism.
The proxy is still in ideal position to attempt Man-in-the-Middle attacks, since all communications go through it; but SSL is protected against that, namely by virtue of the Web server certificate being validated by the client. This of course relies on the human user not to click through warnings about invalid certificates. In some organizations, local sysadmins install extra "rogue" root CA certificates in desktop systems so that they may create fake server certificate on the proxy, and do the MitM attack, granting them access to the exchanged data (so that they can apply antivirus filters even on HTTPS traffic, or so they say at least).
Barring such a rogue CA installation (which is, basically, a breach into the security of the client machine), the proxy won't be able to peek at the data exchanged between the browser and the HTTPS server. The proxy will still be able to know which server was contacted, and to observe the size of the data exchanges: encryption hides the contents, not the size.
Situation for SOCKS is conceptually similar. The dialog between browser and proxy is different, but the basics remain the same: the proxy will be able to see all the HTTP traffic, and none of the HTTPS traffic.
Edit: apparently, some other kinds of "proxies" exist, in which your browser contacts a dedicated server, which itself runs a browser, does your browsing for you, and returns the pages to you. Unfortunately, some people call that "Web proxies", a terminology which has been in use for two decades to designate what is, technically, a HTTP proxy. Confusion ensues.
Such "browsing proxies" are similar, in concept, with opening a session on the server with a remote desktop protocol and running your browser from there. This grants all conceivable power to the proxy administrators on your browsing activities. You don't want to do that if you don't absolutely trust the proxy sysadmins.
And you'd prefer not use the "Web proxy" expression if there is any risk of ambiguity.