CODEWITHSUNDEEP
sslopensslrabbitmqtls1.2
user369182
user369182

Reputation: 2085

During handshake of TLS connection where does the client fetch the list of cipher suites from?

From where does the client fetches the list of cipher suites that it is going to propose to server?

For example, it looks like that on same machine, clients of two different applications can propose the different list of cipher suits.

To limit the scope of question, I want to understand it for RabbitMQ Client and TLS1.2.

More clarification

So I have RabbitMQ service installed on my machine and then in C# code I try to connect (Ex. var connection = factory.CreateConnection()) to it without any cipher suits configuration.

So here my C# application could be considered as Client.

please note that I am asking about the ciphers that client sends in 'Client Hello' message.

P.S. somewhere I read that rabbitmq internally uses openssl, so when I ran the command 'openssl ciphers -s -tls1_2' I got a list that is different when I see rabbitmq client hello's cipher suits in wireshark. Also I don't have any group policy on machine that overrides the ciphers.

Upvotes: 2

Views: 1062

Answers (2)

Jim Enloe
Jim Enloe

Reputation: 1

Here are the latest TLS 1.3 Oracle cloud ciphers as clients restrict TLS1.2 access to their networks.

TLS_AES_256_GCM_SHA256 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256

Upvotes: -1

Patrick Mevzek
Patrick Mevzek

Reputation: 12595

See https://tls13.ulfheim.net/ for a nice graphical representation of a TLS 1.3 exchange.

In the second message, ClientHello, the client gives among other things a list of ciphers it supports. Where it gets it? Either hard-coded in the application or computed dynamically once decided to connect, etc. this all depends on the application, so you need to investigate its code source/its configuration.

If you take for example openssl s_client as TLS client, you have -cipher and -ciphersuites configuration options to specify which specific ciphers to announce when connecting.

If you look later in the exchange, there is a ServerHello where the server announces which cipher suite will be used.

How that happens? Typically, the server has its own list of preferred ciphers ordered by "quality" (cryptographic strength like preferring 256bits over 128bits and/or other properties like preferring PFS over non PFS), and based on what it got from the client, it tries to select the "best" one that is supported on both side, which is not necessarily always possible.

Now as you put in comments a specific application (Google Chrome), you can see at https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/ssl_cipher.cc;l=1152?q=cipher&ss=chromium%2Fchromium%2Fsrc the definition of a function called "ssl_create_cipher_list" whose goal is to build the cipher list, starting from all compiled ones, and then applying various rules to enable/disable some and sorting them in an order that makes sense. This is of course highly dependent on the application for how it is done, but you can certainly find similar operations in other toolkits.

Finally, do note that there is a big difference between TLS 1.2 (ciphers) and TLS 1.3 (ciphersuites). They are disjoint sets, and when TLS 1.2 has "myriad" of ciphers in the wild (see for example https://www.openssl.org/docs/man1.1.1/man1/ciphers.html for lots of them), TLS 1.3 defines only 5 ciphersuites (see https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4) with one being mandatory to implement, so the whole question of auto-negotiation between client and server becomes almost moot.

As you mention explicitly tls1.2 as tag, do note there is no real reason today not to use 1.3 instead (which is why my first link is on purpose specially for 1.3 - the handshake routine is different in 1.2 but identical for things related to your question of ciphers), you will gain a lot of benefits, from simplified operations, better cryptography all around, and fewer holes.

Upvotes: 2

Related Questions