On 23-Aug-17 06:00, curl-users-request_at_cool.haxx.se wrote:
> Message: 3
> Date: Wed, 23 Aug 2017 10:08:37 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: curl users <curl-users_at_cool.haxx.se>
> Subject: --insecure
> Message-ID: <alpine.DEB.2.20.1708230958320.25548_at_tvnag.unkk.fr>
> Content-Type: text/plain; format=flowed; charset=US-ASCII
>
> Hi friends,
>
> On github alone, "curl --insecure" is used in source code at least 117,000
> times. With a possible addition of about 196,000 instances where "curl -k" is
> used.
>
> Some of these use cases are probably totally legit, especially when you get
> things from localhost or similar, but many of them should probably rather make
> the connection to the self-signed server secure by using a cacert for it.
>
> Is there anything we can do to reduce the use of insecure SSL connections done
> by curl in the world?
Yes, see below.
> Would adding a warning help? Here's a PR doing that:
>
> https://github.com/curl/curl/pull/1821
I don't see how this helps. I know I specified --insecure - confirming
it doesn't incent me to do otherwise.
>
A few thoughts:

In my experience, the reason for the common use of --insecure is that
it's too painful to add trust for a self-signed certificate. Getting it
from the server and adding it to a trust store is a multi-step, arcane
process. And once there, it probably doesn't persist. (E.g., openssl
s_client -connect foo.example.org:443 </dev/null | sed ... find and add
to ca_bundle/path [hashing the latter] - and the next cert bundle
removes it. Or add explicit --capath/--cacert to every curl command
that touches such a host. In any case, I ran my curl command; it
failed. I added trust. I try again. Three phases, probably a dozen
commands. Hey, I just want my file... what are the chances I'm being
spoofed? I get paid for results - and it's snack time.) Don't tell me
that a smart guy can do it simpler or can script the process. That's
true - but you shouldn't have to be "smart" to securely get a file. Or
have time to spare.

Things to consider:

a) Encourage DANE (and support it in curl) - though whether curl support
would drive adoption is open

b) Take a leaf from ssh's book: add a simple mechanism for retrieving a
server's certificate and adding it to a trust store. The trust store
could be curl-specific (~/.curl/trusted_certificate_bundle or
~/.curl/trusted_certificate_path/), or add it to the SSH cafile/capath
(with sufficient privs). In the latter case, mk-ca-bundle.pl (or
equivalent) needs a mechanism to include locally-trusted certs; I
suspect adding to capath is easiest.

The most likely to be accepted model would be that on a certificate
failure, there's a prompt similar to ssh's:
    The self-signed certificate offered by foo.example.org is not trusted.
    Issuer/subject: /C:AQ/L:McMurdo/CN:foo.example.org Valid 1-Apr-2001
thru 31-Mar-2037
    12 bit RSA key. Fingerprint: BEEFDAD..., Not revoked.
    Do you want to continue connecting? [y/N/a]
Where 'a' adds to (some) trust store.

If the trust store is curl-private, there need to be facilities to list
the content and to revoke trust; probably also purge expired/revoked.

Another model is to have curl (or a separate utility) contact a server
with the sole purpose of obtaining its certificate and adding it to a
trust store. e.g curl --trust-certificate foo.example.org:443

There are quite a few questions to answer about the details of
implementation, among them:

  * Should non self-signed certificates be included? (E.g. a new or
    local CA) - if so, how far up the trust chain does one go to find
    the certificate to add? (The leaf? The first intermediate? The
    root?)
  * What statuses should be allowed? Are expired certs OK? What if CRL
    or OCSP can't be retrieved or indicate revocation/suspension?
  * What if this host already has a different certificate registered?
    Is it an update, or a MITM attack?
  * What permissions are acceptable for the trust store? (E.g. o=w is
    almost certainly a bad thing; g=w may be OK) Should it have a
    checksum or some other tamper detection mechanism? A cron job that
    mails changes to the owner? [You don't want silent trust added...]
  * Should non-interactive jobs have a --ok-to-trust option to skip the
    prompt? (Test suites would like it). If so, should interactive users?
  * How does this interact with --quiet?
  * Is this added trust port-specific? (Many, but not all self-signed
    certs are for a specific service - e.g. TLS or SMTPS. Restricting
    trust to the specific service(s) that a user approved limits exposure.)

There are others - the trick is finding the right balance between "it's
easy" and "it's secure in all cases".

Anyhow, not fully thought out, but perhaps this rough outline will
prompt further development.

Hopefully useful.

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

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