On 04/12/2018 04:56, Sam Roberts wrote: > Do they overlap in purpose, so the cipher list can be used to limit > the signature algorithms? Or are the signature algorithms used for > different purposes than the cipher suites in the cipher list? The answer varies depending on whether you are talking about TLSv1.2 or TLSv1.3. I'll discuss normal sig algs first (as opposed to client sig algs). In both TLSv1.2 and TLSv1.3 the sig algs describe what signature schemes the client is willing to accept from the server for the signature created in a ServerKeyExchange message (TLSv1.2) or a CertificateVerify message (TLSv1.3). The server will create the signature using the algorithm associated with the public key in the certificate. A TLSv1.2 ciphersuite contains a number of different components - one of which is an algorithm that will be used for signing. Therefore, in TLSv1.2, the ciphersuite that eventually gets selected must be consistent with the algorithm associated with the public key in the certificate and the selected sig alg. In TLSv1.2 on the client side OpenSSL will automatically restrict the cipher list to only include those ciphersuites which are consistent with its configured sig algs. So, for example, if the client is not willing to accept ECDSA based sig algs then it will not offer any ECDSA based ciphersuites. In TLSv1.2 on the server side OpenSSL will attempt to choose a ciphersuite from its configured set that is both consistent with the sig algs sent from the client and with its configured certificates. So for example if the server has both an RSA and an ECDSA certificate available but the client only offers RSA based sig algs, then the server will select an RSA based ciphersuite, and vice versa. In TLSv1.3 things are slightly different because TLSv1.3 ciphersuites do not specify a signature algorithm at all. So, on the client side, the TLSv1.3 ciphersuites sent are unaffected by the configured sig algs. On the server side the TLSv1.3 ciphersuite is selected independent of the sig algs. The server independently chooses a signature algorithm to use entirely based on its available certificate algorithms. Client sig algs are similar to normal sig algs but they only come in to play when client auth has been configured, i.e. the server requests a certificate from the client and the client provides one. In this case, both in TLSv1.2 and TLSv1.3, the sig alg selected is entirely based on the algorithm in the client cert. It is not impacted by the ciphersuite at all. So, for example, the ciphersuite could be based on RSA (because the server's certificate is based on RSA) but the client certificate's algorithm could be ECDSA (and hence the client sig alg in use will be ECDSA based). > > If they have to be configured seperately, is the mechanism to use > https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd_value_type.html > ? They do have to be configured separately. You can do this via the SSL_CONF interface if you wish. Or you can set them directly using the functions described on these man pages: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_sigalgs.html https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
