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. The url_rewrite_access directive controls what transactions are sent to the redirector. Note that CONNECTs should be sent both during step1 and during step2 by default. > 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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
