[squid-users] Forward proxy: TLS connections to server

[Amos Jeffries]

On 21/02/18 18:38, ninadmnaik wrote:
> Does the "https_port intercept ssl-bump" work only in transparent proxy
> scenarios, where the DNAT changes have been applied?
> https://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat

The "intercept" mode flag alone is what means DNAT is taking place and
has to be deciphered by Squid;

 - the NAT may have other names but is still "Destination NAT".

 - the particular *_port line and ssl-bump are unrelated to the NAT.


> 
> Or is it possible to explicitly point to squid proxy in the client and still
> use the "https_port intercept ssl_bump"?

No. Explicit proxy is a completely traffic syntax (aka "mode").

Specifically the "explicit proxy" mode signaled by absence of a mode flag.

SSL-Bump makes no sense on an explicit-proxy https_port. Since ssl-bump
is an MITM hijack on the client traffic and by definition the TLS
(explicit) directed by the client itself to an explicit-proxy https_port
is intended explicitly for that proxy instead of any other server / origin.


> 
> Here's the setup we've so far:
> 
> Squid 3.5.27
> 
> Conf file:
> acl localnet src 127.0.0.1/32
> acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
> acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
> acl localnet src fc00::/7       # RFC 4193 local private network range
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged)
> machines
> 
> acl SSL_ports port 5235         # xmpp over ssl
> acl SSL_ports port 3130
> acl SSL_ports port 443
> acl Safe_ports port 80          # http
> acl CONNECT method CONNECT
> 
> acl ssl-bump_port myportname 3130
> always_direct allow ssl-bump_port        # always direct to origin server.
> Do not get from cache.
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> 
> http_access allow all
> 
> http_port 3128

Proxy listening on port 3128 for explicit-proxy traffic.

> https_port 3130 intercept ssl-bump generate-host-certificates=on

Proxy listening on port 3130 for NAT intercepted port 443 (HTTPS) traffic.


> dynamic_cert_mem_cache_size=4MB cert=/pem.certificate/cert.pem
> key=/pem.certificate/key.pem cafile=/etc/ssl/cert.pem
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ssl_bump peek step1
> ssl_bump bump step2
> 
> sslproxy_cert_error allow all
> sslproxy_flags DONT_VERIFY_PEER

Proxy admin disabling all security measures offered by TLS. Free pass to
anyone abusing the network through port 443, no logging performed when
attacks happen.


Please remove the above lines and fix the problems that show up via
means other than silencing the log records.


> sslcrtd_program /usr/local/squid/libexec/ssl_crtd  -s
> /usr/local/squid/ssl_db -M 4MB
> 
> 
> And here's what the client is trying to do:
> 
> 1. sslSocket.connect("localhost", 3130);

Immediate Fail. Only the NAT system may send traffic to that port.
You should have firewall rules enforcing that restriction.

Also, the traffic must have been going directly to an origin server
before the NAT system altered it. ie traffic uses bare TLS containing
HTTP origin-form syntax.


> 
> 2. sslSocket.getOutputStream.write("CONNECT fcm-xmpp.googleapis.com:5235
> HTTP/1.1 Host: CONNECT fcm-xmpp.googleapis.com:5235");


If it is doing things right that client is doing:

 0) opening a TCP connection to the proxy, and

 1) inside that TCP connection (0) negotiating TLS to the proxy, and

 2) over that (1) it is sending an HTTP message. The explicit-proxy
request to setup an blind tunnel to some server on port 5235 . And,

 3) over that (2) it is going to send TLS to an origin server, and

 4) over that (3) it is going to send HTTP messages (aka HTTPS).


So to receive the traffic Squid requires:

A) an "https_port ..." to receive the TCP at (0) and explicit TLS at
(1), and

B) the "ssl-bump" option to decrypt the traffic at (4).


That is all. The TCP at (0) is the same, and HTTP at (2) is already in
explicit-proxy syntax, so no "intercept" necessary. SSL-Bump sets up
Squid to handle the (4) messages properly whatever the outcome of the
bumping attempt.

There is a special case when the traffic is NAT intercepted on it sway
to a different explicit=-proxy. In that case the dst-IP is not the
origin servers and the other things "intercept" causes to happen are
wrong - so do not use "intercept", just ignore the NAT.


NOTE: HTTP traffic sent by a client intentionally to a proxy (eg the
CONNECT) is often described as "plain-text HTTP". But as you can see
that is an oversimplification - the existence of (1) above shows how
inaccurate that word "plain-text" can be.
 This is why the terms "explicit-proxy" or "forward-proxy" are used. The
traffic may take the form of plain-text on TCP, or encrypted on TLS, and
literally any other reliable transport protocol. Subject only to what
the proxy software is written to receive.



> 
> However, squid receives number 1 as a CONNECT. Same when I do: 'telnet
> localhost 3130'. 

Which is different layering to the above. Telnet only does the (0) and
(2) TCP and HTTP layering. No (1) encryption step at all.

 - The "http_port" (no 's') directive is for traffic layering where
(1)'s TLS does not exist.



Amos