14

I have a list of cipher suites in this format:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

Is there a fast, easy way of translating it to more human readable/management readable format? :)

  • may not be exactly what you're looking for but testssl.sh does a nice table at the end of a scan which is more readable than the standard Cipher lists – Rоry McCune Mar 17 '16 at 14:45
13

No, afaik.

Also, if it is supposed to be readable and helpful for non-tech people, each translation might be a book for itself, explaining each part of those strings, it's up- and down sides in painful detail.

Just in case you didn't know, rfc 5246 currently covers this format and includes a table with cipher suites that might send you down a helpful track.

Your example

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384

means "TLS using ECDHE_ECDSA with the elliptic curve P384 for key exchange, encrypting the connection using AES_256 in GCM while using SHA384 as PRF."

As you can see from following the links, there is no 'easy' understanding of the used acronyms themselves. Yet the general syntax is

TLS_nameOfKeyExchange_WITH_nameOfBlockCipherAndMode_nameOfPRFForMAC_addinionalExtensions

As you see from my edit, the inference sometimes fails horribly, too;)

5

The IANA maintains the official registry for defined cipher suites. Each cipher suite is a 16-bit identifier; the "symbolic name" is not nominally standard; most implementations use the names indicated in the registry, but sometimes not, like OpenSSL. OpenSSL has its own naming scheme.

With the IANA registry, you can look up the cipher suite name, which will point you to the RFC that defines that specific cipher suite. It is still up to you to read that RFC to get the actual details.

Now the puzzler is that the string you give is not one of these semi-standard names. It has an extra "_P384" at the end. If you understand the underlying crypto, then you can infer that the "P384" suffix probably relates to NIST standard elliptic curve P-384, defined in FIPS 186-4. So your example, "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384", would be "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" as defined in RFC 5289, used with that elliptic curve.

Inferences can only get you so far. The "TLS_ECDHE_ECDSA" prefix means that the key exchange will use ECDHE (Elliptic-Curve Diffie-Hellman, Ephemeral) and the server will sign its half of ECDHE with its permanent private key (the one corresponding to the public key in the server certificate), and that signature will use ECDSA, a signature algorithm that operates in an elliptic curve. It is unclear whether the "P384" suffix designates the elliptic curve for ECDHE, for ECDSA, or for both (I suspect it is only for ECDHE, but that's just a hunch). This is the problem with non-standard terminology.

Thus, the source of information for understanding your cipher suite names should be the documentation for the tool that produces or consumes these names. Failing that, you are back to making your own conclusions.

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.