17.02.2018 21:44, ninadmnaik пишет:
> We need to communicate with a xmpp server over TLS connections. Now, we know
> that our app can open a TLS connection to Squid. But can Squid initiate a
> TLS connection to the xmpp server?
Only if it goes over HTTP/HTTPS port. With some difficults and often
require special configuration.
> Our App ----(TLS socket connection)---> Squid ----(Can this be TLS
> connection?)----> XMPP server
> If it's possible, how to go about setting up squid for this?
> Would 'ssl-bump' feature be the way to go?
May be yes, may be no. Depends from previous. And not ssl-bump. Let's
say - peek-and-splice, and most probably splice rather than bump.
> http://www.squid-cache.org/Versions/v3/3.5/cfgman/https_port.html >
> Note that these are not 'https' requests. Just plain socket connections.
Squid is not sockets proxy. It's HTTP/HTTPS/FTP proxy only.
> Please point us in the right direction.
Try to read https://wiki.squid-cache.org first.
"Note that these are not 'https' requests. Just plain socket connections."
Maybe this wasn't statement wasn't entirely correct. We are using the
'connect' method to talk to squid proxy. And squid proxy is able to connect
to the remote xmpp server. It's just that the xmpp server supports TLS
connections only and thus further communication is not possible.
From the access logs:
1518880487.658 1449 127.0.0.1 TCP_TUNNEL/200 46 CONNECT
fcm-xmpp.googleapis.com:5235 - HIER_DIRECT/2607:f8b0:4001:c0b::bc -
"Try to read https://wiki.squid-cache.org first."
Yeah, we've been doing that and will investigate further. Just wanted to know if something like this is even possible, before we dig deeper.
IM, which is uses HTTP-similar sessions bootstrap, requires special
investigation and custom configuration in case of goes via forwarding proxy.
17.02.2018 22:58, ninadmnaik пишет:
> Thanks for the quick reply Yuri.
> "Note that these are not 'https' requests. Just plain socket connections."
> Maybe this wasn't statement wasn't entirely correct. We are using the
> 'connect' method to talk to squid proxy. And squid proxy is able to connect
> to the remote xmpp server. It's just that the xmpp server supports TLS
If' we're talking about CONNECT method session initiation, it is
requires (in general) to specify additional ports on Squid, which is
permitted to use CONNECT method.
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)
> 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.
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
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
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.