Those web proxies are capable of breaking the confidentiality of your HTTPS session, and they're capable of doing so and without being detected. For example, HideMyAss, ZendProxy, AWebProxy, or basically any of the results if you Google for "Web proxy". I'll not go in details, but basically, a web proxy is a website which you visit and ask it to "proxy"/"rout" a web page for you. You don't want to do that if you don't absolutely trust the proxy sysadmins.Īnd you'd prefer not use the "Web proxy" expression if there is any risk of ambiguity.įirst of all I'd like to make a distinction between what is commonly known as HTTP Proxies, for which, other answers apply, the confidentiality will not be broken unless you add the proxy's CA to your trusted CAs and Web Proxies (we still can't agree on a name, you may call it HTML Proxy or Browsing Proxy). This grants all conceivable power to the proxy administrators on your browsing activities. ![]() 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. 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. 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.Įdit: 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. Situation for SOCKS is conceptually similar. 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. 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).īarring 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. This of course relies on the human user not to click through warnings about invalid certificates. 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. The SSL tunnel is still between the Web server and the browser, and the proxy is a purely transport mechanism. In that case, the proxy is outside of the SSL tunnel and cannot see the exchange data. in practice a SSL handshake and subsequent data. ![]() 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. Section 5.2 of RFC 2817 describes this mechanism. If the target URL uses SSL ( : mind the s in https), then the browser connects to the proxy, and tells it: "I want to connect to port 443 of do it and then relay all bytes in both directions". The connection between proxy and browser could be encrypted, but the proxy still sees everything. By construction, the proxy sees all the data. The proxy complies, get the data, and sends it back to the browser. The browser then connects to the proxy and says to it: "I want to get the page at ". ![]() When a Web browser uses an HTTP proxy, things go the following way.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |