[squid-dev] [PATCH] Crypto-NG: Use Security::PeerOptions for listening port TLS settings

[Amos Jeffries]

On 2/07/2015 8:31 a.m., Alex Rousskov wrote:
> On 06/30/2015 10:12 PM, Amos Jeffries wrote:
>> On 1/07/2015 10:11 a.m., Alex Rousskov wrote:
>>> On 06/30/2015 09:27 AM, Amos Jeffries wrote:
>>>
>>>> * Change the tls_outgoing_options default value from "disable" which did
>>>> not parse previously (now does). To setting TLS/1.0 minimum version with
>>>> SSLv3 disabled.
>>>
>>>>  NAME: tls_outgoing_options
>>> ...
>>>> -DEFAULT: disable
>>>> +DEFAULT: min-version=1.0 options=NO_SSLv3
>>>
>>>
>>> Does this change mean that Squid can no longer talk to SSLv3-only sites
>>> unless the admin manually adjusts tls_outgoing_options to include SSLv3
>>> support?
>>
>> Yes. As per your request earlier I am not removing SSLv3 entirely, just
>> reducing it to default-OFF inline with current BCP requirements.
> 
> 
> IMHO, turning SSLv3 off by default now is a mistake for a proxy product
> like Squid. We need to give others more time to follow that BCP first.
> Please make sure there is enough Squid-specific demand for disabling
> SSLv3 support by default today, before you commit this change
> (regardless of what a BCP says about SSLv3).

It is a very high profile change already and has been for nearly a year
yet. Given that this Squid version will not be mainstream for some ~6
months yet

Also, this change only affects outgoing https:// URLs. Making Squid
outgoing behaviour follow what the browsers have already all done. It
does not affect *_port or cache_peer.


> 
>>>> * Fix tls-min-version=1.N handling not to alter stored options= config
>>>> string. Now updates the binary representation in parsedOptions directly.
>>>
>>> Can you describe this bug from the admin point of view? That is, what
>>> Squid trunk behavior was broken that this patch fixes?
>>
>> The first patch which is in trunk appends the NO_* settings to the
>> textual sslOptions member. Which:
>> a) has already been pre-parsed so the setting would have no effect, and
>> b) on dumping the config would output both tls-min-version= and
>> tls-options= (containing tls-min-version textual representation) to the
>> cachemgr report info. Reloading the resulting config dump into Squid
>> would cause sslOptions to have the NO_TLS* options set twice, and so on
>> for each dump/reload loop.
>>  By setting the parsedOptions value directly we ensure the setting
>> actually works on first load, the dumper will only dump out what the
>> user conigured for tls-options=, and that tls-min-versions=1.N and
>> tls-options= interacte properly (tls-min-version= sets absolute floor on
>> the allowed TLS version, tls-options= disables higher ones piecemeal as
>> needed).
> 
> 
> Still trying to translate the above into admin point of view: Let's
> ignore dumping for a moment -- I understand that your changes fix it.
> Dumping aside, are you saying that a freshly started trunk code will not
> have NO_SSLv2 and other NO_* options appended to http_port options=...
> by default, but will still honor manually set http_port options=... and
> tls-options=... values?

NO_SSLv2 is long gone before any of this.

A freshly started trunk will accept SSLv3 and all TLSv1.*. This change
does not affect the availability of any protocol. It solely fixes the
dumper.

> 
> In other words, if a trunk admin sets http_port options=... and
> tls-options=... values explicitly, will he or she be affected by the
> bugs your patch is fixing?

Yes, but its not noticable unless one is using the dumper.

Amos