Sorry if I missed with a community to ask.

Recently I stumbled on a fact that the same cipher suite can be designated by two different IDs, and this is not a typo nor single occasion.

For instance: http://www.thesprawl.org/research/tls-and-ssl-cipher-suites

  • TLS_ECDH_ECDSA_WITH_NULL_SHA is 0x0047 and 0xC001
  • TLS_ECDH_ECDSA_WITH_RC4_128_SHA is 0x0048 and 0xC002

And few others more, like TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA and TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA.

So, the question is: why two codes are used to designate the same cipher suite? Is it a marker of legacy (broken?) implementation to distinguish? Or just a merge of two standards? Or something else?

  • $\begingroup$ TLS fingerprints. 0x0047 0%, 0xc001 0.07% $\endgroup$
    – kelalaka
    Nov 1, 2018 at 18:55
  • $\begingroup$ Only pocketbeat uses 0x0047 and it is belong to Elasticsearch and all your first numbers belongs to them. Here a list from IBM $\endgroup$
    – kelalaka
    Nov 1, 2018 at 19:05
  • 2
    $\begingroup$ It should be noted that all 4 of those examples are deprecated and should not be used $\endgroup$ Nov 1, 2018 at 19:41
  • 2
    $\begingroup$ The official registry is iana.org/assignments/tls-parameters/… . All of your first numbers are unregistered and in violation of the standard. C001,C002 are standard but insecure and hence unpopular. FFxx are nonstandard but permitted. $\endgroup$ Nov 2, 2018 at 2:55

1 Answer 1


These numbers belong to ElasticSearch;

  • TLS_ECDH_ECDSA_WITH_RC4_128_SHA is 0x0048

and 0x0047 has almost 0% at tlsfingerprint.io

The second numbers in SSL/TLS in this format {0xC0,0x01},{0xC0,0x01},{0xFF,0xE1},{0xFF,0xE0}. The first two in rfc4492. These are deprecated in rfc8422. The last two is for private usage.

The implementations can have different control by the maintainers, therefore it is good to have different numbers. It is bad that your original source doesn't list where they took the numbers.

Note: in TLS 1.3, there are only 5 cipher suites with their id's;

  • {0x13,0x01} - TLS_AES_256_GCM_SHA384
  • {0x13,0x02} - TLS_CHACHA20_POLY1305_SHA256
  • {0x13,0x03} - TLS_AES_128_GCM_SHA256
  • {0x13,0x04} - TLS_AES_128_CCM_8_SHA256
  • {0x13,0x05} - TLS_AES_128_CCM_SHA256
  • $\begingroup$ So, am I correct this is just a merge of two standards, Elastic and SSL? $\endgroup$ Nov 1, 2018 at 22:25
  • $\begingroup$ @YurySchkatula They just merge some lists, maybe contains more than two, as BearSLL/TLS... One has to look at all. $\endgroup$
    – kelalaka
    Nov 1, 2018 at 22:28
  • 1
    $\begingroup$ C001 and C002 are in rfc4492 which applies to TLS 1.0 and 1.1 and was carried forward to TLS 1.2 with some modifications (Appendix A.7 of rfc5246), but deleted by rfc8422 in 2018-08 shortly before this A. FFE0 and FFE1 were and are 'private use' for TLS only, and not mentioned on the page you link. Neither is related to SSLv2 at all; SSLv2 ciphersuites were three octets and those obviously arent. $\endgroup$ Jul 19, 2020 at 2:13
  • 1
    $\begingroup$ First two 'code' lines in section 6. Although often treated as a 16-bit bigendian number, SSL/TLS actually defines CipherSuite as two 8-bit bytes, see e.g. rfc5246 section A.4.1 and A.5. (And iana.org/assignments/tls-parameters/… .) $\endgroup$ Jul 20, 2020 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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