Thanks Alex, that was very helpful.
Based on your explanation, I just want to use squid as a blind TCP tunnel carrying the HTTPS connection from client to app server.
In that case, I don't need to use ssl_bump feature and the ssl_crtd program for certificate management, is that correct?
Would this config file work to setup the TCP tunnel --
acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
# Deny requests to certain unsafe ports
http_access deny !Safe_ports
# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports
# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager
http_access allow localnet
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
# Squid normally listens to port 3128
http_port 3128
dns_v4_first on
## Allow server side certificate errors such as untrusted certificates, otherwise the connection is closed for such errors
sslproxy_cert_error allow all
## Accept certificates that fail verification (should only be needed if using 'sslproxy_cert_error allow all')
sslproxy_flags DONT_VERIFY_PEER
On Wed, Dec 12, 2018 at 3:49 PM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On 12/12/18 12:58 PM, subhish.pillai wrote:
> 1. What is the difference between SSL bumping and SSL interception?
These concepts describe activities at different layers:
* SSL bumping is, in Squid context, inspection of SSL traffic that often
also involves impersonating the origin server and decrypting encrypted
HTTP traffic (i.e. a MitM attack on the client-server HTTPS communication).
* SSL interception is, in this context, directing (TCP/IP traffic that
presumably carries) SSL traffic off its "natural" TCP/IP path so that it
gets to Squid. Interception itself works at protocol layers below SSL
and HTTP. What happens when the SSL traffic gets to Squid is outside
"SSL interception" scope.
Usually, folks intercept SSL traffic to bump it, but YMMV. It is
possible, for example, to simply log TCP-level information about the
intercepted traffic without any MitM attacks on SSL.
> 2. What is the difference between "http_port 3128 intercept" and "http_port
> 3128 transparent"? Do i need to setup the http_port as either of these?
The difference is in whether Squid impersonates the IP client, but you
need neither because your "clients are explicitly configured to connect
through the proxy server". You do not need to divert traffic from its
natural TCP/IP path to proxy it because that natural TCP/IP path already
goes through your proxy.
> 3. Do I need to create self-signed certs on the proxy server and distribute
> it to the client and application server?
* Yes if you want to inspect encrypted HTTP traffic of your client
application (i.e. get to the HTTP stuff inside the SSL layer).
* Yes if you want client to be able to read Squid-generated error pages.
* No otherwise. In this case, Squid will be just a blind TCP tunnel.
What do you want to use Squid for? The answer to that question has a
significant effect on your Squid configuration.
> # And finally deny all other access to this proxy
> http_access allow all
FWIW, your rule does not match the comment and creates an open proxy.
Both are bad.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
Subhish Pillai
R&D Software Quality Engineer
Broadcom | Brocade Storage Networking
T (720) 462-2900
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
