Re: [squid-users] Does Squid support client ssl termination?
On Wed, Nov 2, 2022 at 6:17 AM wrote: > On 2022-11-02 07:49, Grant Taylor wrote: > > On 11/1/22 11:33 AM, squid3 wrote: > >> That is not true as a blanket statement. > > > > Please clarify which statement / who you are addressing. > > > > It seems as if you're addressing mingheng (copied below for > > convenience): > > > > Yes I was addressing mingheng's statement. > > > > On 10/31/22 7:32 PM, mingheng wang wrote: > >> I delved into the configuration the last few days, and found that > >> Squid doesn't officially support cache_peer when ssl_bump is in use. > > > > But you may be addressing my statement (...): > > > > On 11/1/22 10:44 AM, Grant Taylor wrote: > >> That surprises me. I wonder if it's a technical limitation or an > >> oversight. > > > > > > On 11/1/22 11:33 AM, squ...@treenet.co.nz wrote: > >> What Squid officially *does not* support is decrypting traffic then > >> sending the un-encrypted form to a HTTP-only cache_peer. > Oh sorry, I was meant to say that. I tested setting a sslstrip proxy as cache_peer when ssl_bump was in use, and it didn't work. I was too focused on my setup and forgot the case of regular proxies. > > > > Please elaborate. I'm trying to develop a mental model of what is and > > is not supported with regard to client / proxy / server communications. > > I'm unclear on how this applies to the two potential HTTPS streams; > > client-to-proxy and proxy-to-server. > > Okay, some info that may help with that mental model... > > The first thing you need to do is avoid that "HTTPS" term. It has > multiple meanings and they cause confusion. Instead decompose it into > its TLS and HTTP layers. > > * A client can use TCP or TLS to connect to a proxy. > - this is configured with http_port vs https_port > > * Independently of the connection type the client can request http:// or > https:// URLs or CONNECT tunnels. > > * Independent of what the client is doing/requesting, a cache_peer may > be connected to using TCP or TLS. > - this is configured with cache_peer tls options (or their absence) > > * Independent of anything else, a cache_peer MAY be asked to open a > CONNECT tunnel for opaque uses. > - this is automatically decided by Squid based on various criteria. > > > TCP is the foundation layer. On top of that can be HTTP transfer or TLS > transfer. Transfer layers can be nested infinitely deep in any order. > > So "HTTPS" can mean any one of things like: > 1) HTTP-over-TLS (how Browsers handle https:// URLs) > 2) HTTP-over-TLS (sending http:// URLs over a secure connection) > 3) HTTP-over-TLS-over-TLS (relay (1) through a secure cache_peer) > 4) HTTP-over-TLS-over-HTTP (relay (1), (2) or (3) through an insecure > cache_peer via CONNECT tunnel) > > Each agent along the chain can add or remove any number of transfer > layers to the protocol X-over-Y stack. Although for efficiency most > prefer to minimize the layering depth. > > A typical web request may flow across the Internet through a chain of > proxies like this: > > client -(1)-> S1 =(4)=> S2 =(1)=> S3 -(2)-> O > > C = origin client > S1 = forward-proxy > S2 = insecure relay proxy > S3 = TLS terminating reverse-proxy > O = origin server > > > > Or if this is more applicable to TLS-Bump on implicit / network > > transparent / intercepting proxies where the client thinks that it's > > talking HTTPS to the origin server and the proxy would really be > > downgrading security by stripping TLS. > > > > It's *more* important with SSL-Bump 'bump' due to the interception > nature of that operation. But also applies to other cases. > > SSL-Bump implies interception of TLS > * intercept may happen at network level (port 443 redirect or NAT) > * intercept may be entirely within Squid (CONNECT tunnel unwrapped) > > Decryption is independent of interception. > a) SSL-Bump 'bump' action performs decrypt (the others do not) > b) a TLS forward/explicit-proxy performs decrypt > c) a TLS reverse-proxy performs decrypt > > Traffic from (a) case requires re-encrypt before sending, even if its > URL indicates insecure protocols. > I don't understand. According to the wiki on Squid that I read, there are several steps involving "peek", "bump" or "slice" etc, we can already choose to bump or slice through SNI at step2. So why does HTTP have to be encrypted too? Anyway, essentially what I need is like splitting Squid into two parts: the client side part communicate with a client over a connection with dynamically generated ce
Re: [squid-users] Does Squid support client ssl termination?
On Mon, Oct 31, 2022, 11:46 PM Grant Taylor wrote: > Hi, > > Pre-script: Did you mean to reply directly to me? Or did you intend > for your reply to go to the squid-users mailing list? > > Sorry about that, don't know why it only went to you. > On 10/27/22 6:47 PM, mingheng wang wrote: > > In my experience, many clients, such as Firefox and Chrome, favor > > HTTPS over HTTP, and some clients even enforce HTTPS. They down right > > send HTTPS CONNECT to 443. > > I think that is a relatively recent change in preference. > > > Does this mean Squid does support this: > > Client --[HTTPS on self-signed certs]-->Squid--[HTTP]--> site (suppose > > it doesn't redirect) > > Yes, that is entirely likely to happen. > > N.B. I'm going to trust that the self-signed vs CA-signed certs are a > non-issue and that clients have been configured to trust whatever cert > is being used, no matter who signed it. > > I delved into the configuration the last few days, and found that Squid doesn't officially support cache_peer when ssl_bump is in use. Actually, I can't find a single tool in the market that can just encrypt any HTTP connection, "converting" it to an HTTPS connection. I'm reading RFCs and documentation to write my own proxy. > > My Apache server only listens on 80, but when using Cloudflare in > > front of it, Cloudflare can add HTTPS support, signed by them, and > > web browsers say the connection is secured. So I thought Squid could > > do the same, only with self-signed certs. > > Cloudflare is functioning as a /reverse/-proxy in that case. Forward vs > reverse proxy is technically different and has different semantics. > > I believe that Squid can function as a reverse proxy. > > This is what still confuses me. A reverse proxy is supposed to proxy a web site. At least that's what I learnt from Nginx and Haproxy's documentation. I'll read more on this when I have time. > > Because I also want to avoid TLS over TLS, if I chain another HTTPS > > proxy between the local Squid and the remote Squid. Our company's > > gateway monitors traffic and forbids tunnels to prevent accessing > > systems from outside but this is also hurting my internet access. When > > using HTTPS over a SSL tunnel within our company, it may trigger the > > IT security policy. > > Okay. This local restriction may complicate things. > > Very tough network environment. They can even somehow detect a confidential file going through the gateway, even with TLS. > That would mean that unencrypted sites would never be encrypted between > the two proxies. If that's okay with you, then fine by me. > > > The downstream child Squid is running on the same localhost as with > > other programs that are going to use it. > > Okay. Thank you for clarifying. > > Aside: I see little benefit, and non-trivial complication, to do HTTPS > web browser to Squid connections to have Squid do unencrypted traffic out. > > > I mean certs signed by well known public CA, like DigiCert, Cloudflare > > etc. > > Okay. Thank you for clarifying. > > > Our company blocks HTTPS connections with self-signed certs. It says > > they're malicious. Besides, I want to reuse the public CA signed > > certs that my website uses. Sorry for not being clearer before, > > perhaps my use case is too specific. > > Re-using CA-signed certificates from a web server on a Squid proxy > server may not work as well as you hope. There's a good chance that you > will run into issues related to CN / SAN mis-match. > > If you don't have any CN / SAN mis-match issues, as in the original cert > includes the proxy's name as a SAN, you'll probably be okay. > > I can just negotiate HTTPS using a separate piece of software and send HTTP data through the tunnel. I believe the important part is the TLS negotiation. Eliminating TLS over TLS should be enough to evade our IT's DPI. They even banned git from accessing the net outside the company because they can't be sure what we are doing with git as it's simultaneously downloading and uploading. > > > -- > Grant. . . . > unix || die > > ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] Does Squid support client ssl termination?
Hello all, Since ssl_bump can generate self signed certificates on the fly, I wonder if this setup is possible, or even just in theory: clients with necessary root CA installed connect to a local Squid. With ssl_bump and self signed certs, it always talks with the clients over HTTPS, making clients believe their connections are secure; the local Squid then forwards the connections to a parent Squid server, which however, will only send data back in plain HTTP, i.e. in clear text, akin to a reverse proxy with ssl termination to its proxied site. my goals are to cache data/modify requests even when connecting to https only sites, while avoiding using self signed certs to encrypt connections over the Internet, because this way, I can chain an https proxy with trusted certs in between. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
