5

I want to start off by saying that I am not an expert in regards to networking or Wireshark but I do have a background in web development, particularly .net and iis/windows server.

I am trying to add a couple of ciphers in the Cipher Suites of my server. This is because the server I am connecting to made a patch to theirs and requested people connecting to them with these ciphers added. I am currently getting a TLS Handshake Failure when I connect to them.

enter image description here

These are the ones I need:

ECDHE-RSA-AES128-GCM-SHA256(OpenSSL) - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE-RSA-AES256-GCM-SHA384(OpenSSL) - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA

I added the Cipher Suite equivalent, which should be the ones I actually need.

Even though I added them (using gpedit.msc and iiscrypto), I have them placed on the first part of the whole cipher list, it does not seem to show up when I trace it in Wireshark.

IISCrypto enter image description here Update: Ciphers from image above are changed to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

SSL Ciperh Suite Order

TLS__ECDHE_RSA_AES128_GCM_SHA256,TLS_ECDHE_RSA_AES256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Wireshark Trace the 3 highlighted ciphers do not appear on the trace enter image description here What are the common causes of this?

UPDATE: Confirming that the the server accepts the ciphers requested thru nmap.

| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
  • 3
    These cipher names are a mix of the syntax used in openssl and in the RFC. It is not clear what and where you have something configured in the first place (code?) and if it was accepted as a valid configuration. It is also not clear what you have seen in Wireshark and if this might be the ciphers you have configured but with a different naming convention. Please add the missing details to your question. – Steffen Ullrich Oct 28 '19 at 12:56
  • @schroeder Yes, I added the message as well. Where it says Handshake Failure. Not sure if that helps. May I know if there are other parts? – ffadriala Oct 28 '19 at 17:52
  • Sorry, I was not clear. The Client Hello does not tell you what the server is offering. It's telling you what the client is expecting. So, you might not have a server issue. Your client might not be able to use the cipher suites you want them to. – schroeder Oct 28 '19 at 17:56
  • @schroeder Thanks for directing it here. Just to clarify, I am the client in my scenario who is connecting to a server. Let me know if I make sense or need to edit part of my question. I found some tools that could help me but so far seems to work for public websites. I am connecting to an internal one and may need to test these tools. – ffadriala Oct 28 '19 at 19:00
  • 1
    "Even though I added them ... I have them placed on the first part of the whole cipher list, it does not seem to show up when I trace it in Wireshark." - I'm saying that the Client Hello will never show the list that is on the server. – schroeder Oct 28 '19 at 19:56
5

I think your question is based on a misunderstanding of how the TLS handshake and specifically the cipher selection works and what you can see on the wire.

The cipher selection is done by the client sending a list of ciphers the client accepts and the server then selecting one cipher from this client offer. This means only the ciphers acceptable by the client are included in the TLS handshake. The list of ciphers acceptable by the server are not included in the handshake and that's why you cannot see it.

You can only get the ciphers supported by the server by using a client configuration which only offers this specific cipher. If the server accepted the cipher it will support it, if not it (most likely) will not support it. And that's exactly what the nmap command you've used does - just tries lots of different ciphers and checks if the handshake succeeds.

3

If you're talking about those ciphers for use in SSL/TLS, you need to configure it appropriately for Windows. If they're not showing up during negotiation, you probably haven't configured it correctly.

You need to configure the client and/or the server to support them:

  1. General SChannel Cipher info: https://docs.microsoft.com/en-us/windows/win32/secauthn/cipher-suites-in-schannel
  2. Configuring them via policy: https://docs.microsoft.com/en-us/windows-server/security/tls/manage-tls

And if you are Linux friendly, here is a solid article on using nmap to output the SSL/TLS cipher negotiation to the conosle: https://medium.com/@rootsecdev/configuring-secure-cipher-suites-in-windows-server-2019-iis-7d1ff1ffe5ea

What's a common cause of this? ...misconfiguration. You are either not setting this up correctly in the first place or the setting is being overwritten by something (e.g. Group Policy, some security product), etc.

  • Thanks for the info, I am currently going through the pages. I know there's a lot, but give me time to get through the paragraphs. I am using Windows Server 2008 R2 Standard. Let me check on the group policy. – ffadriala Oct 28 '19 at 17:57

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.