Squid Proxy Tunnel
Features/HTTPS – Squid Web Proxy Wiki
Version: 2. 5 More: RFC 2817, 2818, Features/SHTTP Contents
Feature: HTTPS (HTTP Secure or HTTP over TLS)
CONNECT tunnel
CONNECT tunnel through Squid
Intercepting CONNECT tunnels
Bumping CONNECT tunnels
Direct TLS connection
Direct TLS connection to a reverse proxy
Intercepting direct TLS connections
Bumping direct TLS connections
Encrypted browser-Squid connection
Chrome
Firefox When a client comes across an URL, it can do one of three things: opens an TLS connection directly to the origin server, or opens a tunnel through a proxy to the origin server using the CONNECT request method, or opens an TLS connection to a secure proxy. Squid interaction with these traffic types is discussed below.
The CONNECT method is a way to tunnel any kind of connection through an HTTP proxy. By default, the proxy establishes a TCP connection to the specified server, responds with an HTTP 200 (Connection Established) response, and then shovels packets back and forth between the client and the server, without understanding or interpreting the tunneled traffic. For the gory details on tunneling and the CONNECT method, please see RFC 2817 and the expired Tunneling TCP based protocols through Web proxy servers draft. CONNECT tunnel through Squid
When a browser establishes a CONNECT tunnel through Squid, Access Controls are able to control CONNECT requests, but only limited information is available. For example, many common parts of the request URL do not exist in a CONNECT request: the URL scheme or protocol (e. g.,,, ftp, voip, itunes, or telnet), the URL path (e. g., / or /secure/images/), and query string (e. g.? a=b&c=d) With HTTPS, the above parts are present in encapsulated HTTP requests that flow through the tunnel, but Squid does not have access to those encrypted messages. Other tunneled protocols may not even use HTTP messages and URLs (e. g., telnet). It is important to notice that the protocols passed through CONNECT are not limited to the ones Squid normally handles. Quite literally anything that uses a two-way TCP connection can be passed through a CONNECT tunnel. This is why the Squid default ACLs start with deny CONNECT! SSL_Ports and why you must have a very good reason to place any type of allow rule above them. Intercepting CONNECT tunnels
A browser sends CONNECT requests when it is configured to talk to a proxy. Thus, it should not be necessary to intercept a CONNECT request. TBD: Document what happens of Squid does intercept a CONNECT request, either because Squid was [mis]configured to intercept traffic destined to another proxy OR because a possibly malicious client sent a hand-crafted CONNECT request knowing that it is going to be intercepted. Bumping CONNECT tunnels
WARNING: HTTPS was designed to give users an expectation of privacy and security. Decrypting HTTPS tunnels without user consent or knowledge may violate ethical norms and may be illegal in your jurisdiction. Squid decryption features described here and elsewhere are designed for deployment with user consent or, at the very least, in environments where decryption without consent is legal. These features also illustrate why users should be careful with trusting HTTPS connections and why the weakest link in the chain of HTTPS protections is rather fragile. Decrypting HTTPS tunnels constitutes a man-in-the-middle attack from the overall network security point of view. Attack tools are an equivalent of an atomic bomb in real world: Make sure you understand what you are doing and that your decision makers have enough information to make wise choices. Squid SslBump and associated features can be used to decrypt HTTPS CONNECT tunnels while they pass through a Squid proxy. This allows dealing with tunneled HTTP messages as if they were regular HTTP messages, including applying detailed access controls and performing content adaptation (e. g., check request bodies for information leaks and check responses for viruses). Configuration mistakes, Squid bugs, and malicious attacks may lead to unencrypted messages escaping Squid boundaries. From the browser point of view, encapsulated messages are not sent to a proxy. Thus, general interception limitations, such as inability to authenticate individual embedded requests, apply here as well.
When a browser creates a direct TLS connection with an origin server, there are no HTTP CONNECT requests. The first HTTP request sent on such a connection is already encrypted. In most cases, Squid is out of the loop: Squid knows nothing about that connection and cannot block or proxy that traffic. The reverse proxy and interception exceptions are described below. Direct TLS connection to a reverse proxy
Squid-2. 5 and later can terminate TLS or SSL connections. You must have built with –enable-ssl. See _port for more information. Squid-3. 5 and later autodetect the availability of GnuTLS library and enable the functionality if available. OpenSSL must be enabled explicitly with the –with-openssl configure option. If the library is installed in a non-standard location you may need to use the –with-foo=PATH configure option. See configure –help for details. This is perhaps most useful in a surrogate (aka, accelerator, reverse proxy) configuration. Simply configure Squid with a normal reverse proxy configuration using port 443 and SSL certificate details on an _port line. Intercepting direct TLS connections
It is possible to intercept an HTTPS connection to an origin server at Squid’s _port. This may be useful in surrogate (aka, accelerator, reverse proxy) environments, but limited to situations where Squid can represent the origin server using that origin server SSL certificate. In most situations though, intercepting direct HTTPS connections will not work and is pointless because Squid cannot do anything with the encrypted traffic — Squid is not a TCP-level proxy. Bumping direct TLS connections
WARNING: HTTPS was designed to give users an expectation of privacy and security. A combination of Squid NAT Interception, SslBump, and associated features can be used to intercept direct HTTPS connections and decrypt HTTPS messages while they pass through a Squid proxy. This allows dealing with HTTPS messages sent to the origin server as if they were regular HTTP messages, including applying detailed access controls and performing content adaptation (e. Currently, Squid-to-client traffic on intercepted direct HTTPS connections cannot use Dynamic Certificate Generation, leading to browser warnings and rendering such configurations nearly impractical. This limitation will be addressed by the bump-server-first project. From the browser point of view, intercepted messages are not sent to a proxy. Thus, general interception limitations, such as inability to authenticate requests, apply to bumped intercepted transactions as well.
Squid can accept regular proxy traffic using _port in the same way Squid does it using an _port directive. RFC 2818 defines the protocol requirements around this. Unfortunately, popular modern browsers do not yet permit configuration of TLS encrypted proxy connections. There are open bug reports against most of those browsers now, waiting for support to appear. If you have any interest, please assist browser teams with getting that to happen. Meanwhile, tricks using stunnel or SSH tunnels are required to encrypt the browser-to-proxy connection before it leaves the client machine. These are somewhat heavy on the network and can be slow as a result. Chrome
The Chrome browser is able to connect to proxies over TLS connections if configured to use one in a PAC file or command line switch. GUI configuration appears not to be possible (yet). More details at Firefox
The Firefox 33. 0 browser is able to connect to proxies over TLS connections if configured to use one in a PAC file. GUI configuration appears not to be possible (yet), though there is a config hack for embedding PAC logic. There is still an important bug open: Using a client certificate authentication to a proxy: If you have trouble with adding trust for the proxy cert, there is a process by Patrick McManus to workaround that. CategoryFeature
Use Squid as HTTP / HTTPS / SSH Proxy – Squins IT Solutions
Written by Kees van Dieren Guide to install Squid proxy server to proxy HTTP, HTTPS and SSH. When is it useful Sometimes you need to serve the internet as if you are on another location. Some examples: Test CDN solutions View iOS / Android app store presence from various locations View localized Adwords / Facebook ads Use services that are available only in some territories Use SSH on a LAN that does not have outbound port 22 open Solutions Possible solutions to get a proxy: Use premium proxy service such as Smartproxy. Create simple server with Proxy server installed. We found the latter solution the most affordable and flexible. And it is easy as well. Configure Squid proxy on Ubuntu for HTTP, HTTPS and SSH create an Ubuntu or Debian Virtual server install the Squid proxy server: apt-get install squid configure squid (see chapter below: configure Squid) restart squid (service squid restart) Configure Squid Open the configuration file in an editor: vi /etc/squid/ Allow your client IP’s to use proxy Locate INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS and add the following lines below: acl holiday_location src 82. 236. 191. 91
_access allow holiday_location
Allow SSH port (22) to be proxied Locate acl SSL_ports port 443 Add above the following line: acl SSL_ports port 22 # ssh
Locate acl Safe_ports port 21 Add the following line below: acl Safe_ports port 22 # ssh
Restart Squid Don’t forget to restart squid using command: service squid restart Configure SSH clients to connect via proxy Install Corkscrew Next, in ~/, add the following block: host *
ProxyCommand corkscrew proxy-hostname-or-ip-address 8080%h%p
Now connect to SSH servers as usual to connect via a proxy. Alternative when configuration and installing Squid on Linux failed When installing Squid on Linux doesn’t succeed, try paid service Smartproxy. Posted in: Proxy ASO Kees van Dieren, CEO We’ve years of experience helping startups and scale-ups to work more efficient by creating apps that are fit their needs. Let’s talk. We look forward to exploring the opportunity to help your company too. Go ahead and send us a message. We look forward to exploring the opportunity to help you too.
How to configure an SSH proxy server with Squid – Fedora …
Sometimes you can’t connect to an SSH server from your current location. Other times, you may want to add an extra layer of security to your SSH connection. In these cases connecting to another SSH server via a proxy server is one way to get through.
Squid is a full-featured proxy server application that provides caching and proxy services. It’s normally used to help improve response times and reduce network bandwidth by reusing and caching previously requested web pages during browsing.
However for this setup you’ll configure Squid to be used as an SSH proxy server since it’s a robust trusted proxy server that is easy to configure.
Installation and configuration
Install the squid package using sudo:
$ sudo dnf install squid -y
The squid configuration file is quite extensive but there are only a few things we need to configure. Squid uses access control lists to manage connections.
Edit the /etc/squid/ file to make sure you have the two lines explained below.
First, specify your local IP network. The default configuration file already has a list of the most common ones but you will need to add yours if it’s not there. For example, if your local IP network range is 192. 168. 1. X, this is how the line would look:
acl localnet src 192. 0/24
Next, add the SSH port as a safe port by adding the following line:
acl Safe_ports port 22
Save that file. Now enable and restart the squid proxy service:
$ sudo systemctl enable squid
$ sudo systemctl restart squid
4. ) By default squid proxy listens on port 3128. Configure firewalld to allow for this:
$ sudo firewall-cmd –add-service=squid –perm
$ sudo firewall-cmd –reload
Testing the ssh proxy connection
To connect to a server via ssh through a proxy server we’ll be using netcat.
Install nmap-ncat if it’s not already installed:
$ sudo dnf install nmap-ncat -y
Here is an example of a standard ssh connection:
$ ssh
Here is how you would connect to that same server using the squid proxy server as a gateway.
This example assumes the squid proxy server’s IP address is 192. 63. You can also use the host-name or the FQDN of the squid proxy server:
$ ssh -o “ProxyCommand nc –proxy 192. 63:3128%h%p”
Here are the meanings of the options:
ProxyCommand – Tells ssh a proxy command is going to be used.
nc – The command used to establish the connection to the proxy server. This is the netcat command. %h – The placeholder for the proxy server’s host-name or IP address. %p – The placeholder for the proxy server’s port number.
There are many ways to configure an SSH proxy server but this is a simple way to get started.
The opinions expressed on this website are those of each author,
not of the author’s employer or of Red Hat. Fedora Magazine aspires to
publish all content under a Creative Commons license but may not be able
to do so in all cases. You are responsible for ensuring that you have the
necessary permission to reuse any work on this site. The Fedora logo is a
trademark of Red Hat, Inc. Terms and Conditions
