Sorry Daniel, not much time right now (customers), hopefully I can elaborate later.
> (Let me preface this by saying that I'm not a TLS expert.) Me neither. Just a bit logic juggling. Just one thing: > I think the perfect remedy for a client to detect those things are cert > pinning (ie detecting when a site changes its cert) and possibly oscp > stapling. A remedy for a wider scale detection of these compromises is > Certificate Transparency. > > Or am I wrong? Hmmm, right and wrong. Pinning (TOFU), Transparency and OCSP ((multi-)stapling does not matter here - that is just about optimizing transport) are indeed valuable helping tools to ensure/check trust/security. But if these are not enabled by default, there is only use to "humans that understand this topic" and explicitly enable it. Am I right that (lib)curl does not enable these by default ? If these techniques are enabled, just doing a partial check of the trust chain seems ok to me. On Monday 30 November 2015 09:52:38 Daniel Stenberg wrote: > On Mon, 30 Nov 2015, Tim Ruehsen wrote: > >> What sort of problem do you see with this? > > > > I already gave a scenario where the requested change is dangerous. If you > > think it is not appropriate, please give some arguments. > > (Let me preface this by saying that I'm not a TLS expert.) > > You mentioned a case where the root CA was compromised as a reason. Can you > elaborate on how such a situation would be relevant? > > We've seen compromised CAs several times in the past few years and we've > seen CAs do (stupid) mistakes. Comodo, diginotar, symantec and more. > > In neither of those cases they would suddently populate my CA bundle with a > new faulty cert. Also, in neither of those cases (to my knowledge) would > trusting an intermediate CA had made the situation much different. In all > those cases the CAs handed out certs to sites that they really shouldn't > have and thus the already present root certs and intermediate certs were > unmodified. (Some of them were later removed and/or blacklisted, but that's > a slow process.) > > I think the perfect remedy for a client to detect those things are cert > pinning (ie detecting when a site changes its cert) and possibly oscp > stapling. A remedy for a wider scale detection of these compromises is > Certificate Transparency. > > Or am I wrong? > > >> We don't normally fear adding options in libcurl, but this is a very > >> specialized option that very few users would know how to handle. > > > > ??? IMO, Reiner and Petr know what they want - and they seems to be the > > only ones who needs this feature so far. Why do you think they can't > > handle a CLI option ? > > They would be examples of users in the subset of humans that understand this > topic and would understand what such an option does. The vast majority of > (lib)curl users have much less knowledge of protocols in general and TLS in > particular than Reiner and Petr. And in fact than most people who subscribe > to this mailing list. ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
