libSSL includes a hard-coded ordered list of SSL/TLS cipher suites, which controls the order in which cipher suites appear in the client's ClientHello message. There are cases for which the application might want to use a different order than the hard-coded one. For example, one may want to prioritize : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA At the current time, this cannot be accomplished with the NSS API. The only way to force TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA to be negotiated is to disable TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA But this has the side affect of falling to possibly even less desirable cipher suites when operating with some servers. IMO, NSS should include an API to allow the application to order the cipher suites. A possibly prototype would be : SECStatus SSL_CipherPrefOrderSet(PRFileDesc *fd, const PRInt32 cipherList, const PRUint32 cipherNum); and corresponding get function : SECStatus SSL_CipherPrefOrderGet(PRFileDesc *fd, PRInt32 retCipherList, PRUint32* cipherNum); where cipherNum would be an in/out parameter, specifying the maximum size of the return array on input, and set to the actual number upon return.
If a cipher suite is not included in cipherList, where will it be ordered? Or will this function disable unlisted cipher suites implicitly?
Masatoshi, My proposal is that this single call to CipherPrefOrderSet would disable all cipher suites not listed in cipherList . Ie, an application would use this call instead of calling SSL_CipherPrefSet multiple times.
Thanks for the clarification. Another suggestion: I would not like to call this function every time I create an fd. (i.e. I want SSL_CipherPrefOrderSetDefault/SSL_CipherPrefOrderGetDefault.)
Yes, we can add the global variants for this call as well. Note that you can use a model socket so you don't have to call this for every fd - just once, for the model socket. This is how Oracle apps work - one model socket per listener .
You need to log in before you can comment on or make changes to this bug.