[squid-dev] default SSL client and server methods

[Amos Jeffries]

On 11/09/2015 5:04 a.m., Tsantilas Christos wrote:
> Hi all,
> 
>   starting from Stuart Henderson mail about libreSSL I saw that in
> current squid trunk (but not squid-3.5), for many Linux OS systems we
> are always using SSLv23 as default method while connecting to server or
> connecting to clients, without giving an other alternate to the users..
> 
> The problem I am seeing is that we are using the TLS_server_method() and
> TLS_client_method() which are available only in openSSL-1.1.0 and later.
> But many OSes still using older openSSL libraries, so the users for
> these systems are forced to use SSLv23 method without any other alternate.
> 

Yes. That is intentional. TLS negotiation is different from SSL
negotiation. The code difference is mirrored the squid.conf options
change from sslversion=N to tls-min-version=1.M

Where in SSLv2 or SSLv3 the specification around method allows saying
"this is my single version", and use only that version (no others).
 - Squid would identify the appropriate X-only method and use it.
 - OR, Squid would fallback to SSLv23_* and let the library use the
options string to determine method.

TLS says use a range from highest the library supports, down to some
minimum. (Until SSLv3 is disabled that should be left at minimum of
TLSv1.0 to avoid issues with FALLBACK_SCSP extension).
 - the library uses the options string to locate the appropriate method.
Always now rather than just as a default fallback.

For a proxy who needs to support maximum range of clients and servers we
should be using the range-based negotiation with configurable range
limits. Admin with more knowledge can use the options= parameters to
achieve X-only behaviour if they like to. Admin without the knowledge
required to do that are protected from shooting themselves and users in
the foot.

Regarding the library API function names;

The SSLv23_*_method() have been renamed to TLS_*_method() in the current
libraries. They operate in close enough the same way to be considered
drop-in replacements according to the OpenSSL documentation.

The method() selection was never something Squid got to decide. It was
always admin configured and the squid.conf settings to achieve it are
now different.

So is there a problem now?

Amos