Re: [squid-dev] [RFC] removal of SSL version options
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. 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 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) We can also emit a warning for closed (not X+) sslversions. This alternative assumes OpenSSL supports such flexibility. Your third example *version=N,M conflicts with the specifications. The relevant spec requirement is to MUST advertise the highest version supported by the library being used (which we dont actually know, its library internal) and support receiving all others higher than some minimum (1.0+). Since we are mapping version to option flags we are capable of supporting it if we must. But I would like to avoid that until we have a real need. Most of TLS assumes the above spec mechanism is happening. Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [RFC] removal of SSL version options
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
[squid-dev] [RFC] removal of SSL version options
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? Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] [RFC] removal of SSL version options
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? 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). We can also emit a warning for closed (not X+) sslversions. This alternative assumes OpenSSL supports such flexibility. HTH, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
