On 4/7/17 12:22 PM, VMnIgP5yDWURkomdpGjx via curl-users wrote:
> Hello
>
> The -k, --insecure flag https://curl.haxx.se/docs/manpage.html "allows
> curl to proceed and operate even for server connections otherwise
> considered insecure.", which in general means "Don't check the
> validity of TLS certificates".
>
> Allowing this to be set with a single, nondescript character "k"
> (instead of the longer form "--insecure") is dangerous as:
>
> 1) It is hard to notice when reading a script that uses curl,
> especially when multiple other command-line options are also set
It is no harder than reading any other single letter option. By this
logic, should we remove all of those as well?

> 2) It says nothing about the very large security implications;
> "--insecure" is significantly clearer
I am not sure what you mean about that. The security implications of
using -k,--insecure is documented in man curl.

>
> Scenarios where this could occur include:
>
> 1) It's common (due to time/complexity pressures) for developers to
> disable TLS cert checking when first setting up a new program/script,
> then forget to re-enable it before porting their code to a production
> system

How common is this really? I've never seen it in a script, and I've
never done that myself. If they are really having issues with it, why
don't *they* just use --insecure?

> 2) If the user has set other options that imply SSL certificate
> checking is enabled e.g. --cacert, no warnings are printed indicating
> this option is now overridden and useless. The user would be far more
> likely to investigate/pause for thought if they saw "--insecure"
> in-between other SSL certificate related options rather than an
> inconspicuous "-k".
>
The option isn't useless. It just doesn't validate that the cert on the
other side is proper. And again, why would they be using -k if they
don't know what it means?

> 3) The "-k" option is easy to miss during security audits, which are
> often time-limited and require the auditor to know what "-k" means.
> The skill level and time input required by a security auditor to
> notice disabled TLS certificate validation is far lower for "--insecure".
If your security auditor misses a -k in a bash script, that seems like a
shitty security audit. I would be wary of what else they missed. It
isn't that hard to look for a k. The only skill required is knowing the
alphabet.

>
> 4) A malicious attacker could alter a script that used curl to include
> the "-k" option, to provide them with a persistent MITM capability.
> This is less likely to be detected than adding "--insecure".
>
If the attacker has access to your system to alter such a script, you
have much larger problems.

> Proposed change:
>
> Deprecate the short "-k" option in favour of requiring the longer form
> "--insecure". As many scripts will already use the short-hand form, a
> transition plan should be used e.g. showing a warning saying "-k is
> deprecated. Use --insecure instead." for a period of time/set number
> of versions, after which "-k" is removed. Note that after this time
> period breaking existing code (by removing "-k") may not be a bad
> thing, as developers investigating why their scripts don't work will
> have a chance to re-evaluate their choice to disable TLS certificate
> checking.
>
> It would be interesting to know the prevalance in open-source software
> of curl scripts using "-k" or "--insecure", like Google did for the
> Mad Gadget vulnerability
> https://opensource.googleblog.com/2017/03/operation-rosehub.html
>
> Thanks
>
>
> -----------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-- 
Nicholas Chambers
Technical Support Specialist
nchambers_at_lightspeedsystems.com
1.800.444.9267
www.lightspeedsystems.com

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-04-07