On 12.03.2012 06:16, Amit Pasari-Xsinfoways wrote:
Dear All,
I have configured SSLBUMP in squid3.1 , in transparent mode for port
80 and 443 .
There is no support for transparent SSL proxy in Squid-3.1.
There is support for Man-In-The-Middle (interception) of CONNECT
request tunnels. With some rough and nasty ability to grab port-443
traffic at expense of a great many SSL alert popups on to the users
browser.
Both the web server and browser are fully aware of what is going on.
Even the user is painfully aware due to those popups several times per
page loading. "transparent" it is not.
My problem is when i open website like mail.yahoo.com or
gmail.com
it doesnt show me images , or when i open https://facebook.com
everything comes inline , no css nothing .
Where as when i configure my browser to use squid everything seems to
be ok
My Details :
OS : Centos 4.8
Squid : squid3-3.1.8-1.el4
Squid 3.1.8 does not support ssl-bump. You need a minimum of 3.1.13 for
that to work properly. For interception on port 443 you need the 3.2
series with dynamic certificate generation to create fake certificates
on demand and reduce the popups.
<snip>
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP
networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access allow newclient
http_access allow newclient1
http_access allow publicip
http_access deny all
# Squid normally listens to port 3128
# http_port 3128
# Amit Start
always_direct allow all
ssl_bump allow all
sslproxy_cert_error allow all
http_port 3128 intercept ssl-bump cert=/etc/squid/server.crt
key=/etc/squid/server.Key
#the below should be placed on a single line
https_port 3129 intercept ssl-bump cert=/etc/squid/server.crt
key=/etc/squid/server.Key allow-direct options=NO_SSLv2
ssl-bump is a http_port option to kick off decryption.
https_port is decrypting SSL traffic on arrival using the certificate
given.
Intercepting SSL in 3.1 can only be done with the browser receiving
fake certificates which they often complain about. It is very likely
that the browser is setup to not report (via those annoying SSL popups)
when it is having issues.
sslproxy_flags DONT_VERIFY_PEER
This allows any network your traffic flows over to perform SSL
decryption and replacement of certificates in your clients traffic.
Squid will not even check for bad certificates, let alone produce
warnings about external people listening in on the traffic.
I hope I don't need to explain how risky that is.
I recommend not even using it for testing ssl-bump. You *want* the
problems to show up so they can be identified and resolved quickly,
particularly in testing.
# Amit end
# We recommend you to use at least the following line.
hierarchy_stoplist cgi-bin ? xsinfoways.com
This prevents cache_peer links being used for any URL which matches the
pattern. You don't seem to have any cache_peer, so this is useless.
cache_mem 96 MB
cache_dir ufs /var/spool/squid 2000 16 256
request_body_max_size 0 KB
# Uncomment and adjust the following to add a disk cache directory.
#cache_dir ufs /var/cache/squid 100 16 256
# Leave coredumps in the first cache dir
coredump_dir /var/cache/squid
# Add any of your own refresh_pattern entries above these.
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
cache_effective_user squid
cache_effective_group squid
Some Errors in cache.log :
2012/03/10 17:41:44| clientNegotiateSSL: Error negotiating SSL
connection on FD 47: error:140760FC:SSL
SSL decryption is failing to decrypt some traffic which is not SSL
encrypted.
Take your pick:
- CONNECT being used for a protocol other than HTTPS.
- port 443 being used for a protocol without TLS or SSL encryption.
routines:SSL23_GET_CLIENT_HELLO:unknown protocol (1/-1)
2012/03/10 17:41:44| clientNegotiateSSL: Error negotiating SSL
connection on FD 47: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol (1/-1)
2012/03/10 17:44:04| clientNegotiateSSL: Error negotiating SSL
connection on FD 127: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol (1/-1)
2012/03/10 17:44:04| clientNegotiateSSL: Error negotiating SSL
connection on FD 128: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol (1/-1)
2012/03/10 17:44:04| clientNegotiateSSL: Error negotiating SSL
connection on FD 127: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol (1/-1)
2012/03/10 17:44:51| clientNegotiateSSL: Error negotiating SSL
connection on FD 21: error:14094418:SSL
routines:SSL3_READ_BYTES:tlsv1
alert unknown ca (1/0)
Something strange may be going on here with this alert. Squid is
_receiving_ an unknown CA certificate while negotiating with the client.
It would appear that your trusted certificates list used by OpenSSL is
outdated. Or possibly that the client is using a specially client
certificate for stronger security (which you are promptly erasing by
using ssl-bump MITM).
Amos
