Squid_ The Definitive Guide - Duane Wessels [163]
http_port
Most likely, Squid is acting as a surrogate for your HTTP server on port 80. Use the http_port directive to make Squid listen on that port:
http_port 80
If you want Squid to act as surrogate and a caching proxy at the same time, list both port numbers:
http_port 80
http_port 3128
You can configure your clients to send their proxy requests to port 80 as well, but I strongly discourage that. By using separate ports, you'll find it easier to migrate the two services to separate boxes later if it becomes necessary.
https_port
You can configure Squid to terminate encrypted HTTP (SSL and TLS) connections. This feature requires the —enable-ssl option when running ./configure. In this mode, Squid decrypts SSL/TLS connections from clients and forwards unencrypted requests to your backend server. The https_port directive has the following format:
https_port [host:]port cert=certificate.pem [key=key.pem] [version=1-4]
[cipher=list] [options=list]
The cert and key arguments are pathnames to OpenSSL-compatible certificate and private key files. If you omit the key argument, the OpenSSL library looks for the private key in the certificate file.
The (optional) version argument specifies your requirements for various SSL and TLS protocols to support: 1=automatic, 2=SSLv2 only, 3=SSLv3 only, 4=TLSv1 only.
The (optional) cipher argument is a colon-separated list of ciphers. Squid simply passes it to the SSL_CTX_set_cipher_list( ) function. For more information, read the ciphers(1) manpage on your system or try running: openssl ciphers.
The (optional) options argument is a colon-separated list of OpenSSL options. Squid simply passes these to the SSL_CTX_set_options( ) function. For more information, read the SSL_CTX_set_options(3) manpage on your system.
Here are a few example https_port lines:
https_port 443 cert=/usr/local/etc/certs/squid.cert
https_port 443 cert=/usr/local/etc/certs/squid.cert version=2
https_port 443 cert=/usr/local/etc/certs/squid.cert cipher=SHA1
https_port 443 cert=/usr/local/etc/certs/squid.cert options=MICROSOFT_SESS_ID_BUG
httpd_accel_host
This is where you tell Squid the IP address, or hostname, of the backend server. If you use the loopback trick described previously, you write:
httpd_accel_host 127.0.0.1
Squid then prepends this value to partial URIs that get accelerated. It also changes the value of the Host header.[1] For example, if the client makes this request:
GET /index.html HTTP/1.1
Host: squidbook.org
Squid turns it into this request:
GET http://127.0.0.1/index.html HTTP/1.1
Host: 127.0.0.1
As you can see, the request no longer contains any information that indicates the request is for http://squidbook.org. This shouldn't be a problem as long as the backend server isn't configured for virtual hosting of multiple domains.
If you want Squid to use the origin server's hostname, you can put it in the httpd_accel_host directive:
httpd_accel_host squidbook.org
Then the request is as follows:
GET http://squidbook.org/index.html HTTP/1.1
Host: squidbook.org
Another option is to enable the httpd_accel_uses_host_header directive. Squid then inserts the Host header value into the URI for most requests, and the httpd_accel_host value is used only for requests that lack a Host header.
When you use a hostname, Squid goes through the normal steps to look up its IP address. Because you want the hostname to resolve to two different addresses (one for clients connecting to Squid and another for Squid connecting to the backend server), you should also add a static DNS entry to your system's /etc/hosts file. For example:
127.0.0.1 squidbook.org
You might want to use a redirector instead. For example, you can write a simple Perl program that changes http://squidbook.org/... to http://127.0.0.1/.... See Chapter 11 for the nuts and bolts of redirecting client