[squid-users] client-->iptables-->squid-proxy->another-proxy

[Amos Jeffries]

On 21/08/17 09:53, Diogenes S. Jesus wrote:
> Hi Amos. Thanks for pointing it out - but this has never been an 
> acl-related issue, more like a https_port / ssl-bump configuration 
> question when the upstream ssl request was not sending a "CONNECT 
> www.example.org:443 <http://www.example.org:443>" but a "GET 
> htttps://www.example.org <http://www.example.org>".
> 

There are a couple of things wrong with that.

Firstly, port 443 traffic does not validly contain "GET https://..." 
requests. It should only contain origin-form requests same as port 80. 
The 'https' part is generated by Squid from the fact those requests are 
received by an https_port and thus must have been wrapped by TLS/SSL for 
the HTTP portion to become handled by Squid.


Secondly, Squid internally generates synthetic/fake CONNECT messages to 
represent the intercepted traffic on an https_port. Simulating HTTPS 
sent through a forward/explicit proxy. At step1 that is done with the 
TCP SYN packet details, at step2 with the client TLS SNI details.
  Splice simply tells bumping not to decrypt any CONNECT message, 
including those synthetic ones. The Squid-generated CONNECT is then 
caused to be sent upstream to the peer by not being unwrapped/decrypted. 
This type of generated CONNECT is implemented any nobody having trouble 
with it that I'm aware of.


Thirdly, What is being asked for by JerlyCook and others is some form of 
filtering to be done at the front-end proxy for https:// traffic before 
it gets sent to the parent/sibling proxy. So splicing is not always a 
viable choice for those use-cases even if it is technically the best and 
safest thing to do.


Amos