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. Matt _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
