Why did the server sent "unsupported extension" alert ?

[hanumesh nk]

Hi Team,
Iam using nss-3.68.4-with-nspr-4.32 in my server. Client is trying to connect to the server using STARTTLS, but after "Client Hello" message is sent, the server sending "Unsupported Extension" to the client and the connection getting closed.

Could anyone help me to figure out which extension did the server not supported?

Below is the client hello message with extensions obtained from tcpdump:
Transport Layer Security
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 751
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 747
Version: TLS 1.2 (0x0303)
Random: <Random>
Session ID Length: 32
Session ID: <Session id>
Cipher Suites Length: 62
Cipher Suites (31 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 612
Extension: ec_point_formats (len=4)
Extension: supported_groups (len=12)
Extension: encrypt_then_mac (len=0)
Extension: extended_master_secret (len=0)
Extension: signature_algorithms (len=48)
Extension: supported_versions (len=9)
Extension: psk_key_exchange_modes (len=2)
Extension: key_share (len=38)
Extension: certificate_authorities (len=463)

Any help to resolve this problem will be really helpful.

Best Regards,
Hanumesh

[Martin Thomson]

It's possible that we have a bug on our end here.

There are two extensions we don't fully support here:

* encrypt_then_mac - we have absolutely no knowledge of this, so we should be ignoring it.

* certificate_authorities - the tricky one

We do understand certificate_authorities, but we don't handle it from the client.  Now, we can (and probably should) ignore it.  TLS 1.3 allows the client to use it, even if it is a rare thing to see in practice.

Can I suggest that you open a bug for this: https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=Libraries  (If you are able, including a full copy of the problematic ClientHello will make this a lot easier for us to diagnose.)

--
You received this message because you are subscribed to the Google Groups "dev-tec...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-tech-cryp...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAMiJu-nkJqwp3fwY9JXPYZSLeu%3DuLU15WYbNxK3OG5ZjTxps9A%40mail.gmail.com.

[hanumesh nk]

Hi Martin,

Thanks for your reply.

I had raised a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1815167 ) as you suggested.

I want this bug to be fixed as soon as possible. The clients are not able to connect to the NSS server and are terminated with "unsupported extension". This is a high priority issue for us.

Could you please guide me to make it a high priority issue and get it fixed in the next ESR release ?

Best Regards,

Hanumesh

[Dennis Jackson]

Hi Hanumesh,

I've submitted a patch to fix this for you which we'll get into the next ESR. In the meantime, there are two workarounds which may work for you:

• Disable TLS1.3 on the server so that connections negotiate TLS1.2; or
  
• Disable certificate_authorities on the clients.

Best,

Dennis

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-tech-crypto/CAMiJu-kF1TVDbY8wXeAW6cUubcFtaYppRCdck2-nRMArrK4Rgw%40mail.gmail.com.

[hanumesh nk]

Hi Dennis,

Thanks for the fix and workarounds.

I have a question out of curiosity about the first workaround suggested. 

In the tcpdump(attached in this mail) and also in the "client hello" attached with the bug, I could see TLS 1.2 is mentioned as the protocol being used for the communication.

So, my question is, if communication is already happening with TLS 1.2, then how would negotiating to TLS 1.2 solve the problem? 

Or the server is still in the process of choosing the TLS version (since the server knows about the versions supported by the client in the "client hello" message) ?

Please, put some light on it and help me understand.

Best Regards,

Hanumesh

[Dennis Jackson]

Hi Hanumesh,

No problem! 

Unfortunately Wireshark doesn't use the right labels for TLS packets, because there's no one right answer. A Client Hello typically supports multiple versions of TLS at the same time and depending on what the server supports, could be used as a TLS1.2 CH or a TLS1.3 CH. So in this case Wireshark is guessing and guessing wrong. If you open the details for that packet and unfold the Client Hello, you should be able to find a Supported Versions extension which contains both TLS1.2 and TLS1.3.

Best,

Dennis

[hanumesh nk]

Thanks again for the clarification and fixing the issue.

Best Regards,

Hanumesh