(ootw stands for option of the week)
Long form: --insecure. The title is a little misleading, but this refers to the lowercase -k option.
This option has existed in the curl tool since the early days, and has been frequently misused ever since. Or I should perhaps call it “overused”.
Truly makes a transfer insecure
The name of the long form of this option was selected and chosen carefully to properly signal what it does: it makes a transfer insecure that could otherwise be done securely.
The option tells curl to skip the verification of the server’s TLS certificate – it will skip the cryptographic certificate verification (that it was signed by a trusted CA) and it will skip other certificate checks, like that it was made for the host name curl connects to and that it hasn’t expired etc.
For SCP and SFTP transfers, the option makes curlskip the known hosts verification. SCP and SFTP are SSH-based and they don’t use the general CA based PKI setup.
If the transfer isn’t using TLS or SSH, then this option has no effect or purpose as such transfers are already insecure by default.
Unable to detect MITM attacks
When this option is used, curl cannot detect man-in-the-middle attacks as it longer checks that it actually connects to the correct server. That is insecure.
Slips into production
One of the primary reasons why you should avoid this option in your scripts as far as possible is that it is very easy to let this slip through and get shipped into production scripts and then you’ve practically converted perfectly secure transfers into very insecure ones.
Instead, you should work on getting an updated CA cert bundle that holds certificates so that you can verify your server. For test and local servers you can get the server cert and use that to verify it subsequently.
Optionally, if you run your production server on a test or local server and you just have a server name mismatch, you can fix that in your test scripts too just by telling curl what server to use.
libcurl options
In libcurl speak, the -k functionality is accomplished with two different options: CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER. You should not allow your application to set them to 0.
Since many bindings to libcurl use the same option names you can also find PHP programs etc setting these to zero, and you should always treat that as a warning sign!
Why does it exist?
Every now and then people suggest we should remove this option.
It does serve a purpose in the chicken and egg scenario where you don’t have a proper certificate locally to verify your server against and sometimes the server you want to quickly poll is wrongly configured and a proper check fails.
How do you use it?
curl -k https://example.com
You’d often use it in combination with -v to view the TLS and certificate information in the handshake so that you can fix it and remove -k again.
Related options
--cacert tells curl where to find the CA cert bundle. If you use a HTTPS proxy and want the -k functionality for the proxy itself you want --proxy-insecure.
An alternative approach to using a CA cert bundle for TLS based transfers, is to use public key pinning, with the --pinnedpubkey option.
“it is every easy” i think you meant to type “it is very easy”
@Cork: I did indeed mean that. Thanks, fixed now!
Rather than fully deprecating that option, have you considered making CURLOPT_SSL_VERIFYHOST and CURLOPT_SSL_VERIFYPEER produce warnings when set to 0, to make them more likely to get caught if deep in an application? Or otherwise making those options more likely to raise warning signs?
libcurl really has no safe place to send warnings to that will be noticed and won’t risk causing problems, so no. I don’t see how we can do that!