On 5/29/2015 12:58 AM, Ray Satiro wrote:
> On 5/28/2015 5:28 AM, Daniel Stenberg wrote:
>> On Tue, 26 May 2015, Ryan Schmidt wrote:
>>
>>> Some time ago the idea was brought up to use openssl's new
>>> -trusted_first / X509_V_FLAG_TRUSTED_FIRST mode; a patch was provided:
>>>
>>> http://curl.haxx.se/mail/lib-2011-12/0223.html
>>
>> I basically only have one question on this: how would a user know
>> when to use and not use --trusted_first ?
>>
>> Isn't this one of those options that just should be enabled if
>> available? What's the downside with that? Or possibly we can have it
>> enabled by default and allow the user to switch it off in case of
>> trouble?
>>
>> PS, an alternative patch can be found here and this version has
>> better error-checking of the OpenSSL calls used:
>>
>> http://kriscience.blogspot.se/2013/03/supporting-trusted-but-untrusted.html
>>
>
> Some more on this and how it may be beneficial. In the last month I've
> twice encountered server-sent legacy intermediates and because the
> Mozilla CA bundle no longer contains the legacy root CA issuer for
> those intermediates the chain no longer verifies. What the bundle does
> contain though is a replacement root issuer that could be used to
> verify the chain. OpenSSL currently will not do this by default.
> Firefox and Internet Explorer seem to handle it fine. If you are using
> the OpenSSL backend try:
>
> curl https://www.mediafire.com
> curl: (60) SSL certificate problem: unable to get local issuer
> certificate
>
> But if you pass the trusted_first flag (1.0.2+) it can verify:
> openssl s_client -trusted_first -CAfile curl-ca-bundle.crt -connect
> mediafire.com:443
> ...
> Verify return code: 0 (ok)
>
> OpenSSL has since said [1] the default behavior will be changed to
> check for alternate chains in 1.1.0 and the next release of 1.0.2,
> (and likely 1.0.1) so I don't know if trusted first will be necessary
> once that happens. I asked in that thread what the disadvantage would
> be if TRUSTED_FIRST is added to libcurl as the default, and
> specifically how that flag relates to the new default alternate check
> since as it stands now OpenSSL won't do the alternate check if
> TRUSTED_FIRST is specified.
>
>
> [1]: http://rt.openssl.org/Ticket/Display.html?id=3621 user/pass
> guest/guest.

Matt Caswell of OpenSSL has updated that ticket with some helpful info
explaining the difference between TRUSTED_FIRST and the new alt chains
behavior. The only disadvantage to using TRUSTED_FIRST is what would
likely be a minor performance hit in the time it takes to check
alternate chains. The new alternate chain check will give us the same
fix with even less of a hit. The two methods are mutually exclusive. I
propose [1] we enable trusted if it's available and the new default
alternate chain check is not available.

[1]: https://github.com/jay/curl/commit/c69ad1d

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-05-30