🔐 Cipher Suite Negotiation

Cipher Suite?

A cipher suite is a set of cryptographic algorithms, which are negotiated within the secure channels to talk securely to servers, which is used by TLS or the older version called SSL.

This "key exchange algoritm" is used for data exchange between two devices, cipher suites can include signatures and an authentication algorithm to help authenticate the server and or client.

How are they defined?



Examples?

Sure, lets take my website that uses TLS v1.3 and ask nmap to get all the cipher suites from it, that command is : 

nmap -script ssl-enum-ciphers <website>

That return this which includes the Cipher suites with in nmap

TLS v1.3 Ciphers

So lets focus on the TLS v1.3 ciphers here:

TLSv1.3:

|     ciphers:

|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A

|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A

|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A

This means to connect on TLS v1.3 you need an client that supports this Cipher suites,  so lets take Server 2022 which will support these ciphers which was taken from this

Enabled by Default

TLS_AES_256_GCM_SHA384

TLS_AES_128_GCM_SHA256

Supported but not enabled by default

TLS_CHACHA20_POLY1305_SHA256

This will cause an issue here, as there is no cipher that can be used from my blog on TLS v1.3 that works with Server 2022, this means that platform cannot talk TLS v1.3 to by blog, which means it will negotiate TLS1.2 as a common cipher will not work.

TLS v1.2 Ciphers

TLS v1.3 is not an option, so lets look at TLS v1.2 ciphers, here we have a couple more, so hopefully more options......

 TLSv1.2:

|     ciphers:

|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A

|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A

|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A

|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

TLS v1.2 on Server 2022 supports these ciphers which was taken from this

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

From the excerpt, excellent now we have a match, all three of those match which means that Server 2022 will be talking to my blog using TLS v1.2 rather than TLS 1.3.

Cipher Mismatch?

Note : In Wireshark you will need the search filter of tcp.port==443

Yes this occurs, here using Wireshark we can see an example of this in the flesh so to speak.

Here we can see TLS v.1.0 using used to talk on two ciphers locally from the server as you can see below, this is the "client hello"....

However when the handshake takes place we get an error, the server response has not gone well at all.....

 

which when expanded gives the error:

I should get the  Client Key Exchange, Change Cipher Spec Encrypted Handshake - but I get the error - which means our server can send a hello, but does not get a handshake from the other end, in this case no secure connection was established.

Cipher Suite Agree and Match

Note : In Wireshark you will need the search filter of tcp.port==443

This is what it should look like, you should get a "client hello" then a "server hello" then a certificate....

Well when it works this is the "client hello" with all the Ciphers.....

The in the server hello, you will see the negotiated Cipher suite as below:

Then the final stage is you will get the certificate, notice unlike before this was not a fatal error, this was the actual certificate.....