Feature: Squid-in-the-middle SSL Bump
Goal: Enable ICAP inspection of SSL traffic.
Developer: AlexRousskov, Christos Tsantilas
Squid-in-the-middle decryption and encryption of straight CONNECT and transparently redirected SSL traffic, using configurable CA certificates. While decrypted, the traffic can be analyzed, blocked, or adapted using regular Squid features such as ICAP and eCAP.
By default, most user agents will warn end-users about a possible man-in-the-middle attack.
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.
Here is a sample squid.conf excerpt with SSL Bump-related options:
Enabling SSL Bump
Example of how to configure the HTTP port to bump CONNECT requests
http_port 3128 ssl-bump cert=/usr/local/squid3/etc/site_priv+pub.pem # Bumped requests have relative URLs so Squid has to use reverse proxy # or accelerator code. By default, that code denies direct forwarding. # The need for this option may disappear in the future. always_direct allow all
ssl_bump is used to prevent some requests being bumped.
Example of how to avoid bumping requests to sites that Squid cannot proxy well
acl broken_sites dstdomain .example.com ssl_bump deny broken_sites ssl_bump allow all
Certain certificate errors may occur which are not really problems. Such as an internal site with self-signed certificates, or an internal domain name for a site differing from its public certificate name.
The sslproxy_cert_error directive and the ssl_error ACL type allow these domains to be accepted despite the certificate problems.
SECURITY WARNING: ignoring certificate errors is a security flaw. Doing it in a shared proxy is an extremely dangerous action. It should not be done lightly or for domains which you are not the authority owner (in which case please try fixing the certificate problem before doing this).
Allow access to website sending bad certificates
# ignore errors with certain cites (very dangerous!) acl TrustedName url_regex ^https://weserve.badcerts.example.com/ sslproxy_cert_error allow TrustedName sslproxy_cert_error deny all
Allow access to websites attempting to use certificates belonging to another domain.
# ignore certain certificate errors (very dangerous!) acl BadSite ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH sslproxy_cert_error allow BadSite sslproxy_cert_error deny all
Squid becomes responsible for handling server certificate validation errors
When an HTTP client receives the invalid origin server certificate it can use agent features to handle validation errors. For example, many browsers warn and allow the user to examine the invalid certificate and optionally ignore the error for this or even future connections.
This powerful functionality is currently not available because Squid makes the ultimate decision on whether to ignore the validation error. The HTTP client always receives a valid certificate generated by Squid and not the invalid certificate from the origin server. We are considering adding code to mimic server certificate errors when generating a fake certificate, giving back the user an option to examine and bypass the error. Quality patches or sponsorships are welcomed.