On 01/31/2013 11:24 PM, Amos Jeffries wrote: > On 1/02/2013 5:17 p.m., Alex Rousskov wrote: >> 2. How to configure two ssl_bump decisions per transaction? >> >> When Peek and Splice is known to cause problems,
> What problems and how would this be known? I will answer the second part first: Problems will be detected because Squid will respond with error messages and/or users will complain that "something does not work". No new magic here. This is how current SslBump (and pretty much any other Squid feature) problems are detected. One example of a problem that will probably happen sooner or later is SSL cypher incompatibility: client supports cyphers A and B, Squid supports cyphers B and C, server supports cyphers C and D. Regular SslBump is possible, but Peek and Splice will fail (if Squid mimics client Hello when talking to the server) because client and server have no common cyphers. In this particular example, the non-proxied connection would probably have failed as well, so it is not a big deal, but one can imagine an SSL server that responds differently to different clients, making Squid look bad. Another example is non-SSL traffic that does not start with some kind of Hello message from the client. In this case, Squid will wait for SSL Hello but nothing will come. Squid will timeout. Initial Peek and Splice implementation will probably handle that as a regular error. Eventually, we will probably have to make behavior on timeouts and other soft errors configurable (e.g., on_peek_timeout=tunnel). >> ssl_bump peek safeToPeek >> ssl_bump none all >> >> ssl_bump_peeked server-first safeToBump >> ssl_bump_peeked splice all >> >> Is that the best configuration approach, or am I missing a more elegant >> solution? > What about making "peek" a flag that can optionally prefix any of the > ssl_bump ACL actions... > > ssl_bump client-first foo !safeToPeek > ssl_bump peek client-first foo > ssl_bump server-first !safeToPeek > ssl_bump peek server-first safeToBump > ssl_bump none all I like that, but I do not think it will work because the ACLs you want to use for the "to peek or not to peek?" decision are going to be different from the ACLs you want to use for "to bump or not to bump _after_ we peeked" decision. The former ACLs would use CONNECT/TCP-level information. The latter ACLs would use SSL certificate information. Thus, you do not want to use the same set of ACLs for one ssl_bump rule. In other words, the decision what to do after we peek cannot be done before we peek. That is why we want to peek in the first place... In your specific example, the "safeToBump" ACL cannot be evaluated until we peek. > Overall the whole thing is getting complex and risks making a huge mess. I agree that this will increase code complexity. I am afraid this is a necessary price to pay for safer, more precise SslBump. As for the mess, I am not sure what you mean exactly, but I do not think Peek and Splice should be allowed to stay in Squid unless it works well in some environments and can be disabled in others. > Time to reduce the options. I do not think it is realistic to expect us to be able to reduce the number of configuration options when adding a new optional feature. I would very much prefer to keep the number of options the same, but we need to find a way to do that. Currently, I cannot offer anything better than adding ssl_bump_peeked or similar, but I hope others can think of something. > This *is* a quazi-legal feature after all. I do not like using scary but undefined terms like that. Virtually any feature is going to be illegal somewhere and useful elsewhere. After all, there are situations where unfiltered internet access is illegal and situations where unfiltered internet access is legal but lethal. I think that we should continue to allow features that significant portions of the community find useful, especially when those features do not violate internet protocols. Let our users decide what is legal and/or moral in their environment. Thank you, Alex.
