Re: [squid-users] Fwd: Fwd: SSLBUMP Issue with SSL websites

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
Received on Sun Mar 11 2012 - 22:49:48 MDT