On 08/21/2016 06:46 AM, Marcus Kool wrote:
there are still some issues with the wiki page that I like to clarify.
Thanks a lot for working on this!
wiki: http://wiki.squid-cache.org/Features/SslPeekAndSplice
section "processing steps"
Can action "none" be removed from step 1?
Done.
Step 1. what is "CONNECT info"? In the introduction one speaks
of "HTTP CONNECT" which has a FQDN. But the fake CONNECT sent to
a URL rewriter has only an IP address.
CONNECT info is the info associated with a CONNECT request, real or fake
(depending on the http*_port being used for the transaction). Real
CONNECT requests often have FQDNs. Fake CONNECT requests have IP
addresses during step1.
Why is the fake CONNECT that is sent to the URL rewriter done
at step 1 where only the IP and not the FQDN is available?
... because some rewriters want/need those CONNECTs, for various
reasons. The overall design here is simple and logical in my biased
opinion: Send everything by default but let admin control what should be
sent. If _your_ rewriter does not need some CONNECTs, configure Squid
not to send those unwanted CONNECTS to the rewriter. If Squid lacks ACLs
to detect unwanted CONNECTs, add support for those missing ACLs.
In section "Peek at SNI and Bump" it is stated that SNI is obtained in
step 1. This contradicts the text at step 1 and 2.
In section "Peek at SNI and Bump" it is NOT stated that SNI is obtained
in step 1. It is stated that SNI is obtained by peeking during step 1.
"obtaining SNI" and "peeking" are not the same! If, during step 1, you
tell Squid to peek, then, during step 2, Squid peeks and obtains SNI.
There is no contradiction, but we are definitely struggling with how to
describe what is going on. Specific improvement suggestions are very
welcomed.
squid.conf.documented has this:
# At each SslBump step, Squid evaluates ssl_bump directives to find
# the *next* bumping action (e.g., peek or splice).
Emphasis on "*next* bumping action".
Should the wiki be reworded and use "next bumping action"?
Please suggest complete specific fixes. We know that the current wiki
text is difficult to follow for many so the attempts to rework it are
welcomed.
Section "Actions"
item peek: Receive client SNI (step1), or server certificate (step2) ...
This contradicts the explanation of the processing steps.
item stare: likewise.
I do not think it does (see the "peeking during step1 tells Squid to get
SNI during step2" discussion above), but please suggest a better way to
phrase those descriptions. We know they are confusing. SNI (and
certificate parsing) happens at the beginning of stepN+1 but whether
that step happens at all depends on the stepN action.
I suggest to remove the "Deprecated actions" or use a BOLD warning not
to use them.
I do not think we should remove them because comparing their description
with the currently supported actions may be very useful for upgrading
admins. Does not Squid already emit a deprecation WARNING when those
actions are used?
If you know how to gray-out the rows with deprecated actions, please do
that. Otherwise (or in addition to that), please feel free to add a
"Avoid this deprecated, poorly supported, and soon to be deleted
action." or similar text to each deprecated action description.
Section "Mimicking SSL client Hello properties when staring"
The section has "The information in this section is incomplete and
somewhat stale."
Is there any information to update this section ?
Yes, but it is only Squid sources and possibly commit log :-(.
section "Examples"
I usually write explicit rules like this:
# do not touch servers where ssl-bump breaks HSTS
acl tls_allowed_hsts ...
# prevent bumping some allowed servers with self-signed certificates
acl tls_allowed_selfsigned ...
...
I recommend against documenting ACLs as actions. Your tls_allowed_hsts
does not prevent touching anything. Your tls_allowed_selfsigned does not
prevent bumping of any connections. Etc. ACLs are conditions. They only
identify certain transactions. They do not touch/prevent/allow/block
anything. The rules that use those ACLs do all that.
# TLS/SSL bumping steps
ssl_bump peek tls_s1_ip_connect all # peek a client connecting at IP level
ssl_bump splice tls_s2_client_hello tls_to_splice # splice some: do not bump/interfere
ssl_bump stare tls_s2_client_hello all # connect to the server and stare(peek) at its TLS/SSL properties
ssl_bump bump tls_s3_server_hello all # bump if we can (tls_s2_client_hello/stare succeeded)
The above rules follow the steps of the wiki page but
the examples on the wiki have optimised rules and sometimes
there are messages on the mailing list that rules can be optimized
to save CPU cycles.
It is not primarily about CPU optimization. It is about readability.
The last 4 lines of the example can be optimized into
ssl_bump peek tls_s1_ip_connect all
ssl_bump splice tls_s2_client_hello tls_to_splice
ssl_bump stare all
ssl_bump bump all
Actually, they should be written as:
ssl_bump peek tls_s1_ip_connect
ssl_bump splice tls_to_splice
ssl_bump stare all
ssl_bump bump all
And, most likely (possibly after some ACL adjustments) can be further
clarified as:
ssl_bump splice tls_to_splice
ssl_bump stare all
ssl_bump bump all
Which is a lot clearer for some, but not for others.
I prefer not to optimize since reading the rules is
easier and one understands better what happens at each step.
It is a matter of taste.
However, if a significant number of CPU cycles are saved, I suggest to
include an example like above and rules of thumb on how to optimize and the
final optimized results so that a less experienced reader understands
the optimizations.
Please do, but this is not about optimization. It is about describing
desired outcome in two different ways:
* If you want to be verbose and prefix every rule with the step it
applies to, then you can do that (at the elevated risk of forgetting to
tell Squid what to do in some cases among all the noise).
* If you want to express the essence of your configuration, you can do
that instead (at the risk of misinterpreting which step a rule will be
applied at, due to increased complexity).
There are only two "noise reduction" or "condensing" rules AFAICT:
1. Do not say "large green all". Just say "large green".
2. Splice and peek rules are ignored during step 3.
The examples in "Avoid bumping banking traffic" :
I can image what used (but not defined) serverIsBank acl looks like:
acl serverIsBank ssl::server_name .santander.com
but have no idea what the acl haveServerName looks like.
What is intended here?
IIRC, that example was originally written before ssl::server_name
existed. haveServerName would have to detect a request where the server
name is known (e.g., step2 with SNI or step3). The difficulties with
writing such ACLs is what prompted us to add ssl::server_name. The
example should probably be rewritten as:
acl serverIsBank ssl::server_name ...
ssl_bump peek step1
ssl_bump splice serverIsBank
ssl_bump bump all
or even
acl serverIsBank ssl::server_name ...
ssl_bump splice serverIsBank
ssl_bump stare all
ssl_bump bump all
if you do not want Squid to silently bump bank transactions that lack
SNI. I am not sure whether Squid will log level-1 warning when it cannot
splice after staring during step2, but it would be appropriate to teach
Squid to do so IMO (with a rate/count limit of course).
The example description would need to be adjusted accordingly.
Thank you,
Alex.
