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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
