Re: [PATCH] squidclient TLS support

On 18/04/2014 9:40 a.m., Alex Rousskov wrote:
> On 04/17/2014 02:19 PM, Amos Jeffries wrote:
>> On 17/04/2014 6:56 a.m., Alex Rousskov wrote:
>>> On 04/16/2014 07:44 AM, Amos Jeffries wrote:
>>>> + // x509 certificate credentials
>>>> + gnutls_certificate_credentials_t certCredentials;
>>>
>>> client or server certificate credentials? I assume it is the latter but:
>>>
>>
>> Everything in this is client oriented since "squidclient" is a client.
>
> Not really. The certificate that squidclient is validating is the server
> certificate. The CA used to validate that certificate is also likely to
> be server-, not client-specific.
>
> You do not have to change any of this -- I am just indicating likely
> confusing places for other folks who would have to deal with this code.
> This is purely based on the experience dealing with similar Squid code
> where it was difficult to understand which end of the transaction the
> code is manipulating (leading to such bugs as client descriptor used in
> server descriptor context, for example).
>
>
>>>> + << " --tls [TLS options] Use TLS on the connection" << std::endl
>>>> + << std::endl
>>>> + << " TLS options:" << std::endl
>>>> + << " --anonymous Use Anonymous TLS." << std::endl
>>>
>>> AFAICT, the new code allows squidclient to establish a secure connection
>
>>> The connection can be encrypted using SSL or TLS, depending on
>>> various factors, right? If yes, please make the new option name
>>> protocol-neutral (e.g., --secure) so that the tool user does not have to
>>> lookup new (to them) protocol abbreviations or change their scripts as
>>> protocol names change.
>>
>> Yes...
>>
>> The prime factor being that one endpoint uses the *TLS* mechanism to
>> negotiate use of SSL/3.0 format messaging.
>
> AFAICT, the vast majority of users do not care whether it is a TLS or
> SSL or some FutureProtocolLayer mechanism. They just need what they call
> a "secure connection" or "SSL connection". We can fight the established
> terminology among our users, but I do not think this particular issue is
> worth the fight.
>
> Curl uses "--ssl" for this. I know you are not a big fan of "SSL" so I
> proposed "secure" as a more neutral and still commonly understood
> replacement. Wget is using --secure-protocol. Both popular tools support
> SSL and TLS, of course.
>
>
>> "secure" would be lying since "--secure --anonymous" then means
>> *insecure* as do various cipher settings, none of which are failures cases.
>
> There is no single word that can describe all the nuances of a complex
> setup. "--tls" is as misleading as "--secure" when squidclient ends up
> not using TLS despite --tls on the command line. "Secure" is what our
> tool users understand to be related to "that SSL stuff". Those advanced
> users that use --anonymous option or custom cyphers are far less likely
> to misinterpret --secure.
>
>
>> "Transport Security" is the most accurate descriptive term.
>
> We need an option name. I doubt "--transport-security" is better than
> "--secure" but it is your call. And if you still insist that "--tls" is
> the best name, then so be it. I am glad I helped fix a bug, but fighting
> over a squidclient option name is not worth our time IMO.
>
>
> Cheers,
>
> Alex.
>

Thank you for the time. I have polished up, re-tested, and applied the
patch to trunk.

Amos
Received on Fri Apr 18 2014 - 15:55:42 MDT