Re: [squid-users] squid as transparent ssl proxy

On 25/02/2012 4:25 a.m., Jan Fischbach wrote:
> Hi Everyone,
>
> I compiled an configured squid in the way to get a transparent ssl
> proxy. With the debug flag an looking into the access.log, no errors
> or warnings are shown. When intercepting http traffic, everything
> works fine but there is trouble with ssl.

First of all. Lets be clear that "transparent" is just a modifier word,
it means different things depending on how its used in a sentence:

  * in "transparent HTTP" means the proxy is not altering anything
during the relay.
    - CONNECT tunnel *is* transparent in HTTP, the proxy cannot access
or change anything inside the encrypted tunnel.

  * in "transparent proxy" (TCP layer) it means the proxy is not visible
from client *and* server end.
     - NAT (REDIRECT) is not transparent. The server is fully aware of
the proxies presence.

  * in "transparent intercept" it means the client is not aware of the
interception being done.
   - NAT (REDIRECT) is one form of transparent intercept.

There are other phrases using the word, but those are the three related
to your config which are getting confused.

TLS/SSL was designed from the ground up to make transparent interception
not work. It ensures the either the client or the server is always able
to detect the interception. This is still true, even with ssl-bump. The
loophole ssl-bump uses is that many users ignore the warnings, and
client agents/browser can be configured to trust the proxy when it is
detected.

So you can see there is no way to do "Translarent SSL Proxy". What you
are aiming for is SSL interception proxy. A bit pedantic maybe, but we
have to pay attention to that level of detail to make sense of what the
config can/cant do.

> On the Client (ipad) - safari tells me that it cant establish a safe
> connection - nothing more. the acces.logs shows:
>
> ext/html
> 1330094808.367 3 172.20.0.113 NONE/400 3563
> %BF%18%C6%CC%D5%CB%B5+%C5Eq - NONE/- text/html

Squid is agreeing with Safari. A connection was received from
172.20.0.113. Requesting "%BF%18%C6%CC%D5%CB%B5+%C5Eq". No server was
contacted, and 3563 bytes forming an HTTP 400 error page were returned.

This is binary data arriving in a plain-HTTP port. We shall get to that
below.

>
> here is my config and stuff:
>
> ip_forward =1
>
>
> Chain PREROUTING (policy ACCEPT)
> target prot opt source destination
> REDIRECT tcp -- anywhere anywhere tcp
> dpt:www redir ports 3128
> REDIRECT tcp -- anywhere anywhere tcp
> dpt:https redir ports 3129

Okay.

> and here the squid.conf

>
> acl SSL method CONNECT
> ssl_bump allow all

Okay, anything which is eligible for bumping / decrypt is done so.
You will want to restrict that to your LAN ranges, but fine for testing.

>
> ## allow users to webistes attemping to use certs belonging to other domains
> acl BadSite ssl_error SQUID_X509_V_ERR_DOMAIN_MISMATCH
> sslproxy_cert_error allow BadSite
> sslproxy_cert_error deny all

If you really want to allow for example; google.com to emit certificates
for yahoo.com and be accepted silently.
Use with care. You have just taken full responsibility for any problems
caused by the above example for *all* websites in existence, and there
are a lot of really malicious phishing sites out there who would jump at
this opportunity to spoof the SSL certificates as well as the phished
site content.

SOLUTION: You should be able to add an ACL to the conditions limiting
what domains *you*, the proxy admin, trust enough to ignore errors from.

>
> # Squid Transparent http listens to port 3128
> http_port 172.20.0.79:3128 intercept
>
> http_port 127.0.0.1:3128 intercept
Comment is incorrect. One of these port receives "intercepted HTTP (port
80) traffic".

Which one depends on the order of interface naming/IDs or some other
magic in the kernel. Redirect change ste local IP, sending packets to
the "primary IP" of the box, (whatever that mens on yoru box). This is
only a problem with REDIRECT, you can use DNAT instead to specify which
IP:port Squid is listening on and drop one of these listeners.

Additional security note:
   port 3128 is a well-known port for proxies to be listening on. There
are some nasties out there which take advantage of that to cause DoS
conditions for intercept proxies. You should make the interception
listening port(s) a random number known only to you, the firewall, and
squid config and add the mangle table rule to prevent any external
packets reaching it without NAT.
   see
http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect for
the iptables rules about that.

> # Squid Transparent SSL https listens to por 3129
> http_port 172.20.0.79:3129 intercept ssl-bump
> cert=/etc/apache2/ssl/server.crt key=/etc/apache2/ssl/server.key
>
> http_port 127.0.0.1:3129 intercept ssl-bump
> generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> options=ALL cert=/etc/apache2/ssl/apache.pem

Neither of these ports accepts HTTPS traffic. They are both http_port
(HTTP port 80 traffic format). This is the problem you can see with
Safari and the Squid log.
  * The SSL being redirected here cannot be decrypted by an http_port.
Resulting in that binary "request" details being logged by Squid.
  * Squid rejects the binary with a plain-text HTTP error. Resulting in
Safari having problems interpreting the SSL bytes it was expecting.

What you need to receive intercepted HTTPS (port 443) is https_port.

Amos
Received on Sat Feb 25 2012 - 00:30:37 MST