curl / Mailing Lists / curl-users / Single Mail


Re: curl-users--insecure (Daniel Stenberg)

From: Timothe Litt <>
Date: Thu, 24 Aug 2017 09:37:26 -0400

On 24-Aug-17 06:26, Alex Bligh wrote:
> Even a --getcert flag which retrieves the cert, and a --manualcert flag which accepts that particular cert (or similar) would be helpful. I don't think that should be much harder than specifying ones own trust store to the SSL library.

There is no need for --manualcert - --cacert will do.

You can retrieve a server's certificate with this (or similar) magic:
  openssl s_client -connect </dev/null 2>&1 | \
  sed -ne'/--BEGIN/,/--END/p' >

and then use curl with
   curl --cacert ...
EVERY time you connect to that particular server.

And as I noted earlier, that can be scripted by people willing to invest
the time.
Such a script can be arbitrarily clever about getting & caching
certificates; using
the default trust store when possible, and invoking curl.

But as I wrote previously, this misses the point.

If the goal is to eliminate the use of --insecure, the problem to be
solved is that
any variation of this process is more painful than adding --insecure to
a command
-- or to your alias for curl! Even '--cacert ~/.certs/'
is more
typing than '-k' (or '--insecure').

People are lazy - or more charitably, want to make the most efficient
use of their time.
Users add -k because it appears to trivially solve the 'problem' of curl
failing to connect
to some servers. So any complicated scheme is unattractive, and will
not be adopted
by the majority of users.

To eliminate (or drastically reduce) --insecure, curl needs to make
adding and using
trust painless - at most a one-time confirmation. This is why the SSH
model is attractive. In its simplest form (and most common use case),
it requires no
additional command line options, and it only asks for confirmation ONCE
per server
certificate. The complexities are hidden from the user. There are
details for the curl developers to work through; but better them (once)
than users
(every time).

To remove the incentive to type -k, the solution needs to make things
simpler for the
user, not add more work.

Timothe Litt
ACM Distinguished Engineer
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.


Received on 2017-08-24