Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
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 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
Hi Peter, Unfortunately I am not privy to the reasons for choosing this particular cipher suite. 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)? Does it make it easier for an attacker to "fake" a certificate and impersonate the server? 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. Regards, Ahmed On Mon, May 4, 2020 at 4:38 PM Peter Wu 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 > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
Hello Peter,
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.
Regards,
Ahmed
On Sat, May 2, 2020 at 3:21 PM Peter Wu wrote:
> Hi Ahmed,
>
> I have posted a patch at https://code.wireshark.org/review/37034 which
> should allow you to see the plaintext. However there is a big open
> question about the draft specification. Can you share some more details
> on your implementation, in particular which TLS library do you use?
>
> Without more answers, this patch will not be merged.
>
> Kind regards,
> Peter
>
> On Sat, May 02, 2020 at 10:55:07AM -0700, Ahmed Elsherbiny wrote:
> > Wow this is great news, thank you Peter!
> >
> > Regards,
> > Ahmed
> >
> > On Sat, May 2, 2020 at 10:21 AM Peter Wu wrote:
> >
> > > Hi Ahmed,
> > >
> > > On Fri, May 01, 2020 at 02:10:01PM -0700, Ahmed Elsherbiny wrote:
> > > > Hello,
> > > >
> > > > I've written a dissector for a custom protocol. The dissector works
> well,
> > > > and now I'm trying to run the protocol over TLS 1.3.
> > > >
> > > > The cipher suite being used is TLS_SHA256_SHA256 (Code: 0xC0B4).
> This is
> > > a
> > > > new cipher suite, it is used for integrity and has a null cipher (The
> > > > payload is actually plaintext). It is still in draft form, here is
> the
> > > > document that describes it:
> > > >
> https://www.ietf.org/id/draft-camwinget-tls-ts13-macciphersuites-05.txt
> > > >
> > > > Looking at the ServerHello packet, Wireshark shows the CipherSuite as
> > > > Unknown (0xC0B4). Consequently, it does not provide a "Decrypted
> > > > application data" tab and does not pass the data to my dissector.
> > >
> > > The new cipher name was added in the development build via commit
> > > v3.3.0rc0-513-g3e2a837cc0 (https://code.wireshark.org/review/36052).
> It
> > > is not present in the stable build yet.
> > >
> > > > This is what the TLS debug log shows:
> > > [..]
> > > > I tried adding the cipher-suite to packet-tls-utils.c and recompiling
> > > > Wireshark. This is the line that I added, since the document says
> that
> > > > Diffie-Helman is the only key exchange that can be used. I'm not
> > > completely
> > > > sure that I'm using the correct macros - I don't fully understand
> TLS.
> > > >
> > > > {0xC0B4, KEX_DH_ANON, ENC_NULL, DIG_SHA256, MODE_GCM }
> > >
> > > This is not correct, TLS 1.3 has a different key exchange (KEX_TLS13)
> > > and more changes are needed to ensure that existing TLS 1.3 ciphers do
> > > not break while adding support for this new cipher.
> > >
> > > I've created a test samples for the two ciphers and posted these at
> > > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16543
> > >
> > > I hope to have a patch available tomorrow.
> > > --
> > > Kind regards,
> > > Peter Wu
> > > https://lekensteyn.nl
> ___
> Sent via:Wireshark-dev mailing list
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
Hi Ahmed,
I have posted a patch at https://code.wireshark.org/review/37034 which
should allow you to see the plaintext. However there is a big open
question about the draft specification. Can you share some more details
on your implementation, in particular which TLS library do you use?
Without more answers, this patch will not be merged.
Kind regards,
Peter
On Sat, May 02, 2020 at 10:55:07AM -0700, Ahmed Elsherbiny wrote:
> Wow this is great news, thank you Peter!
>
> Regards,
> Ahmed
>
> On Sat, May 2, 2020 at 10:21 AM Peter Wu wrote:
>
> > Hi Ahmed,
> >
> > On Fri, May 01, 2020 at 02:10:01PM -0700, Ahmed Elsherbiny wrote:
> > > Hello,
> > >
> > > I've written a dissector for a custom protocol. The dissector works well,
> > > and now I'm trying to run the protocol over TLS 1.3.
> > >
> > > The cipher suite being used is TLS_SHA256_SHA256 (Code: 0xC0B4). This is
> > a
> > > new cipher suite, it is used for integrity and has a null cipher (The
> > > payload is actually plaintext). It is still in draft form, here is the
> > > document that describes it:
> > > https://www.ietf.org/id/draft-camwinget-tls-ts13-macciphersuites-05.txt
> > >
> > > Looking at the ServerHello packet, Wireshark shows the CipherSuite as
> > > Unknown (0xC0B4). Consequently, it does not provide a "Decrypted
> > > application data" tab and does not pass the data to my dissector.
> >
> > The new cipher name was added in the development build via commit
> > v3.3.0rc0-513-g3e2a837cc0 (https://code.wireshark.org/review/36052). It
> > is not present in the stable build yet.
> >
> > > This is what the TLS debug log shows:
> > [..]
> > > I tried adding the cipher-suite to packet-tls-utils.c and recompiling
> > > Wireshark. This is the line that I added, since the document says that
> > > Diffie-Helman is the only key exchange that can be used. I'm not
> > completely
> > > sure that I'm using the correct macros - I don't fully understand TLS.
> > >
> > > {0xC0B4, KEX_DH_ANON, ENC_NULL, DIG_SHA256, MODE_GCM }
> >
> > This is not correct, TLS 1.3 has a different key exchange (KEX_TLS13)
> > and more changes are needed to ensure that existing TLS 1.3 ciphers do
> > not break while adding support for this new cipher.
> >
> > I've created a test samples for the two ciphers and posted these at
> > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16543
> >
> > I hope to have a patch available tomorrow.
> > --
> > Kind regards,
> > Peter Wu
> > https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
Wow this is great news, thank you Peter!
Regards,
Ahmed
On Sat, May 2, 2020 at 10:21 AM Peter Wu wrote:
> Hi Ahmed,
>
> On Fri, May 01, 2020 at 02:10:01PM -0700, Ahmed Elsherbiny wrote:
> > Hello,
> >
> > I've written a dissector for a custom protocol. The dissector works well,
> > and now I'm trying to run the protocol over TLS 1.3.
> >
> > The cipher suite being used is TLS_SHA256_SHA256 (Code: 0xC0B4). This is
> a
> > new cipher suite, it is used for integrity and has a null cipher (The
> > payload is actually plaintext). It is still in draft form, here is the
> > document that describes it:
> > https://www.ietf.org/id/draft-camwinget-tls-ts13-macciphersuites-05.txt
> >
> > Looking at the ServerHello packet, Wireshark shows the CipherSuite as
> > Unknown (0xC0B4). Consequently, it does not provide a "Decrypted
> > application data" tab and does not pass the data to my dissector.
>
> The new cipher name was added in the development build via commit
> v3.3.0rc0-513-g3e2a837cc0 (https://code.wireshark.org/review/36052). It
> is not present in the stable build yet.
>
> > This is what the TLS debug log shows:
> [..]
> > I tried adding the cipher-suite to packet-tls-utils.c and recompiling
> > Wireshark. This is the line that I added, since the document says that
> > Diffie-Helman is the only key exchange that can be used. I'm not
> completely
> > sure that I'm using the correct macros - I don't fully understand TLS.
> >
> > {0xC0B4, KEX_DH_ANON, ENC_NULL, DIG_SHA256, MODE_GCM }
>
> This is not correct, TLS 1.3 has a different key exchange (KEX_TLS13)
> and more changes are needed to ensure that existing TLS 1.3 ciphers do
> not break while adding support for this new cipher.
>
> I've created a test samples for the two ciphers and posted these at
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16543
>
> I hope to have a patch available tomorrow.
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
> ___
> Sent via:Wireshark-dev mailing list
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Trying to decode a TLS 1.3 with null cipher
Hi Ahmed,
On Fri, May 01, 2020 at 02:10:01PM -0700, Ahmed Elsherbiny wrote:
> Hello,
>
> I've written a dissector for a custom protocol. The dissector works well,
> and now I'm trying to run the protocol over TLS 1.3.
>
> The cipher suite being used is TLS_SHA256_SHA256 (Code: 0xC0B4). This is a
> new cipher suite, it is used for integrity and has a null cipher (The
> payload is actually plaintext). It is still in draft form, here is the
> document that describes it:
> https://www.ietf.org/id/draft-camwinget-tls-ts13-macciphersuites-05.txt
>
> Looking at the ServerHello packet, Wireshark shows the CipherSuite as
> Unknown (0xC0B4). Consequently, it does not provide a "Decrypted
> application data" tab and does not pass the data to my dissector.
The new cipher name was added in the development build via commit
v3.3.0rc0-513-g3e2a837cc0 (https://code.wireshark.org/review/36052). It
is not present in the stable build yet.
> This is what the TLS debug log shows:
[..]
> I tried adding the cipher-suite to packet-tls-utils.c and recompiling
> Wireshark. This is the line that I added, since the document says that
> Diffie-Helman is the only key exchange that can be used. I'm not completely
> sure that I'm using the correct macros - I don't fully understand TLS.
>
> {0xC0B4, KEX_DH_ANON, ENC_NULL, DIG_SHA256, MODE_GCM }
This is not correct, TLS 1.3 has a different key exchange (KEX_TLS13)
and more changes are needed to ensure that existing TLS 1.3 ciphers do
not break while adding support for this new cipher.
I've created a test samples for the two ciphers and posted these at
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16543
I hope to have a patch available tomorrow.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
