On 04/16/2015 12:45 AM, Amos Jeffries wrote: > On 16/04/2015 5:35 p.m., Alex Rousskov wrote: >> On 04/15/2015 06:17 AM, Amos Jeffries wrote: >>> Squid currently has several "version" options to set the SSL/TLS >>> protocol version. >>> >>> http(s)_port ... version= >>> cache_peer ... sslversion >>> sslproxy_version ... >>> >>> However, >>> >>> 1) the option configures version X-only. Which does not follow with >>> current best practice of most other TLS enabled software offering a >>> minimum-version option for compliance with TLS version auto-upgrade >>> mechanisms. >>> >>> This can result in Squid installations being stuck unnecessarily on >>> outdated protocol versions with insecure ciphers. >>> >>> >>> 2) these options overlap with the related ssloptions= values. >>> >>> These can easily be configured to conflict. Such as version setting >>> TLSv1.0-only and ssl-options enabling other versions with v1.0 >>> forbidden. The order of security context setup prevents this being a >>> major problem, but it can result in security doing things the admin does >>> not exactly expect. >>> >>> >>> 3) the http(s)_port option is also easily confused with protocol= since >>> it lacks a "ssl" prefix seen elsewhere. >>> >>> >>> I would like to eventually move towards having a TLS minimum-version >>> parameter like other software. Which means we at least need to begin >>> clearing up this problem ASAP. >>> >>> Given that the ssloptions= parameters can be used to reach the same >>> configuration I propose that we simply remove the current sslversion >>> options. >>> >>> Opinions? >> >> >> I agree that having both ssloptions and sslversion is wrong when both >> can restrict SSL versions. However, I am pretty sure there are cases >> where the admin needs to restrict SSL version to be "exactly X" rather >> than "X or later". Removing an existing interface that supports such >> "exactly X" configurations seems wrong to me. If you remove sslversion, >> can you add ONLY_SSLv3, ONLY_TLSv1, etc. values to the remaining ssloptions? > > ssloptions already supports enumerating the protocols one does not want > to support.
Which is different than enumerating the protocols one wants to support when the set of possible protocols is a moving target. > sslversion=1 == ssloptions= > sslversion=3 == ssloptions=NO_TLSv1,NO_TLSv1_1,NO_TLSv1_2 > sslversion=4 == ssloptions=NO_SSLv3,NO_TLSv1_1,NO_TLSv1_2 > sslversion=5 == ssloptions=NO_SSLv3,NO_TLSv1,NO_TLSv1_2 > sslversion=6 == ssloptions=NO_SSLv3,NO_TLSv1,NO_TLSv1_1 The above does not look equivalent to me when TLS v1.3 appears. As you said, we should care about old configurations that get "stuck" with the now-wrong set of options. When the admin wants Squid to use X (e.g., because the peer requires X), they should be able to say so and not depend on any new versions added to OpenSSL. >> Alternatively, instead of removing sslversion, consider obsoleting >> NO_SSL* and NO_TLS* options in ssloptions while adding support for a >> more flexible sslversion configuration: >> >> cache_peer ... sslversion=TLSv1.0+ # TLSv1.0 or later >> cache_peer ... sslversion=TLSv1.1 # exactly TLSv1.1 >> cache_peer ... sslversion=TLSv1.0,TLSv1.0 # TLSv1.0 or 1.1 >> ... >> >> This will allow admins to configure "minimum-version" (in most cases) >> without losing the ability to restrict versions to a specific subset (in >> special cases). > > This is similar to what I was wanting to move towards. If you think I > should compress the timeline and go straight to this I can: > > cache_peer ... tls-version=1.0+ # TLSv1.0 or later > cache_peer ... tls-version=1.1 # exactly TLSv1.1 (warn risky, etc) If you deprecate the old sslversion values, do not drop SSL support, and allow versions enumeration (assuming it is useful, see below), sure! If you prefer to do two configuration changes instead of one, please explain why you think those two changes would be better than their cumulative result. > Your third example *version=N,M conflicts with the specifications. [ Real-world often conflicts with specifications. As you probably know, I think we ought to support real-world requirements rather than specification recommendations when the two are in conflict. Everybody should support your persistent efforts to make Squid compliant with currently popular specifications (and follow new terminology), but not at the expense of real-world compatibility (and admin convenience). ] If you are sure that nobody needs version=N,M support or that OpenSSL does not support such configurations, then do not add it. Avoid it not [just] because some specification told you so, but because it is useless! Cheers, Alex. _______________________________________________ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
