[squid-users] https full url

[Alex Rousskov]

On 01/15/2016 07:52 PM, xxiao8 wrote:
> Just found out ssl::server_name_regex that should cover url_regex, for
> urlpath_regex and referer_regex I think I can not get them for
> https/sslbump, to get them an icap/ecap has to be used to read the
> decrypted content at the moment, will squid plan to provide directives
> similar to urlpath_regex/refere_regex for-sslbump in the future?

Your understanding of how HTTPS transactions work still does not match
the reality, resulting in confusion about applicability of various Squid
features, especially ACLs.

One way to improve your understanding of reality is to stop thinking
about HTTPS transaction as a single request/response pair. *Roughly
speaking*, an HTTPS transaction is a sequence of several stages:

1. TCP connection establishment.
2. CONNECT transaction(s) that are HTTP transactions with limited info.
3. SSL connection establishment (and bumping).
4. Bumped HTTPS transaction(s) treated as regular HTTP transactions.

Most HTTP-focused ACLs like url_regex are meant for regular HTTP
transactions (stage #4). They are of limited use for CONNECT
transactions (stage #2) and usually do not work during stages #1 and #3.

ICAP/eCAP adaptation may be applied during stage #2 (with limited
information) and stage #4.

The statement "referer_regex does not work for https/sslbump" is neither
true nor false. Thus, you are getting conflicting responses and are
likely to create poorly working configurations until you realize that
"referer_regex" works well at stage #4 but may also be applied at stage
#2 where it does not work well (not enough information in the CONNECT
requests) or at stages #1 and #3 where it should not be used at all.


ACL is just a "named condition" or a "function". You can type an ACL
name X in any squid.conf directives that use ACLs. That does not mean
that ACL X works with all directives at all times. Someday, Squid or
some squid.conf lint tool would warn about ACLs used in wrong places.
For now, you have to understand what stage-dependent information the
directive has access to and avoid ACLs that require information
unavailable to the directive at the current processing stage.


Good luck,

Alex.
P.S. For intercepted connections, CONNECT transactions in stage #2 are
faked by Squid. For forward-proxied connections, they are real.