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

[Alex Rousskov]

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.