Re: Does cURL accept a CA that is not self signed?

On Fri, Nov 29, 2019 at 3:02 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> I'm convinced most people use a full fledged "CA store" for their curl
> operations just as they do with their browsers.

Some people do; but other people do not. It depends on the engineer
and the problem domain.

Most developers don't know and don't care. Their use case is not worth
talking about because they are happy to set verify=false. They should
take cURL's default.

If I am a browser and I don't know the CA in advance, then I have to
use the CA Zoo. I have to accept the risk.

If I am an organization and I know the CA in advance, then I can shed
the risk of the CA Zoo. I can use my organization's [private] CA, or I
can use __ 1 __ CA from the CA Zoo.

As a security architect in Risk for US Financial and US DoD, I can say
with absolute certainty there are more than a handful of organizations
that reject the practice. We will reject a vendor's solution that uses
the CA Zoo when a single CA will suffice. (What happens in reality is
we apply pressure and they change their practice).

> > If it is the CA Zoo, then folks have exponentially increased their attack
> > surface. I still remember Diginotar [0,1], and more recently companies like
> > Symantec issuing certificates for domains they had no administrative or
> > relationship with or operational control over [2].
>
> Sure, but the CA world has also improved quite significantly since then with
> CT, CAA and more which makes such attacks and mistakes much harder to do now
> without getting caught really quickly.

I could not care less about CT and CAA.

CT does not help me setup a secure channel. It is a tattle tale after
the fact. We have to wait for someone to complain they have been
compromised.

CAA does little to help me setup a secure channel. It increases
failure points and attack surface. With CAA I need to make more
network requests and expand the Trust Model to include yet another
entity.

Going to the network for information that can be built into the app
and distributed to users over a trusted distribution channel makes
absolutely no sense. It is more over-engineering by engineers.

> > No. I'm only using the Let's Encrypt X3 ca certificate. I only use the CA
> > needed for the end entity certificate at hand.
>
> Right, but that is an intermediate cert and not a root cert if I understand
> things correctly so you're asking curl to verify a partial cert "chain".
>
> My Let's Encrypt sites have their certs chained like this:
>
> - ISRG Root X1
> - Let's Encrypt Authority X3
> - [my site]
>
> [from another mail]

Citation, please. RFC 5280, RFC 6125 and CA/B do not require
verification back to a root CA. The CA/B does require a test web page
setup that chains to a root certificate. But there are absolutely no
requirements that software MUST build a path to a root CA.

As far as I know, it is a suggested practice from RFC 4158. And a bad
one at that based on what we know security engineering failures.

In practice, I merely need a certificate with CA:TRUE. Self signed
(AKI=SPKI) means nothing to me or anyone else in practice. Put another
way, I need to decide what to trust.

Sometimes I don't even need CA:TRUE, like when pinning end-entity
certificates. But frequent end-entity certificate rotations by folks
like Google (30 days) and Let's Encrypt (90 days) means pinning an
end-entity cert can be inconvenient.

> > It looks like X509_V_FLAG_PARTIAL_CHAIN was discussed before for cURL, but I
> > could not tell where it ended
>
> I was never merged. From the look of it because nobody argued for it and could
> motivate properly for *why* we would need it so it just faded into oblivion.
>
> "It would fix my problems" isn't strong enough. I will admit that I'm not sure
> I personally can fully assess the security implications of setting that bit.
> But yes, it seems other TLS libraries already have that behavior by default.

I suggest someone unfamiliar with the problems and security controls
available to contain the risk read the first three chapters of Peter
Gutmann's Engineering Security
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). Or read Ross
Anderson's Security Engineering
(https://www.cl.cam.ac.uk/~rja14/book.html). I'll enumerate some of
them from my readings:

* Using a single CA certificate to reduce risk is precisely the "it
fixes my security problem". I decide what risk is acceptable, not
cURL.

* Using a single CA certificate did not suffer the attacks like
Diginotar and Symantec. There is a rich history of failures going back
to 1995: http://wiki.cacert.org/Risk/History . These are not one-off
problems.

* Using the CA Zoo violates a number of Security Engineering
principals. The seminal paper is "Basic Concepts and Taxonomy of
Dependable and Secure Computing". The principal violations include
least privilege, verification, and error detection.

* Using the CA Zoo blows up a Trust Model. There are at least 136
additional edges in the graph that don't need to be present.

* One policy does not fit all, but cURL is forcing it upon users.
GnuTLS, OpenSSL, and Wget got it right.

* Trusting Mozilla to get it right is bad in some instances. Mozilla's
loyalty lies with the CA Cartel, not the users. Mozilla is happy to
include a CA that violates its internal policies and CA/B policies. I
don't even bother commenting on the bugs in Mozilla's tracker anymore.

And last but not least, there is a human cost that engineers always
overlook. Companies are happy to pretend the worst that can happen is
a compromised bank card (losses passed onto share holders) or
compromised PII (losses passed onto the victim after the obligatory 2
years of credit monitoring).

I worked with a Vietnamese guy in the 1990's named Say Ok. Say had
about 6 half-dollar shaped scars in on his chest and abdomen. I asked
him where he got them. He said they happened from when he worked in
the US embassy during the Vietnam war. The North Vietnamese tied to
murder him. They were AK-47 bullet hole scars.

In current times I am aware of at least one Kill/Capture/Influence
program (I was asked to join it). I am aware of the US targeting
civilians in the Middle East. The civilians are not combatants or
militarized. At least one civilian was murdered due to the program. He
was a goat farmer the US targeted because the US felt he could become
militarized. Part of the jacket built on the goat farmer came from
compromised comms.

Governments around the world are surveilling their entire population.
Sometimes it is passive, other times it is active. Governments don't
spy on citizens and journalists for any other reason than to harm
them. If you think there are no human costs associated with these
security engineering failures, you are sadly fucking mistaken.

Jeff
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-11-29