<html><body>
<p><font size="2" face="sans-serif">Amos,</font><br>
<br>
<font size="2" face="sans-serif">Per:</font><br>
<tt><font size="2">There *is* a Right Way.<br>
<br>
It is this:<br>
<br>
1) using this in squid.conf:<br>
     https_port 3129 cert=/path/to/proxy.pem<br>
<br>
2) client connects to 3129 using TCP, then performs TLS handshake.<br>
<br>
3) client sends requests inside the encrypted connection as if they were<br>
HTTP to a proxy but using https:// URL scheme.</font></tt><br>
<br>
<font size="2" face="sans-serif"><br>
If my client (it's not a browser) is an https client ultimately attempting to send its payload to a reverse proxy listening on 443, does this mean</font><br>
<font size="2" face="sans-serif">that I will have an encrypted payload inside of another encrypted payload? Also, if I configure my client to send traffic to Squid at port 3129,</font><br>
<font size="2" face="sans-serif">then doesn't this mean I'm using Squid explicitly and not transparently?</font><br>
<br>
<br>
<img width="16" height="16" src="cid:1__=08BBF76FDFD097CD8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Amos Jeffries ---03/01/2015 08:39:01 PM---On 2/03/2015 9:55 a.m., Eliezer Croitoru wrote: > Hey Yuri,"><font size="2" color="#424282" face="sans-serif">Amos Jeffries ---03/01/2015 08:39:01 PM---On 2/03/2015 9:55 a.m., Eliezer Croitoru wrote: > Hey Yuri,</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From:      </font><font size="1" face="sans-serif">Amos Jeffries <squid3@treenet.co.nz></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To:        </font><font size="1" face="sans-serif">squid-users@lists.squid-cache.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date:      </font><font size="1" face="sans-serif">03/01/2015 08:39 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject:   </font><font size="1" face="sans-serif">Re: [squid-users] question about encrypted connection between https client and Squid</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Sent by:   </font><font size="1" face="sans-serif">"squid-users" <squid-users-bounces@lists.squid-cache.org></font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">On 2/03/2015 9:55 a.m., Eliezer Croitoru wrote:<br>
> Hey Yuri,<br>
> <br>
> On 01/03/2015 20:17, Yuri Voinov wrote:<br>
>> Normally you never use CONNECT method over HTTP ports. This is<br>
>> prohibited by squid basic security requirements.<br>
> <br>
> The above statement is true only if the proxy admin prohibit this.<br>
> A CONNECT method can be allowed and can be used for any purpose what so<br>
> ever the admin of the server sees right.<br>
> There are basic default settings which allows the usage of a CONNECT<br>
> method only to access specific "ssl safe ports".<br>
> <br>
> The "right" way (if these one) to access squid using an encrypted<br>
> channel would be throw either a tunnel or another proxy which can<br>
> forward the request into squid.<br>
<br>
There *is* a Right Way.<br>
<br>
It is this:<br>
<br>
1) using this in squid.conf:<br>
     https_port 3129 cert=/path/to/proxy.pem<br>
<br>
2) client connects to 3129 using TCP, then performs TLS handshake.<br>
<br>
3) client sends requests inside the encrypted connection as if they were<br>
HTTP to a proxy but using https:// URL scheme.<br>
<br>
Thats is *all*.<br>
<br>
It is very simple. It works well with SSL-enabled Squid.<br>
<br>
It avoids both the page-long list of NAT/TPROXY interception problems<br>
and the other half-page list of SSL-bump hijacking related prblems.<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
squid-users@lists.squid-cache.org<br>
</font></tt><tt><font size="2"><a href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>