cannot access squid with https_port: 403

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

cannot access squid with https_port: 403

fansari
I have to setup a TLS proxy connection between client and squid. My config is
working with http_port (without TLS) but as soon as I try https_port it does
not work (squid 3.5.23 compiled with --enable-ssl' '--enable-ssl-crtd'
'--with-openssl').

What I am trying to achieve is a proxy for https content. When I access the
squid I always get a 403 error code (I am testing with curl).

curl --proxy ${PROXY} --cacert ${CERT} --proxy-insecure --insecure ${URL}

1567498682.392     3 xxx.xxx.0.239 TCP_DENIED/200 0 CONNECT xxx.xxx.0.1:3129
- HIER_NONE/- -
1567498682.498     1 xxx.xxx.0.239 TAG_NONE/403 3825 CONNECT mydomain:443 -
HIER_NONE/- text/html

Here my squid.conf. What am I doing wrong?

acl wifi_net src xxx.xxx.0.0/24
acl our_proxy localip xxx.xxx.0.1/32
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
acl step1 at_step SslBump1
acl bumpedPorts myportname 3129
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
http_access deny to_localhost
http_access allow localhost
http_access allow wifi_net
http_access allow CONNECT bumpedPorts
http_access allow CONNECT our_proxy
http_access deny all
http_port 3128 ssl-bump \
  cert=/etc/squid/certs/squid-ca-cert-key.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
https_port 3129 intercept ssl-bump \
  cert=/etc/squid/certs/squid-ca-cert-key.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
ssl_bump peek step1
ssl_bump bump all
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
cache_dir ufs /var/spool/squid 1024 16 256
debug_options ALL,2
coredump_dir /var/spool/squid
refresh_pattern .               30      20%     1440 override-expire




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

Amos Jeffries
Administrator
On 3/09/19 8:46 pm, fansari wrote:

> I have to setup a TLS proxy connection between client and squid. My config is
> working with http_port (without TLS) but as soon as I try https_port it does
> not work (squid 3.5.23 compiled with --enable-ssl' '--enable-ssl-crtd'
> '--with-openssl').
>
> What I am trying to achieve is a proxy for https content. When I access the
> squid I always get a 403 error code (I am testing with curl).
>
> curl --proxy ${PROXY} --cacert ${CERT} --proxy-insecure --insecure ${URL}
>
> 1567498682.392     3 xxx.xxx.0.239 TCP_DENIED/200 0 CONNECT xxx.xxx.0.1:3129
> - HIER_NONE/- -


You have either opened a TCP connection directly to the "intercept" port
or told Squid to do so on a CONNECT transaction to port 3128.

Only NAT systems can send traffic to an intercept port. That's what the
intercept means.

You must test the proxy with traffic a client would actually send. In
the same way the clients would normally use it.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

fansari
Thank you for your reply.

If I drop the keyword "intercept" I get this error message when starting
squid:

FATAL: ssl-bump on https_port requires tproxy/intercept which is missing.

Using "tproxy" does not help me either - I also end up with 403.

What I want to achieve with my scenario is just caching of https content.

The scenario consists of one central system (the "server") and then the
"clients".

For the interface used I work with private IPv4 addresses.

On the server there is IP masquerading for NAT - but it seems that the
traffic even gets stuck before it is sent out.

I tested with tcpdump on the outgoing interface and checked the logs of my
webserver (which I used for a test) and both tests show that the connection
is not going out to my webserver but gets stuck on the squid.

Is "intercept" the correct way when I want to cache https content?

Regarding the clients of the real scenario: this will be a Chromium
application so I could setup a .pac file for example. But before testing
this I want to have a successful curl test.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

Amos Jeffries
Administrator
On 4/09/19 12:29 am, fansari wrote:

> Thank you for your reply.
>
> If I drop the keyword "intercept" I get this error message when starting
> squid:
>
> FATAL: ssl-bump on https_port requires tproxy/intercept which is missing.
>
> Using "tproxy" does not help me either - I also end up with 403.
>
> What I want to achieve with my scenario is just caching of https content.

What you have configured is *a* valid configuration for that to happen.

Your test is what is wrong _for that port_.


>
> Regarding the clients of the real scenario: this will be a Chromium
> application so I could setup a .pac file for example. But before testing
> this I want to have a successful curl test.
>

Aha. This was the critical missing information.

That means the http_port and ssl_bump lines are what you actually need
to be using.

Remove that https_port line entirely.

Also, remove these lines:
"
 acl bumpedPorts myportname 3129

 http_access allow CONNECT bumpedPorts
 http_access allow CONNECT our_proxy
"

Instead you should have your normal http_access rule(s) for determining
which clients are allowed to use the proxy. If they are allowed to use
the proxy they are allowed to do CONNECT already for the https:// traffic.

Test it like this:
  curl --proxy 192.168.0.1:3128 --cacert ${CERT} https://example.com/


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

fansari
I have tested this and it is working.

This is what I said: when I use this http_port directive then it works.

So what is still unclear to me is: what is this https_port directive for? I
understood from one of you answers I found to someone else that this will
lead to something like double stacked TLS encryption. Is this correct?

http://squid-web-proxy-cache.1019090.n4.nabble.com/https-port-td4682718.html

The most important question is: using just the http_port directive - will
the connection between client and squid still be https (TLS  encrypted)?
This is important to understand for me because we need https because our
nodejs application will not work with http connections.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

Amos Jeffries
Administrator
On 4/09/19 1:21 am, fansari wrote:
> I have tested this and it is working.
>
> This is what I said: when I use this http_port directive then it works.
>
> So what is still unclear to me is: what is this https_port directive for? I
> understood from one of you answers I found to someone else that this will
> lead to something like double stacked TLS encryption. Is this correct?

It is for;
 a) receiving port 443 traffic from a NAT system,
or
 b) receiving TLS explicit proxy traffic.


>
> http://squid-web-proxy-cache.1019090.n4.nabble.com/https-port-td4682718.html
>
> The most important question is: using just the http_port directive - will
> the connection between client and squid still be https (TLS  encrypted)?

The answer you are looking for is both Yes and No.

Traffic to that port must always start with an un-encrypted request. In
the case of HTTP it starts with an unencrypted CONNECT request. The TLS
is embedded within the resulting tunnel.

The traffic which was going to be encrypted stays encrypted. But there
is a non-encrypted portion ahead of it at the transport protocol level.


> This is important to understand for me because we need https because our
> nodejs application will not work with http connections.
>

If it can rely on a Browser to do the CONNECT tunnel part, then it
should be fine.

Otherwise, if it does everything above TCP itself and can only start
with the TLS handshake. Then you are going to need to use one of the
https_port setups.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

fansari
OK - I cannot figure out the whole requirement right now.

In case it will not not work like this: with a) you mean "intercept" and
with b) "tproxy"?

Which of these scenarios would you recommend in case http_port will not do
for us?




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

fansari
In reply to this post by Amos Jeffries
Seems that intercept is easier than tproxy.

I have now this config:

acl wifi_net src  xxx.xxx.0.0/24
acl our_proxy localip  xxx.xxx.0.1/32
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
acl step1 at_step SslBump1
acl bumpedPorts myportname 3129
http_access deny !Safe_ports
http_access allow localhost manager
http_access deny manager
http_access deny to_localhost
http_access allow localhost
http_access allow wifi_net
http_access allow CONNECT bumpedPorts
http_access allow CONNECT our_proxy
http_access allow CONNECT wifi_net
http_access deny all
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump \
  cert=/etc/squid/certs/squid-ca-cert-key.pem \
  generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
ssl_bump peek step1
ssl_bump bump all
ssl_bump server-first
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
cache_dir ufs /var/spool/squid 1024 16 256
debug_options ALL,2
coredump_dir /var/spool/squid
refresh_pattern .               30      20%     1440 override-expire

When I add these rules on the server in /etc/firewalld/direct.xml

<rule ipv="ipv4" table="nat" chain="PREROUTING" priority="0">-i wlan1 -p tcp
-s xxx.xxx.0.0/24 --dport 80 -j DNAT --to xxx.xxx.0.1:3128</rule>
<rule ipv="ipv4" table="nat" chain="PREROUTING" priority="0">-i wlan1 -p tcp
-s xxx.xxx.0.0/24 --dport 443 -j DNAT --to xxx.xxx.0.1:3129</rule>

then I receive the content and also see a TCP_MEM_MISS or TCP_MEM_HIT in the
access.log.

So maybe this could be a scenario to use in case http_port does not work.

From this server itself the squid seems not to be used - but this is
probably more routing than squid stuff.




--
Sent from: http://squid-web-proxy-cache.1019090.n4.nabble.com/Squid-Users-f1019091.html
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

Matus UHLAR - fantomas
On 03.09.19 11:44, fansari wrote:
>Seems that intercept is easier than tproxy.

FYI, tproxy means incercept AND changing outgoing IP address to the IP
address of the original client.

yes, intercept alone is easier, because tproxy means implementing
intercepting and something in addition.

nowadays when most of clients are behing NAT firewall, tproxy may not be so
important, since the source IP will often get translated to the same ip on
the gateway, no matter which IP (proxy or client) goes through it.

--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: cannot access squid with https_port: 403

Amos Jeffries
Administrator
In reply to this post by fansari
On 4/09/19 2:59 am, fansari wrote:
> OK - I cannot figure out the whole requirement right now.
>
> In case it will not not work like this: with a) you mean "intercept" and
> with b) "tproxy"?
>

No for (b) I mean "TLS explicit". New connections from clients start
with TLS handshake immediately, no CONNECT message or HTTP layering
going on. Just a client talking to a proxy - explicitly over TLS instead
of TCP.



> Which of these scenarios would you recommend in case http_port will not do
> for us?
>

I cannot answer that without details of the client application and how
it performs connection setup. You seem reluctant to go into detail over
that, so I mentioned all the options.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users