Again thanks for the explanation.
I understand the step1/2/3 for sslbump and Squid extracts the domain
name at various steps(SNI, client hello, server hello,etc) and there is
no guarantee which step will get what I want.
Assuming the ssl is fully bumped(not spliced), that means their http
request-line(the full URL) and http header(e.g. referer) are now
available in clear text inside Squid, my question is that, can Squid now
"extract" them and let me use them via directives, just like I use
url_regex/urlpath_regex/referer_regex when http mode is used.
I tested external_acl_type and the URI/PATH were empty for _bumped_ ssl
traffic too.
Basically I'm trying to see how to get the http-header info from a
bumped ssl connection and use them directly inside squid.conf(including
external acl), otherwise icap/ecap is unavoidable for bumped ssl http
header analysis.
Thanks,
xxiao
On 01/16/2016 10:06 AM, Alex Rousskov wrote:
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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
