Matt,<div><br></div><div>Thank you for reply.</div><div><br></div><div>May I ask you when do you think your patch may land in 1.0.2 or whatever?</div><div><br></div><div>If this is something of your long term goals and not going to land anywhere soon. Could you please tell me about issues in my patch (either privately or in publiс)?</div><div><br></div><div>Thank you again,</div><div>Fedor.<br><br>On Thursday, January 15, 2015, Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 15/01/15 14:21, Matt Caswell wrote:<br>
><br>
><br>
> On 15/01/15 14:13, Fedor Indutny wrote:<br>
>> Hello!<br>
>><br>
>> During the course of deprecation of stale 1024bit CA certs,<br>
>> node.js and io.js project teams have identified the problem with<br>
>> how OpenSSL client handles the server's certificate chain. It is<br>
>> quite evident that it ignores certificate store and loads issuer<br>
>> from the chain that was received. This leads to the problems with<br>
>> AWS and probably other service providers who sent the stale<br>
>> **alternative** certificate chain with same serial numbers, but<br>
>> 1024bit CA certificates.<br>
>><br>
>> I have already tried proposing a solution to the OpenSSL team:<br>
>><br>
>> <a href="https://www.mail-archive.com/openssl-dev@openssl.org/msg37721.html" target="_blank">https://www.mail-archive.com/openssl-dev@openssl.org/msg37721.html</a><br>
>><br>
>> But one of the node.js contributors we have found this commit (from 2010):<br>
>><br>
>> <a href="https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3" target="_blank">https://github.com/openssl/openssl/commit/db28aa86e00b9121bee94d1e65506bf22d5ca6e3</a><br>
>><br>
>> The main question that I have is:<br>
>><br>
>> Is it safe to float this patch on top of 1.0.1k and use it? From<br>
>> my knowledge of code it appears to be pretty harmless, however<br>
>> the fact that it wasn't backported in 5 years makes me wonder if<br>
>> it was considered safe after all.<br>
><br>
> There are some concerns about the performance of trusted_first.<br>
> Successful certificate look ups are cached, whilst failed ones are not.<br>
> Therefore using trusted_first *could* have an adverse impact.<br>
><br>
> This issue is currently under discussion within the dev team. I have an<br>
> alternative patch that addresses the same issue in a different way.<br>
> Essentially it works in a similar way to that which you proposed in<br>
> RT3637. However I have some issues with that patch, so I've done it<br>
> slightly differently.<br>
><br>
> RT3621 is also relevant here.<br>
<br>
I should add that in any case this functionality would never be<br>
backported to 1.0.1 (only considered for future versions). 1.0.1 is a<br>
stable release and only sees bug fixes. This would be considered a<br>
feature and a significant change to the way certificates are verified.<br>
<br>
Matt<br>
<br>
_______________________________________________<br>
openssl-dev mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-dev" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-dev</a><br>
</blockquote></div>