All users were logged out of Bugzilla on October 13th, 2018
This is the server-side counterpart of bug 1267894 . Currently, an NSS server negotiates the first cipher suite that appears in the ClientHello which is locally enabled in the server. Some clients have ordered list which may not coincide with the security preference of the server administrator. For example, certain clients prioritize : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA over TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA but the server would prefer to use TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, if the client is compatible available. 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 on the server side. But this has the side affect of falling to possibly even less desirable cipher suites when operating with some clients. We should include an API that allows the server to configured its own preferred ordered list for cipher negotiation. In this case, the server would choose the first cipher from the server's list that appears in the ClientHello. The same prototype could be used for this case as for bug 1267894, or we could use different functions for client and server side. Here is the prototype I proposed for client : 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.
You need to log in before you can comment on or make changes to this bug.