On 19/08/15 16:07, Alex Rousskov wrote: > Your interpretation is correct: Your configuration tells Squid to peek > at steps #1 and #2 and then try to bump at step #3. Unfortunately, the > last two actions (peeking at step #2 and then bumping at step #3) are > usually not compatible. Please see the Limitations section at > http://wiki.squid-cache.org/Features/SslPeekAndSplice Ah! I used to use "external_acl_type" to run a script that would check the SSL status of the host:port and that would allow squid to decide whether to bump or splice. I'd turned it off for whatever reason - I guess that's why it was working before. (in all of this I am speaking in the context of transparent TLS - I realize for the formal proxy scenario you typically have the SNI name/hostname via the CONNECT method). Sure enough, once I deleted the peeks, it started bumping So is there no way to get the SNI field from the client without breaking the opportunity for bump? It's just that my testing has already shown everyone using CloudFlare for HTTPS is now protected by their WAF technology - which rejects SSL sessions that don't contain SNI. So if you are wanting to (transparently) bump HTTPS, you can't use peek - but you need peek in order to discover the SNI hostname, because if you don't have that then acls using ssl::server_name_regex and/or "external_acl_type" will basically get rejected talking to vast numbers of https servers in the world. This is a bit of a catch-22 My packet sniffer implies the SNI details is in the first TLS packet sent from the client (ie pre-encryption). So couldn't squid just make a note of that detail? Sort of a "pre-peek" I guess? I read about how there are so many SSL extensions/etc that squid will always be running afoul of issues if it tries to be too smart, but can't we look at this as 1. client->server (3-way TCP handshake) 2. client sends first TLS packet (contains extensions data - including SNI). Gets to squid server 3. squid can extract that data, and make decisions immediately just on that one packet. It can compare with acls and decide to bump or splice 4. if bump, squid forms the client->squid TLS channel and a separate squid->server TLS channel 5. if splice, squid now forms a TCP channel to the server, then forwards that first TLS packet, then "joins the two ends" 6. waits for next client packet If all HTTPS transactions contained the hostname (because of CONNECT or SNI), then squid could be set to default to bump, but to splice known "un-bumpable" sites - due to pinning or because they are not actually HTTPS sites (eg Skype). It just seems like it's currently limited to default splice, with bumping explicit things? (which I can't believe is useful) -- Cheers Jason Haar Corporate Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
