Re: [PATCH] squidclient TLS support

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.
Received on Thu Apr 17 2014 - 21:41:00 MDT