[squid-users] HTTPS proxy setup questions
subhish.pillai at broadcom.com
Wed Dec 12 23:50:55 UTC 2018
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
## 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')
On Wed, Dec 12, 2018 at 3:49 PM Alex Rousskov <
rousskov at measurement-factory.com> 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
> > 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
> > 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.
> squid-users mailing list
> squid-users at lists.squid-cache.org
R&D Software Quality Engineer
Broadcom | Brocade Storage Networking
T (720) 462-2900
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the squid-users