The RFC only says the server “select[s]” from the ClientHello list. There are two obvious ways, and openssl implements both.
“client preference” – server chooses the first entry in the client’s list that the server can support “server preference” – server chooses the first entry in its own list that the client offers libssl server by default does client preference but does server preference if you set option CIPHER_SERVER_PREFERENCE. Some applications using openssl can do this, notably apache httpd,and during the BEAST furor one widely recommended response was to configure httpd to prefer RC4. (Now RC4 seems to be threatened while BEAST has been mitigated client side, and this is no longer such a good idea.) Other algorithms, such as randomly choosing a suite common to client and server (if there are more than one) would be legal, but silly. TLSv1.2 as a protocol can support all suites implemented by openssl. A given suite will be used only if implemented and (where applicable) configured on both the client and server. In particular, libssl server will agree a suite that uses RSA only if an RSA cert&key is configured, similarly for DSS, and for ECC only if a cert&key is configured *and* it uses a curve and format agreed by the client. DH* and ECDH* suites also require that suitable ‘temporary’ parameters (or optionally keys) be available – through 1.0.1 either configured or via a callback. (1.0.2 will apparently add new options?) Similarly PSK suites require PSK data is configured. Note that ECC, PSK, SRP, GCM, Camellia, SEED and ARIA suites are separate options not in the base RFC and thus a peer system can implement “TLS” without them. TLSv1.1 and lower cannot support the suites labelled TLSv1.2. TLSv1.1 and TLSv1.0, and in openssl SSLv3, can support all suites labelled SSLv3, subject to the same conditions above. Technically the RFCs for ECC, PSK, SRP, and ciphers newer than 3DES only apply to TLS, because SSLv3 (and v2) weren’t IETF standards. openssl does implement them on SSLv3 if the peer agrees, but given the timeline I doubt any peer does except maybe AES. Thus to answer your later question, ECDHE-(RSA,ECDSA)-RC4 is officially supported for TLSv1.0,1.1,1.2 if RFC 4492 is (also) implemented, and for openssl server can be chosen if it has an appropriate key&cert and temporary parameters/key. openssl can also do them on SSLv3 but others might not. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Vladimir Belov Sent: Monday, December 23, 2013 00:24 To: openssl-users@openssl.org Subject: *** Spam *** What is the algorithm of choice cipher suite for connection by Server? Hi, On Server we have an ordered list of cipher suits. Server gets a cipher suits of client in ClientHello. What is the algorithm of choice cipher suite for connection by Server from client's list? Is it simple so: server looks at its ciphers list from top to bottom and the first corresponding cipher suite that will be in ClientHello's cipher list will be chosen for connection. Or something else? And the second question. with command: openssl ciphers -V we can see cipher suits are determined as TLSv1.2 or SSLv3 cipher suits. How can I know all cipher suits which will be use: 1) for TLS 1.2 connections 2) for TLS 1.1 connections 3) for TLS 1.0 connections 4) for SSL 3.0 connections
