[squid-dev] [RFC] removal of SSL version options

[Amos Jeffries]

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