On 26/06/19 2:45 pm, Jared Fox wrote:>
> == Bad news / Major Blocker ==
> https connections to cloud tracing is still being blocked, these are
> TLS 1.2 and uses SNI as seen via tcpdump.
>
Okay, now that you have the v4 capabilities:
* Please add %ssl::bump_mode to your log so we can see easily which
SSL-Bump step each transaction is representing. The
"cloudtrace.googleapis.com" ones all say 200 (success) so it is not
clear whether that is a successful peek, or successful terminate action.
Please be aware that in your config the ssl::server_name ACL is *not*
matching the SNI in your config.
- Your ssl_bump rules say "peek all" - so peek happens on the two Hello
messages. When the serverHello has been peek'd the real server name is
available from the servers own certificate.
So that server cert name is what the ssl_server_name matches against
when checking the "splice domainIsWhitelisted" rule.
The dozens of servers at cloudtrace.googleapis.com call themselves
"edgecert.googleapis.com" and have a long list of sub-domains for
googleapis.com.
==> I suggest changing domainIsWhitelisted to match just the
".googleapis.com" part of the domain.
Alternatively you can add the new "--client-requested" flag to the ACL,
which will force it to use the SNI even after more reliable info is
available. Like so:
acl domainIsWhitelisted ssl::server_name \
--client-requested cloudtrace.googleapis.com
If those do not work, then someone will need to dig down into the
cache.log debug trace of what the ssl_bump ACLs are matching against.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
