On 6/10/2016 8:46 p.m., Vieri wrote: > Hi, > > > > ----- Original Message ----- >> From: Amos Jeffries <squid3@xxxxxxxxxxxxx> >>> Is it correct to assume at this point that the current openssl >>> build on this system is "OK" as far as supporting "Win XP TLS 1.0 >>> ciphers to access at least google.com"? >> >> Yes. The build is capable of it. That is one of 3 conditions that >> must > >> be met for it to work.> The other two being: >> >> * whether it is enabled in the library config. - OpenSSL library >> has its own conf file somewhere. - it is possible that curl and >> other tools whose primary design purpose > >> is communication (not testing) override the library normal defaults >> for> their own use, or re-try certain things after failures. That >> needs to be > >> eliminated to be sure.> * that the squid.conf settings combine with >> those library settings to > >> cause it to be (or stay) enabled.[...] So far we can assume that it >> is either a Squid bug relaying the > >> available cipher list between the two remote endpoints. Or that the >> set of ciphers available to Squid does not include the DES-CBC3-SHA >> one.[...] > >> The fact that the library can be > >> configured independent of any application using it throws a rather >> big > >> spanner into the expected behaviour logics. > [...] >> So far your tests are showing that it is about a 50/50 chance of >> being a bug in Squid versus a Squid/OpenSSL misconfiguration >> somewhere. > > > I don't know what a library configuration file is. OpenSSL has a CONF > library/functions to read its own .cnf files. An application such as > Squid can use these functions to read a conf file, or not. Unless I'm totally confused there is a system-wide conf file that the library can/does load on its own before all that. > > I'm assuming that at compile time, both the openssl library and squid > were built with most features. Is there a way to list available > openssl ciphers from squid (like a squid command line tool)? As if > Squid were to call an openssl library function to "list available > ciphers",or something. Unfortunately not. Squid (mostly) passes the squid.conf strings directly to the library parser so that list the library produced should be what Squid is _able_ to use. The detail to be careful of is whether squid.conf contains any such strings that change the library defaults. > >> To test that last detail you probably need to setup a normal >> https_port with SSL and see if you can connect to it with TLSv1.0 >> and only that cipher in curl. That will eliminate any possible >> server details polluting the test result. > > What is a "normal https_port with SSL"? eg. https_port 3132 > cert=/etc/ssl/squid/proxyserver.pem I would appreciate a full conf > example so there are no squid misconfigurations that would make the > test results even more confusing. I mean an https_port that is not doing ssl-bump or intercept. https_port 3129 ssl \ cert=/etc/ssl/squid/cert.pem \ key=/etc/ssl/squid/key.pam (unless you have cert + key in the same .pem, then key= is not needed) > > BTW, does sslproxy_cipher default to ALL if undefined in squid.conf? > No. If undefined in squid.conf the library default ciphers are used. In recent years that has been a bit volatile and changes with library version, so I cant be more specific. "ALL" enables a lot of ciphers and TLS/SSL features that were known to be unsafe when the library was released. So are not included in the default available set. >. Squid > "debug_options" is already very verbose but maybe it would help in > this case to add extra information as to how Squid is calling openssl > (and maybe seeing if it's possible to get the cipher list). > Good idea. Thanks. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
