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
