On 2024-07-10 16:57, Fiehe, Christoph wrote:
I am just trying to find something that helps to narrow down the
problem. What I want to achieve is, that a client can use HTTP in the
LAN, so that Squid can cache distribution packages without making use
of SSL intercepting when repos are only accessible via HTTPS.
OK.
In that case the secure connection must start at the proxy and end on
the target server with or without any upstream proxies in betweem.
It depends on whether you trust the parent proxy:
If you trust the parent proxy, then you can use two secure connections:
1.1. child - parent (TLS; no CONNECT)
1.2. parent - origin (TLS; no CONNECT)
If you do not trust the parent proxy, then, yes, you will need a tunnel:
2.1. child - parent (CONNECT)
2.2. child - origin (TLS inside the CONNECT tunnel)
N.B. CONNECT request in 2.1 may be plain text (common) or encrypted
(rare); I am ignoring the difference between those two subcases for now.
We have the following setup:
client -> downstream proxy -> upstream proxy -> https://download.docker.com
Now let us assume the client wants to retrieve the following resource http://download.docker.com/linux/ubuntu/dists/jammy/InRelease from the upstream proxy.
The client initiates a HTTP GET request and sends it to the downstream proxy. Now, the URL gets rewritten.
OK.
It indicates to use a HTTPS connection instead in order to talk to the target server, in our case the result is https://download.docker.com/linux/ubuntu/dists/jammy/InRelease.
Yes, but HTTPS scheme does not imply that the child Squid has to use
CONNECT. There are two possible scenarios detailed above. I do not know
which of them applies to your use case.
Now comes the critical point: From my understanding – it may be
wrongof course - the downstream server now has to send a CONNECT
request to the upstream server
Yes, provided the child (downstream) proxy does not trust that parent
(upstream) proxy. That is scenario 2. Scenario 1 is different.
to advise him to establish a secure connection to the target server.
No, the CONNECT tunnel itself is just a pair of TCP connections. The
parent proxy "secures" nothing but basic TCP connectivity. It is the
child proxy that negotiates TLS (over/inside that tunnel) with the
origin server.
After creation, the downstream proxy can retrieve the resource and
send it back to the client via plain HTTP.
Yes.
I suppose, that the GnuTLS occurs because of a missing SSL handshake
between downstream proxy and download.docker.com.
At this time, I can only say that a TLS negotiation error occurs (while
child Squid is using the encryption library it probably should not be
using for this). It is not yet clear to me whether child Squid is
negotiating with the wrong hop or something goes wrong during
negotiation with the right hop.
As the next steps, I recommend switching to OpenSSL and, if that alone
does not help, sharing new errors and determining whether you want to
use scenario 1 (no CONNECT), scenario 2 (CONNECT), or either (whichever
works): Do you trust the parent Squid?
HTH,
Alex.
-----Ursprüngliche Nachricht-----
Von: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
Gesendet: Mittwoch, 10. Juli 2024 22:15
An: squid-users@xxxxxxxxxxxxxxxxxxxxx
Cc: Fiehe, Christoph <c.fiehe@xxxxxxxxxxx>
Betreff: AW: Rewriting HTTP to HTTPS for generic package proxy
On 2024-07-10 15:31, Fiehe, Christoph wrote:
The problem is that the proxy just forwards the client GET request to the upstream proxy
Why does sending a GET request to the upstream proxy represent a problem
in your use case? I cannot find anything in your prior messages on this
thread that would preclude sending a GET request to the upstream proxy.
but in that case a CONNECT is required.
Why?
Please do not interpret my response as implying that this "must send
CONNECT" requirement is wrong (or correct). At this point, I am just
trying to understand what problem(s) you are trying to solve beyond the
one you have originally described.
Thank you,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
