Re: [squid-users] Forward proxy: TLS connections to server
Great. Thanks for such a thorough explanation Amos ! Cleared a lot of doubts. -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Forward proxy: TLS connections to server
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 rec
Re: [squid-users] Forward proxy: TLS connections to server
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
Or is it possible to explicitly point to squid proxy in the client and still
use the "https_port intercept ssl_bump"?
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
https_port 3130 intercept ssl-bump generate-host-certificates=on
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
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);
2. sslSocket.getOutputStream.write("CONNECT fcm-xmpp.googleapis.com:5235
HTTP/1.1 Host: CONNECT fcm-xmpp.googleapis.com:5235");
However, squid receives number 1 as a CONNECT. Same when I do: 'telnet
localhost 3130'.
Should the first connect be received with method 'CONNECT'.
Logs:
2018/02/20 23:14:28.050 kid1| 5,2| TcpAcceptor.cc(220) doAccept: New
connection on FD 29
2018/02/20 23:14:28.050 kid1| 5,2| TcpAcceptor.cc(295) acceptNext:
connection on local=[::]:3130 remote=[::] FD 29 flags=41
2018/02/20 23:14:28.050 kid1| 33,2| client_side.cc(3943)
httpsSslBumpAccessCheckDone: sslBump needed for local=127.0.0.1:3130
remote=127.0.0.1:50607 FD 16 flags=33 method 3
2018/02/20 23:14:28.050 kid1| 11,2| client_side.cc(2372) parseHttpRequest:
HTTP Client local=127.0.0.1:3130 remote=127.0.0.1:50607 FD 16 flags=33
2018/02/20 23:14:28.050 kid1| 11,2| client_side.cc(2373) parseHttpRequest:
HTTP Client REQUEST:
-
CONNECT 127.0.0.1:3130 HTTP/1.1
Host: 127.0.0.1:3130
--
2018/02/20 23:14:28.051 kid1| 85,2| client_side_request.cc(745)
clientAccessCheckDone: The request CONNECT 127.0.0.1:3130 is ALLOWED; last
ACL checked: all
2018/02/20 23:14:28.051 kid1| 85,2| client_side_request.cc(721)
clientAccessCheck2: No adapted_http_access configuration. default: ALLOW
2018/02/20 23:14:28.051 kid1| 85,2| client_side_request.cc(745)
clientAccessCheckDone: The request CONNECT 127.0.0.1:3130 is ALLOWED; last
ACL checked: all
2018/02/20 23:14:28.095 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.096 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.097 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.097 kid1| 83,2| client_side.cc(4316)
clientPeekAndSpliceSSL: SSL_accept failed.
2018/02/20 23:14:28.097 kid1| 83,2| client_side.cc(4316)
clientPeek
Re: [squid-users] Forward proxy: TLS connections to server
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. For example, in your case, port 1449. Generally speaking, squid's default not assumes IM as clients, as by as squid itself is not proxy for all and any protocols. So, it is requires additional configuration for passing IM via proxy. > 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. Indeed :) > > > > -- > Sent from: > http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -- * * C++20 : Bug to the future * * signature.asc Description: OpenPGP digital signature ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Forward proxy: TLS connections to server
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 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. -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
Re: [squid-users] Forward proxy: TLS connections to server
17.02.2018 21:44, ninadmnaik пишет: > Hello, > 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. > Thanks. > > > > -- > Sent from: > http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html > ___ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users -- * * C++20 : Bug to the future * * signature.asc Description: OpenPGP digital signature ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Forward proxy: TLS connections to server
Hello, 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? 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? http://www.squid-cache.org/Versions/v3/3.5/cfgman/https_port.html Note that these are not 'https' requests. Just plain socket connections. Please point us in the right direction. Thanks. -- Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
