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
