On Fri, Nov 29, 2019 at 3:02 AM Daniel Stenberg <[email protected]> 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
