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
Received on 2015-11-30