<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="auto"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 31, 2022, 11:46 PM Grant Taylor <<a href="mailto:gtaylor@tnetconsulting.net" target="_blank">gtaylor@tnetconsulting.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Pre-script:  Did you mean to reply directly to me?  Or did you intend <br>
for your reply to go to the squid-users mailing list?<br>
<br></blockquote><div>Sorry about that, don't know why it only went to you. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 10/27/22 6:47 PM, mingheng wang wrote:<br>
> In my experience, many clients, such as Firefox and Chrome, favor <br>
> HTTPS over HTTP, and some clients even enforce HTTPS. They down right <br>
> send HTTPS CONNECT to 443.<br>
<br>
I think that is a relatively recent change in preference.<br>
<br>
> Does this mean Squid does support this:<br>
>   Client --[HTTPS on self-signed certs]-->Squid--[HTTP]--> site (suppose <br>
> it doesn't redirect)<br>
<br>
Yes, that is entirely likely to happen.<br>
<br>
N.B. I'm going to trust that the self-signed vs CA-signed certs are a <br>
non-issue and that clients have been configured to trust whatever cert <br>
is being used, no matter who signed it.<br><br></blockquote><div>I delved into the configuration the last few days, and found that Squid doesn't officially support</div><div>cache_peer when ssl_bump is in use. Actually, I can't find a single tool in the market that</div><div>can just encrypt any HTTP connection, "converting" it to an HTTPS connection. I'm reading</div><div>RFCs and documentation to write my own proxy.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> My Apache server only listens on 80, but when using Cloudflare in <br>
> front of it, Cloudflare can add HTTPS support, signed by them, and <br>
> web browsers say the connection is secured. So I thought Squid could <br>
> do the same, only with self-signed certs.<br>
<br>
Cloudflare is functioning as a /reverse/-proxy in that case.  Forward vs <br>
reverse proxy is technically different and has different semantics.<br>
<br>
I believe that Squid can function as a reverse proxy.<br>
<br></blockquote><div>This is what still confuses me. A reverse proxy is supposed to proxy a web</div><div>site. At least that's what I learnt from Nginx and Haproxy's documentation.</div><div>I'll read more on this when I have time.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Because I also want to avoid TLS over TLS, if I chain another HTTPS <br>
> proxy between the local Squid and the remote Squid. Our company's <br>
> gateway monitors traffic and forbids tunnels to prevent accessing <br>
> systems from outside but this is also hurting my internet access. When <br>
> using HTTPS over a SSL tunnel within our company, it may trigger the <br>
> IT security policy.<br>
<br>
Okay.  This local restriction may complicate things.<br>
<br></blockquote><div>Very tough network environment. They can even somehow detect a confidential</div><div>file going through the gateway, even with TLS. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That would mean that unencrypted sites would never be encrypted between <br>
the two proxies.  If that's okay with you, then fine by me.<br>
<br>
> The downstream child Squid is running on the same localhost as with <br>
> other programs that are going to use it.<br>
<br>
Okay.  Thank you for clarifying.<br>
<br>
Aside:  I see little benefit, and non-trivial complication, to do HTTPS <br>
web browser to Squid connections to have Squid do unencrypted traffic out.<br>
<br>
> I mean certs signed by well known public CA, like DigiCert, Cloudflare <br>
> etc.<br>
<br>
Okay.  Thank you for clarifying.<br>
<br>
> Our company blocks HTTPS connections with self-signed certs. It says <br>
> they're malicious.  Besides, I want to reuse the public CA signed <br>
> certs that my website uses. Sorry for not being clearer before, <br>
> perhaps my use case is too specific. <br>
<br>
Re-using CA-signed certificates from a web server on a Squid proxy <br>
server may not work as well as you hope.  There's a good chance that you <br>
will run into issues related to CN / SAN mis-match.<br>
<br>
If you don't have any CN / SAN mis-match issues, as in the original cert <br>
includes the proxy's name as a SAN, you'll probably be okay.<br>
<br></blockquote><div>I can just negotiate HTTPS using a separate piece of software and send HTTP data</div><div>through the tunnel. I believe the important part is the TLS negotiation. </div><div>Eliminating TLS over TLS should be enough to evade our IT's DPI. They even banned</div><div>git from accessing the net outside the company because they can't be sure what we</div><div>are doing with git as it's simultaneously downloading and uploading.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
-- <br>
Grant. . . .<br>
unix || die<br>
<br>
</blockquote></div></div>
</div></div>