On 23-Aug-17 09:28, Daniel Stenberg wrote:
> This said, I actually don't think this little warning will change much
> as we users are well trained since long at ignoring warnings -
> especially if everything still seems to work fine.
>
Agree. I don't think it's harmful, except in that it adds to the 'you
can ignore warnings' training. I would prefer to see curl attempt to
verify the host (regardless of -k), and only retry (and warn) without
verification if the first attempt fails and -k was specified. That way
the user is warned only when the -k actually has an effect. This will
prevent warning overload.
>> a) Encourage DANE (and support it in curl) - though whether curl
>> support would drive adoption is open
>
> That's a looong term vision. Not to mention how this then expects
> people to put their self-signed certs into the DNS, which most
> certainly will always be more complicated than just keep using
> --inscure...
>
But that can be automated too, especially with DNS UPDATE. But yes,
it's non-trivial. However, it is the more secure approach - DNSSEC
protects the certs & their authenticity, and there's only one place to
update - rather than a lot of files on a lot of systems.
> making it reality, it is a big chunk of complicated work.
Agree.
> DANE is not exactly getting much love from the browser world so it's
> not likely to be a real solution for HTTPS within the forseeable future.
>
Agree - but someone has to go first. Browsers aren't anxious to support
because there's no demand; there's no demand because browsers don't
support it. curl could be helpful - but I agree it's a long & hard
road. Which is why I didn't say much about it and suggested plan B as a
pragmatic approach.
>> 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.
>
> That's indeed an interesting idea! That's a long list of issues to
> deal with though, that are things that makes this much more
> complicated than the "easy" case ssh has with known hosts.
>
PKI is inherently complicated. known_hosts/authorized_keys is rather
crude hack - it doesn't scale well, and updating on a key/cipher
change/revocation is painful - every host/client pair has to be updated.

BUT: It's "good enough". Human intervention is minimal, yet it enforces
(more or less) secure behavior. And despite its problems, it has been
effective for a long time. It makes people think, but doesn't get in
the way once trust is established.

This thought was to apply "good enough" thinking to the curl world. The
nice thing about this model is that a user doesn't have to repeat or
modify the command. It's a once/host (certificate) confirmation.

> In addition to that great list of challenges we also have
>
They're more questions than challenges - implementing any answer doesn't
appear to be particularly difficult.
> * what TLS library backend is used
That doesn't seem especially hard to abstract. They all take a
cafile/capath, so appending a local trust store should be doable, though
the mechanisms vary. It's work - but I don't see an architectural issue.
> * HTTPS proxy support (for some TLS backends)
I don't see how that's involved; at most it's a minor issue. If curl
talks to a proxy, it's the proxy's certificate that has to go to the
local trust store. The proxy has to deal with trust with respect to the
'real' server; this doesn't change that. If curl IS a proxy, the same
mechanism for injecting additional trust used for server verification
can be used for client verification.
> I firmly agree that it would be really neat with a start at this that
> at least helps the user more towards getting rid of the --insecure
> option.
>
This could be built incrementally - take the simplest answers to work
out the UI. E.g. a proof of concept might:

  * Restrict to self-signed (this is the biggest simplification)
  * Warn about not in validity period; ignore revocation for the first pass.
  * Warn in prompt if certificate trusted for a host changes
  * Reject files/directories with o=w - maybe a compile mask of
    forbidden permissions
  * It overrides --quiet interactively - human intervention is required,
    and the alternative is to fail.
  * Make trust default to port-specific for self-signed; allow an
    override or wildcard. Default to '*' when non-self-signed support
    is added
  * Implement only one backend; stub out the others.
  * Don't worry about proxy support

Once you have confidence & some user feedback, go back and provide more
capabilities/options.

But that's just my impression of a reasonable approach; I'm not deeply
familiar with curl internals, and this won't be on my project list.

One more question - should curl's local trust store interact with the
browsers'/system's certificate trust store? If so, which one(s) and
how? [e.g., when a user adds a certificate to Firefox, can/should curl
trust it? Can/should curl's trust store be the same as
Firefox/Windows/the TLS library? Or should curl update those?
Optionally? Provide import/export?

Anyhow, these are all more design questions than ones for a users' list.

I don't have time to contribute coding/detailed design to this, but
would be able to review a design if you elect to proceed. I opened
github issue 1822 so that future work/discussion/commits can be linked
to this thread, and I'll see notifications. (I don't read curl-users
regularly.)

Glad to have provoked some thought.

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