1

I've worked with TLS certs before, but only on a basic level. I'm trying to understand some specific recommendations for implementing TLS (quoted below).

(For context, my goal is to secure HTTPS connections to a web page which collects user information via a form.)

Here are the recommendations (they are from this article):

If you are not a government organization but have HIPAA-compliance requirements and have to interact with people using a wide array of systems and devices, we would recommend the following:

  • Support TLS 1.0, 1.1, and 1.2+
  • Use all of the non-DES ciphers from [certain lists]

Below is my attempt at interpreting this. I'm hoping you can tell me what I've gotten right or wrong.

  1. The TLS version is a property of the connection (in my case, between the browser and the web server) – not a property of the certificate. In other words, when I see "Protocol: TLS 1.2" in the Security tab of Chrome's dev tools, it means that the browser is communicating with the server using version 1.2 of the TLS protocol. It doesn't make sense to talk about the TLS version of a certificate.

  2. The recommendation to support many different ciphers only applies if I'm implementing a TLS client. In my case, the browser is the client – so, when I generate my cert, I just need to choose a single cipher which (a) is on the approved list, and (b) is supported by all major browsers.

Is this accurate? Inaccurate?

  • If 'generate' cert means you create it yourself, the only thing that might depend on ciphersuites is KeyUsage (and not if you use forward-secrecy suites as you should and almost always can); but there are several things you must get right for any HTTPS regardless of suites (CN, SAN, BC, EKU, probably CRLDP and/or AIA.ocsp). If 'generate' means obtain from a real CA, it will take care of these. – dave_thompson_085 Jun 21 '18 at 7:00
1
  1. The TLS version is a property of the connection

Correct. The certificate has nothing to do with the TLS protocol version.

  1. The recommendation to support many different ciphers only applies if I'm implementing a TLS client. In my case, the browser is the client – so, when I generate my cert, I just need to choose a single cipher which (a) is on the approved list, and (b) is supported by all major browsers.

Mostly wrong.
The server should support at least some of the (secure enough) ciphers the client supports. Since different clients might support different ciphers the server should better support a sane and secure set of ciphers to support a variety of clients instead of only a single cipher. See recommendations from Mozilla.

Also, the cipher has mostly nothing to do with the certificate. While ciphers with RSA authentication can only be used with RSA certificates and ciphers with ECDSA authentication only with ECDSA (ECC) certificates one cannot choose a specific cipher when creating a certificate. In other words: a certificate can used with lots of different ciphers. It is only necessary that the kind of public key in the certificate (RSA or ECC) matches the kind of authentication in the cipher (RSA or ECDSA).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.