Wireshark mailing list archives

Re: Trying to decode a TLS 1.3 with null cipher


From: Peter Wu <peter () lekensteyn nl>
Date: Fri, 8 May 2020 00:35:00 +0200

Hi Ahmed,

On Tue, May 05, 2020 at 09:05:53AM -0700, Ahmed Elsherbiny wrote:
Hi Peter,

Unfortunately I am not privy to the reasons for choosing this particular
cipher suite.

If you can share them in private, I would be interested to hear about
the use cases and why alternative configurations do not address it.

Sorry if my questions sounds naive - I'm really not into the security
domain. What would be the risks of using this implementation (with the
nonce issue and half-size key)?

It would not be interoperable with other systems that implement the
actual draft. And future versions of WolfSSL may change to fix this
issue, there is already a patch here:
https://github.com/wolfSSL/wolfssl/pull/2947

From the security point of view:

 - Use of half the hash length is non-ideal, but not critical. 128 bits
   should still be sufficient.
 - The nonce issue should not be problematic either. While the nonce is
   predictable, it does seem to include the record number
   (BuildTls13Nonce in the WolfSSL source code). That prevents
   reordering attacks. Predictability of the nonce should not be
   problematic as the HMAC key is different for the client and server
   and unpredictable which makes it hard for an attacker to breach
   integrity and authenticity.

Does it make it easier for an attacker to "fake" a certificate and
impersonate the server?

No it does not. However, I am not aware of a broader analysis on this
draft TLS 1.3 null cipher. Without such an analysis I cannot say with
confidence whether your impersonation attack is present or not. And
based on earlier communications in the IETF TLS mailing list, the TLS WG
does not seem to be really interested in adopting the draft.

Hence my earlier question about your use cases, maybe an alternative
solution is possible.

My next question would be, what other cipher suites would you suggest?
I heard that TLS1.2 may get deprecated and so, not sure if that would
be a good option.

TLS 1.2 will be there for several years more, I don't see it going away
anytime soon. But between a standardized NULL cipher in TLS 1.2 and a
non-standard NULL cipher in TLS 1.3, I would suggest going for the
former since it is more widely available. And if you are concerned about
compatibility, no good standard configuration will permit the NULL
cipher, so that should not be an argument for choosing one over the
other.

Kind regards,
Peter

Regards,
Ahmed

On Mon, May 4, 2020 at 4:38 PM Peter Wu <peter () lekensteyn nl> wrote:

Hi Ahmed,

On Mon, May 04, 2020 at 03:12:50PM -0700, Ahmed Elsherbiny wrote:
First of all, thank you again for creating the patch. I did test
it and was able to successfully decode some messages.
My implementation uses WolfSSL v4.3.0.

I hope the patch will be merged in, please let me know if there's
any more info you need from my end.

At the moment the patch is unlikely going to be merged pending further
information from the relevant draft authors. Please be very careful with
deploying your information, WolfSSL appears to have a bug in the
implementation of the draft:
https://github.com/wolfSSL/wolfssl/issues/2945

Is your implementation actually going to be used in production? What are
the reasons behind choosing this draft proposal for TLS 1.3 null ciphers
if I may ask?
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: