[openssl-users] Failure using ECDH-RSA-AES256-SHA with ssl3 on Master Branch

[Jakob Bohm]

On 23/03/2015 14:48, Matt Caswell wrote:
> On 23/03/15 13:45, Viktor Dukhovni wrote:
>> On Mon, Mar 23, 2015 at 01:01:29PM +0000, Matt Caswell wrote:
>>
>>>> As Viktor states RFC 4492 says if the client sends no TLS extension
>>>> containing the curves supported then the server can choose any supported
>>>> curve. So your fix is to continue when we reach the second iteration if
>>>> there are no curves in the second list rather than flag an error.
>>> Essentially yes, although with the refinement that the first iteration
>>> checks the list of available curves for this SSL. This may or may not be
>>> the same as the complete list of curves available in this *build* (e.g.
>>> if SSL_set1_curves_list() has been used).
>> I would expect that a client sending an *empty* list of supported
>> curves means no curves are supported by the client, and the server
>> would not enable EC.  The case where the server is free to choose
>> any curve is presumably when the client does not send a supported
>> curves extension at all.
> It is not valid to send an empty list. If the client uses the extension
> then they *must* set at least one curve. Therefore if the client list is
> empty then it can only be because the extension was not used.
Is sending an empty list technically impossible in the
protocol, or just not currently permitted.  If it is
just not currently permitted then one needs to contemplate
whya client would (in a future "update" RFC for a backwards
compatible TLS version) beallowed to send an empty list
rather than simply not proposing any ECC cipher codes.

One possible interpretation could be "Not only don't I
support any of the currentlypublished ECC ciphers, I will
not accept ECC signatures in the cert chain either".

Another possible interpretation could be "I support arbitrary
curves, both thoseenumerated in the standards and those
explicitly specified".

The second interpretation happens to match what the proposed
patchdoes implicitly, while the first interpretation does not.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded