Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Proxy server
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Transparent proxy=== <!-- was "Intercepting proxy servers" --> Also known as an '''intercepting proxy''', '''inline proxy''', or '''forced proxy''', a transparent proxy intercepts normal [[OSI model#Layer 7: Application layer|application layer]] communication without requiring any special client configuration. Clients need not be aware of the existence of the proxy. A transparent proxy is normally located between the client and the Internet, with the proxy performing some of the functions of a [[Gateway (computer networking)|gateway]] or [[router (computing)|router]].<ref>{{cite web |url=http://www.ukproxyserver.org/transparent-proxy/ |archive-url=https://web.archive.org/web/20130301235707/http://www.ukproxyserver.org/transparent-proxy/ |url-status=dead |archive-date=1 March 2013 |publisher=ukproxyserver.org |title=Transparent Proxy Definition |date=1 February 2011 |access-date=14 February 2013 }}</ref> {{IETF RFC|2616}} (Hypertext Transfer Protocol—HTTP/1.1) offers standard definitions: "A 'transparent proxy' is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification". "A 'non-transparent proxy' is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering". TCP Intercept is a traffic filtering security feature that protects TCP servers from TCP [[SYN flood]] attacks, which are a type of denial-of-service attack. TCP Intercept is available for IP traffic only. In 2009 a security flaw in the way that transparent proxies operate was published by Robert Auger,<ref>{{cite web |url=http://www.thesecuritypractice.com/the_security_practice/2009/03/socket-capable-browser-plugins-result-in-transparent-proxy-abuse.html |title=Socket Capable Browser Plugins Result in Transparent Proxy Abuse |publisher=The Security Practice |date=9 March 2009 |access-date=14 August 2010 |archive-date=2 February 2010 |archive-url=https://web.archive.org/web/20100202224537/http://www.thesecuritypractice.com/the_security_practice/2009/03/socket-capable-browser-plugins-result-in-transparent-proxy-abuse.html |url-status=live }}</ref> and the Computer Emergency Response Team issued an advisory listing dozens of affected transparent and intercepting proxy servers.<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/435052|title=Vulnerability Note VU#435052|publisher=[[United States Computer Emergency Readiness Team|US CERT]]|date=23 February 2009|access-date=14 August 2010|archive-date=10 July 2010|archive-url=https://web.archive.org/web/20100710185848/http://www.kb.cert.org/vuls/id/435052|url-status=live}}</ref> ====Purpose==== Intercepting proxies are commonly used in businesses to enforce acceptable use policies and to ease administrative overheads since no client browser configuration is required. This second reason, however is mitigated by features such as Active Directory group policy, or [[Dynamic Host Configuration Protocol|DHCP]] and automatic proxy detection. Intercepting proxies are also commonly used by ISPs in some countries to save upstream bandwidth and improve customer response times by caching. This is more common in countries where bandwidth is more limited (e.g. island nations) or must be paid for. ====Issues==== The diversion or interception of a TCP connection creates several issues. First, the original destination IP and port must somehow be communicated to the proxy. This is not always possible (e.g., where the gateway and proxy reside on different hosts). There is a class of [[Cross-site scripting|cross-site attacks]] that depend on certain behaviors of intercepting proxies that do not check or have access to information about the original (intercepted) destination. This problem may be resolved by using an integrated packet-level and application level appliance or software which is then able to communicate this information between the packet handler and the proxy. Intercepting also creates problems for [[HTTP]] authentication, especially connection-oriented authentication such as [[NTLM]], as the client browser believes it is talking to a server rather than a proxy. This can cause problems where an intercepting proxy requires authentication, and then the user connects to a site that also requires authentication. Finally, intercepting connections can cause problems for HTTP caches, as some requests and responses become uncacheable by a shared cache. ====Implementation methods==== In integrated firewall/proxy servers where the router/firewall is on the same host as the proxy, communicating original destination information can be done by any method, for example [[Microsoft Forefront Threat Management Gateway|Microsoft TMG]] or [[WinGate]]. Interception can also be performed using Cisco's [[Web Cache Communication Protocol|WCCP]] (Web Cache Control Protocol). This proprietary protocol resides on the router and is configured from the cache, allowing the cache to determine what ports and traffic is sent to it via transparent redirection from the router. This redirection can occur in one of two ways: [[GRE tunneling]] (OSI Layer 3) or MAC rewrites (OSI Layer 2). Once traffic reaches the proxy machine itself, interception is commonly performed with NAT (Network Address Translation). Such setups are invisible to the client browser, but leave the proxy visible to the web server and other devices on the internet side of the proxy. Recent Linux and some BSD releases provide TPROXY (transparent proxy) which performs IP-level (OSI Layer 3) transparent interception and spoofing of outbound traffic, hiding the proxy IP address from other network devices. ====Detection==== Several methods may be used to detect the presence of an intercepting proxy server: * By comparing the client's external IP address to the address seen by an external web server, or sometimes by examining the HTTP headers received by a server. A number of sites have been created to address this issue, by reporting the user's IP address as seen by the site back to the user on a web page. Google also returns the IP address as seen by the page if the user searches for "IP". * By comparing the results of online IP checkers when accessed using HTTPS vs. HTTP, as most intercepting proxies do not intercept SSL. If there is suspicion of SSL being intercepted, one can examine the certificate associated with any secure web site, the root certificate should indicate whether it was issued for the purpose of intercepting. * By comparing the sequence of network hops reported by a tool such as [[traceroute]] for a proxied protocol such as HTTP (port 80) with that for a non-proxied protocol such as SMTP (port 25).<ref>{{cite web|url=http://svn.haxx.se/dev/archive-2003-02/0257.shtml|title=Subversion Dev: Transparent Proxy detection (was Re: Introduction_|publisher=Tracetop.sourceforge.net|access-date=16 November 2014|archive-date=16 October 2015|archive-url=https://web.archive.org/web/20151016002253/http://svn.haxx.se/dev/archive-2003-02/0257.shtml|url-status=live}}</ref> * By attempting to make a connection to an IP address at which there is known to be no server. The proxy will accept the connection and then attempt to proxy it on. When the proxy finds no server to accept the connection, it may return an error message or simply close the connection to the client. This difference in behavior is simple to detect. For example, most web browsers will generate a browser created error page in the case where they cannot connect to an HTTP server but will return a different error in the case where the connection is accepted and then closed.<ref>{{cite book |last=Wessels |first=Duane |year=2004 |title=Squid The Definitive Guide |url=https://archive.org/details/squiddefinitiveg00wess_703 |url-access=limited |publisher=O'Reilly |isbn=978-0-596-00162-9 |pages=[https://archive.org/details/squiddefinitiveg00wess_703/page/n151 130]}}</ref> * By serving the [[End user|end-user]] specially programmed Adobe Flash SWF applications or Sun Java applets that send HTTP calls back to their server.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)