On 10/14/2015 05:00 PM, Dan Charlesworth wrote: > I feel like if server-first is working there must be *some* > combination of peek/stare/bump that’ll work too—it can’t be that > “forward secrecy” cipher stuff. While that feeling is natural, you should resist it. Newer SslBump actions do not simply dissect the old ones into smaller steps. The old actions (e.g., server-first) do not do some of the things that the new actions do (e.g., peek extracts and sends SNI but server-first does not). Doing more sometimes leads to more problems, especially in experiment-driven features such as SslBump. Besides different cipher negotiation patterns, you may be hitting a bug that server-first code path lacks, for example. > I really don’t want our customers to have to use server-first if they > decide to employ bumping, so if any of you smart people have any > other suggestions, please send them through. I second Amos' implied suggestion to try the latest Squid 4.0 as the next step. This does not mean you have to _deploy_ Squid 4.0: * If Squid 4.0 does not work in your tests, we will not need to suspect newer ciphers and may get more information from newer logs. We will also be slightly more motivated to fix or improve something. * If Squid 4.0 works, we will know more about your problem and may suggest some other solutions if you have to run an older Squid. In either case, do collect "debug_options ALL,9" cache logs for an isolated test case. Please note that I am not volunteering to examine your logs, and there is no guarantee that this next step will lead to a solution, but it is relatively easy to make that step. HTH, Alex. >> On 15 Oct 2015, at 1:34 AM, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> On 10/13/2015 09:08 PM, Dan Charlesworth wrote: >> >>> But in reality ssl_bump peek step1 & ssl_bump bump step3 is actually >>> splicing everything, it seems. >> >> >> This may not be related to your specific problem, but I want to clarify >> the above. >> >> ssl_bump peek step1 >> ssl_bump bump step3 >> >> A recent Squid mis-configured using the above sketch should indeed >> splice everything. When Squid reaches bumping step2, no ssl_bump rule >> matches, so Squid uses the previous step rule to decide what to do. >> Since peeking implies splicing, Squid splices at step2 and never gets to >> step3. >> >> It is possible that, in his "bump at step3" recommendation below, Amos >> was talking about this kind of configuration: >> >> ssl_bump stare all >> ssl_bump bump all >> >> Bugs notwithstanding, the above results in bumping at step3. >> >> Alex. >> >> >>>> On 14 Oct 2015, at 1:51 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: >>>> >>>> On 14/10/2015 1:13 p.m., Dan Charlesworth wrote: >>>>> Throwing this out to the list in case anyone else might be trying to get SSL Bump to work with the latest version of Safari. >>>>> >>>>> Every other browser on OS X (and iOS) is happy with bumping for pretty much all HTTPS sites, so long as the proxy’s CA is trusted. >>>>> >>>>> However Safari throws generic “secure connection couldn’t be established” errors for many popular HTTPS sites in including: >>>>> - wikipedia.org >>>>> - mail.google.com >>>>> - twitter.com >>>>> - github.com >>>>> >>>>> But quite a number of others work, such as youtube.com. >>>>> >>>>> This error gets logged to the system whenever it occurs: >>>>> com.apple.WebKit.Networking: NSURLSession/NSURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9802) >>>>> >>>>> Apparently this is related to Apple’s new “App Transport Security” protections, in particular, the fact that “the server doesn’t support forward secrecy”. Even though it doesn’t seem to be affecting mobile Safari on iOS 9 at all. >>>>> >>>>> It’s also notable that Safari seems perfectly happy with legacy server-first SSL bumping. >>>>> >>>>> I’m using Squid 3.5.10 and this is my current config: https://gist.github.com/djch/9b883580c6ee84f31cd1 >>>>> >>>>> Anyone have any idea what I can try? >>>> >>>> You can try bump at step3 (roughly equivalent to server-first) instead >>>> of step2 (aka client-first). >>>> >>>> >>>> Amos >>>> >>>> _______________________________________________ >>>> squid-users mailing list >>>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>>> http://lists.squid-cache.org/listinfo/squid-users >>> >>> _______________________________________________ >>> squid-users mailing list >>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.squid-cache.org/listinfo/squid-users > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
