* Propose on enabling TLSv1.3 @ 2020-08-03 5:54 Huang, Matthew (HPS SW) 2020-08-03 22:06 ` Michael D Kinney 2020-08-10 2:59 ` Zhiguang Liu 0 siblings, 2 replies; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-08-03 5:54 UTC (permalink / raw) To: devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 2034 bytes --] Hi: It's Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I'm working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we're having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with "no-ec" option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could've processed the file correctly. But I've managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don't think that would've caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I've applied them for testing and the result is fairly satisfying. If there's a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 4892 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Propose on enabling TLSv1.3 2020-08-03 5:54 Propose on enabling TLSv1.3 Huang, Matthew (HPS SW) @ 2020-08-03 22:06 ` Michael D Kinney 2020-08-10 2:59 ` Zhiguang Liu 1 sibling, 0 replies; 17+ messages in thread From: Michael D Kinney @ 2020-08-03 22:06 UTC (permalink / raw) To: devel@edk2.groups.io, chao-jui.huang@hpe.com, Kinney, Michael D Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 2716 bytes --] Hi Mathew, There are a couple Tianocore Bugzillas open on this topic https://bugzilla.tianocore.org/show_bug.cgi?id=2424 https://bugzilla.tianocore.org/show_bug.cgi?id=2541 I recommend you review these and comment on the current proposals. Best regards, Mike From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Huang, Matthew (HPS SW) Sent: Sunday, August 2, 2020 10:55 PM To: devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 44110 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Propose on enabling TLSv1.3 2020-08-03 5:54 Propose on enabling TLSv1.3 Huang, Matthew (HPS SW) 2020-08-03 22:06 ` Michael D Kinney @ 2020-08-10 2:59 ` Zhiguang Liu 2020-08-10 4:26 ` [edk2-devel] " Huang, Matthew (HPS SW) [not found] ` <1629CD946C53C473.23035@groups.io> 1 sibling, 2 replies; 17+ messages in thread From: Zhiguang Liu @ 2020-08-10 2:59 UTC (permalink / raw) To: devel@edk2.groups.io, chao-jui.huang@hpe.com Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 2567 bytes --] Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It's Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I'm working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we're having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with "no-ec" option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could've processed the file correctly. But I've managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don't think that would've caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I've applied them for testing and the result is fairly satisfying. If there's a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 6947 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-08-10 2:59 ` Zhiguang Liu @ 2020-08-10 4:26 ` Huang, Matthew (HPS SW) 2020-11-19 17:09 ` Matthew Carlson [not found] ` <1629CD946C53C473.23035@groups.io> 1 sibling, 1 reply; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-08-10 4:26 UTC (permalink / raw) To: devel@edk2.groups.io, zhiguang.liu@intel.com Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 3346 bytes --] Hi Zhiguang: Sure, I love to. But I'm new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It's Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I'm working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we're having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with "no-ec" option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could've processed the file correctly. But I've managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don't think that would've caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I've applied them for testing and the result is fairly satisfying. If there's a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 8324 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-08-10 4:26 ` [edk2-devel] " Huang, Matthew (HPS SW) @ 2020-11-19 17:09 ` Matthew Carlson 0 siblings, 0 replies; 17+ messages in thread From: Matthew Carlson @ 2020-11-19 17:09 UTC (permalink / raw) To: Huang, Matthew, devel [-- Attachment #1: Type: text/plain, Size: 359 bytes --] Hey Matthew! I've found Lazlo's guide to be incredibly helpful https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers I also ran into similar problems with Perl on Windows and ended up just using WSL2 and regular Perl on Linux. Glad to hear that MSYS2 Perl worked. -- - Matthew Carlson [-- Attachment #2: Type: text/html, Size: 553 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <1629CD946C53C473.23035@groups.io>]
* 回覆: [edk2-devel] Propose on enabling TLSv1.3 [not found] ` <1629CD946C53C473.23035@groups.io> @ 2020-08-12 11:12 ` Huang, Matthew (HPS SW) [not found] ` <162A80E91C03CB2F.12108@groups.io> 1 sibling, 0 replies; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-08-12 11:12 UTC (permalink / raw) To: devel@edk2.groups.io, Huang, Matthew (HPS SW), zhiguang.liu@intel.com Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1.1: Type: text/plain, Size: 5247 bytes --] Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io <devel@edk2.groups.io> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io; zhiguang.liu@intel.com 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #1.2: Type: text/html, Size: 13322 bytes --] [-- Attachment #2: tlsv13.patch --] [-- Type: application/octet-stream, Size: 23450 bytes --] diff --git CryptoPkg/Library/Include/crypto/dso_conf.h CryptoPkg/Library/Include/crypto/dso_conf.h index 95f4db2b15..851d1d6a5c 100644 --- CryptoPkg/Library/Include/crypto/dso_conf.h +++ CryptoPkg/Library/Include/crypto/dso_conf.h @@ -1,16 +1,16 @@ /* WARNING: do not edit! */ -/* Generated from include/crypto/dso_conf.h.in */ -/* - * Copyright 2016-2019 The OpenSSL Project Authors. All Rights Reserved. - * - * Licensed under the OpenSSL license (the "License"). You may not use - * this file except in compliance with the License. You can obtain a copy - * in the file LICENSE in the source distribution or at - * https://www.openssl.org/source/license.html - */ - -#ifndef OSSL_CRYPTO_DSO_CONF_H -# define OSSL_CRYPTO_DSO_CONF_H -# define DSO_NONE -# define DSO_EXTENSION ".so" -#endif +/* Generated from include/crypto/dso_conf.h.in */ +/* + * Copyright 2016-2019 The OpenSSL Project Authors. All Rights Reserved. + * + * Licensed under the OpenSSL license (the "License"). You may not use + * this file except in compliance with the License. You can obtain a copy + * in the file LICENSE in the source distribution or at + * https://www.openssl.org/source/license.html + */ + +#ifndef OSSL_CRYPTO_DSO_CONF_H +# define OSSL_CRYPTO_DSO_CONF_H +# define DSO_NONE +# define DSO_EXTENSION ".so" +#endif diff --git CryptoPkg/Library/Include/openssl/opensslconf.h CryptoPkg/Library/Include/openssl/opensslconf.h index 3a2544ea5c..22268391ab 100644 --- CryptoPkg/Library/Include/openssl/opensslconf.h +++ CryptoPkg/Library/Include/openssl/opensslconf.h @@ -1,29 +1,29 @@ -/* +/* * WARNING: do not edit! - * Generated from include/openssl/opensslconf.h.in - * - * Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved. - * - * Licensed under the OpenSSL license (the "License"). You may not use - * this file except in compliance with the License. You can obtain a copy - * in the file LICENSE in the source distribution or at - * https://www.openssl.org/source/license.html - */ - -#include <openssl/opensslv.h> - -#ifdef __cplusplus -extern "C" { -#endif - -#ifdef OPENSSL_ALGORITHM_DEFINES -# error OPENSSL_ALGORITHM_DEFINES no longer supported -#endif - -/* - * OpenSSL was configured with the following options: - */ - + * Generated from include/openssl/opensslconf.h.in + * + * Copyright 2016-2018 The OpenSSL Project Authors. All Rights Reserved. + * + * Licensed under the OpenSSL license (the "License"). You may not use + * this file except in compliance with the License. You can obtain a copy + * in the file LICENSE in the source distribution or at + * https://www.openssl.org/source/license.html + */ + +#include <openssl/opensslv.h> + +#ifdef __cplusplus +extern "C" { +#endif + +#ifdef OPENSSL_ALGORITHM_DEFINES +# error OPENSSL_ALGORITHM_DEFINES no longer supported +#endif + +/* + * OpenSSL was configured with the following options: + */ + #ifndef OPENSSL_SYS_UEFI # define OPENSSL_SYS_UEFI 1 #endif @@ -55,9 +55,6 @@ extern "C" { #ifndef OPENSSL_NO_DSA # define OPENSSL_NO_DSA #endif -#ifndef OPENSSL_NO_EC -# define OPENSSL_NO_EC -#endif #ifndef OPENSSL_NO_IDEA # define OPENSSL_NO_IDEA #endif @@ -88,9 +85,6 @@ extern "C" { #ifndef OPENSSL_NO_SEED # define OPENSSL_NO_SEED #endif -#ifndef OPENSSL_NO_SM2 -# define OPENSSL_NO_SM2 -#endif #ifndef OPENSSL_NO_SRP # define OPENSSL_NO_SRP #endif @@ -157,12 +151,6 @@ extern "C" { #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128 # define OPENSSL_NO_EC_NISTP_64_GCC_128 #endif -#ifndef OPENSSL_NO_ECDH -# define OPENSSL_NO_ECDH -#endif -#ifndef OPENSSL_NO_ECDSA -# define OPENSSL_NO_ECDSA -#endif #ifndef OPENSSL_NO_EGD # define OPENSSL_NO_EGD #endif @@ -229,9 +217,6 @@ extern "C" { #ifndef OPENSSL_NO_TESTS # define OPENSSL_NO_TESTS #endif -#ifndef OPENSSL_NO_TLS1_3 -# define OPENSSL_NO_TLS1_3 -#endif #ifndef OPENSSL_NO_UBSAN # define OPENSSL_NO_UBSAN #endif @@ -247,100 +232,100 @@ extern "C" { #ifndef OPENSSL_NO_DYNAMIC_ENGINE # define OPENSSL_NO_DYNAMIC_ENGINE #endif - - -/* - * Sometimes OPENSSSL_NO_xxx ends up with an empty file and some compilers - * don't like that. This will hopefully silence them. - */ -#define NON_EMPTY_TRANSLATION_UNIT static void *dummy = &dummy; - -/* - * Applications should use -DOPENSSL_API_COMPAT=<version> to suppress the - * declarations of functions deprecated in or before <version>. Otherwise, they - * still won't see them if the library has been built to disable deprecated - * functions. - */ -#ifndef DECLARE_DEPRECATED -# define DECLARE_DEPRECATED(f) f; -# ifdef __GNUC__ -# if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0) -# undef DECLARE_DEPRECATED -# define DECLARE_DEPRECATED(f) f __attribute__ ((deprecated)); -# endif -# endif -#endif - -#ifndef OPENSSL_FILE -# ifdef OPENSSL_NO_FILENAMES -# define OPENSSL_FILE "" -# define OPENSSL_LINE 0 -# else -# define OPENSSL_FILE __FILE__ -# define OPENSSL_LINE __LINE__ -# endif -#endif - -#ifndef OPENSSL_MIN_API -# define OPENSSL_MIN_API 0 -#endif - -#if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < OPENSSL_MIN_API -# undef OPENSSL_API_COMPAT -# define OPENSSL_API_COMPAT OPENSSL_MIN_API -#endif - -/* - * Do not deprecate things to be deprecated in version 1.2.0 before the - * OpenSSL version number matches. - */ -#if OPENSSL_VERSION_NUMBER < 0x10200000L -# define DEPRECATEDIN_1_2_0(f) f; -#elif OPENSSL_API_COMPAT < 0x10200000L -# define DEPRECATEDIN_1_2_0(f) DECLARE_DEPRECATED(f) -#else -# define DEPRECATEDIN_1_2_0(f) -#endif - -#if OPENSSL_API_COMPAT < 0x10100000L -# define DEPRECATEDIN_1_1_0(f) DECLARE_DEPRECATED(f) -#else -# define DEPRECATEDIN_1_1_0(f) -#endif - -#if OPENSSL_API_COMPAT < 0x10000000L -# define DEPRECATEDIN_1_0_0(f) DECLARE_DEPRECATED(f) -#else -# define DEPRECATEDIN_1_0_0(f) -#endif - -#if OPENSSL_API_COMPAT < 0x00908000L -# define DEPRECATEDIN_0_9_8(f) DECLARE_DEPRECATED(f) -#else -# define DEPRECATEDIN_0_9_8(f) -#endif - -/* Generate 80386 code? */ -#undef I386_ONLY - -#undef OPENSSL_UNISTD -#define OPENSSL_UNISTD <unistd.h> - -#undef OPENSSL_EXPORT_VAR_AS_FUNCTION - -/* - * The following are cipher-specific, but are part of the public API. - */ -#if !defined(OPENSSL_SYS_UEFI) -# undef BN_LLONG -/* Only one for the following should be defined */ -# undef SIXTY_FOUR_BIT_LONG -# undef SIXTY_FOUR_BIT -# define THIRTY_TWO_BIT -#endif - -#define RC4_INT unsigned int - -#ifdef __cplusplus -} -#endif + + +/* + * Sometimes OPENSSSL_NO_xxx ends up with an empty file and some compilers + * don't like that. This will hopefully silence them. + */ +#define NON_EMPTY_TRANSLATION_UNIT static void *dummy = &dummy; + +/* + * Applications should use -DOPENSSL_API_COMPAT=<version> to suppress the + * declarations of functions deprecated in or before <version>. Otherwise, they + * still won't see them if the library has been built to disable deprecated + * functions. + */ +#ifndef DECLARE_DEPRECATED +# define DECLARE_DEPRECATED(f) f; +# ifdef __GNUC__ +# if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ > 0) +# undef DECLARE_DEPRECATED +# define DECLARE_DEPRECATED(f) f __attribute__ ((deprecated)); +# endif +# endif +#endif + +#ifndef OPENSSL_FILE +# ifdef OPENSSL_NO_FILENAMES +# define OPENSSL_FILE "" +# define OPENSSL_LINE 0 +# else +# define OPENSSL_FILE __FILE__ +# define OPENSSL_LINE __LINE__ +# endif +#endif + +#ifndef OPENSSL_MIN_API +# define OPENSSL_MIN_API 0 +#endif + +#if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < OPENSSL_MIN_API +# undef OPENSSL_API_COMPAT +# define OPENSSL_API_COMPAT OPENSSL_MIN_API +#endif + +/* + * Do not deprecate things to be deprecated in version 1.2.0 before the + * OpenSSL version number matches. + */ +#if OPENSSL_VERSION_NUMBER < 0x10200000L +# define DEPRECATEDIN_1_2_0(f) f; +#elif OPENSSL_API_COMPAT < 0x10200000L +# define DEPRECATEDIN_1_2_0(f) DECLARE_DEPRECATED(f) +#else +# define DEPRECATEDIN_1_2_0(f) +#endif + +#if OPENSSL_API_COMPAT < 0x10100000L +# define DEPRECATEDIN_1_1_0(f) DECLARE_DEPRECATED(f) +#else +# define DEPRECATEDIN_1_1_0(f) +#endif + +#if OPENSSL_API_COMPAT < 0x10000000L +# define DEPRECATEDIN_1_0_0(f) DECLARE_DEPRECATED(f) +#else +# define DEPRECATEDIN_1_0_0(f) +#endif + +#if OPENSSL_API_COMPAT < 0x00908000L +# define DEPRECATEDIN_0_9_8(f) DECLARE_DEPRECATED(f) +#else +# define DEPRECATEDIN_0_9_8(f) +#endif + +/* Generate 80386 code? */ +#undef I386_ONLY + +#undef OPENSSL_UNISTD +#define OPENSSL_UNISTD <unistd.h> + +#undef OPENSSL_EXPORT_VAR_AS_FUNCTION + +/* + * The following are cipher-specific, but are part of the public API. + */ +#if !defined(OPENSSL_SYS_UEFI) +# undef BN_LLONG +/* Only one for the following should be defined */ +# undef SIXTY_FOUR_BIT_LONG +# undef SIXTY_FOUR_BIT +# define THIRTY_TWO_BIT +#endif + +#define RC4_INT unsigned int + +#ifdef __cplusplus +} +#endif diff --git CryptoPkg/Library/OpensslLib/OpensslLib.inf CryptoPkg/Library/OpensslLib/OpensslLib.inf index cc27b8c57c..4ac9d6f53c 100644 --- CryptoPkg/Library/OpensslLib/OpensslLib.inf +++ CryptoPkg/Library/OpensslLib/OpensslLib.inf @@ -199,6 +199,43 @@ $(OPENSSL_PATH)/crypto/dso/dso_vms.c $(OPENSSL_PATH)/crypto/dso/dso_win32.c $(OPENSSL_PATH)/crypto/ebcdic.c + $(OPENSSL_PATH)/crypto/ec/curve25519.c + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/f_impl.c + $(OPENSSL_PATH)/crypto/ec/curve448/curve448.c + $(OPENSSL_PATH)/crypto/ec/curve448/curve448_tables.c + $(OPENSSL_PATH)/crypto/ec/curve448/eddsa.c + $(OPENSSL_PATH)/crypto/ec/curve448/f_generic.c + $(OPENSSL_PATH)/crypto/ec/curve448/scalar.c + $(OPENSSL_PATH)/crypto/ec/ec2_oct.c + $(OPENSSL_PATH)/crypto/ec/ec2_smpl.c + $(OPENSSL_PATH)/crypto/ec/ec_ameth.c + $(OPENSSL_PATH)/crypto/ec/ec_asn1.c + $(OPENSSL_PATH)/crypto/ec/ec_check.c + $(OPENSSL_PATH)/crypto/ec/ec_curve.c + $(OPENSSL_PATH)/crypto/ec/ec_cvt.c + $(OPENSSL_PATH)/crypto/ec/ec_err.c + $(OPENSSL_PATH)/crypto/ec/ec_key.c + $(OPENSSL_PATH)/crypto/ec/ec_kmeth.c + $(OPENSSL_PATH)/crypto/ec/ec_lib.c + $(OPENSSL_PATH)/crypto/ec/ec_mult.c + $(OPENSSL_PATH)/crypto/ec/ec_oct.c + $(OPENSSL_PATH)/crypto/ec/ec_pmeth.c + $(OPENSSL_PATH)/crypto/ec/ec_print.c + $(OPENSSL_PATH)/crypto/ec/ecdh_kdf.c + $(OPENSSL_PATH)/crypto/ec/ecdh_ossl.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_ossl.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_sign.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_vrf.c + $(OPENSSL_PATH)/crypto/ec/eck_prn.c + $(OPENSSL_PATH)/crypto/ec/ecp_mont.c + $(OPENSSL_PATH)/crypto/ec/ecp_nist.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp224.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp256.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp521.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistputil.c + $(OPENSSL_PATH)/crypto/ec/ecp_oct.c + $(OPENSSL_PATH)/crypto/ec/ecp_smpl.c + $(OPENSSL_PATH)/crypto/ec/ecx_meth.c $(OPENSSL_PATH)/crypto/err/err.c $(OPENSSL_PATH)/crypto/err/err_prn.c $(OPENSSL_PATH)/crypto/evp/bio_b64.c @@ -384,6 +421,10 @@ $(OPENSSL_PATH)/crypto/siphash/siphash.c $(OPENSSL_PATH)/crypto/siphash/siphash_ameth.c $(OPENSSL_PATH)/crypto/siphash/siphash_pmeth.c + $(OPENSSL_PATH)/crypto/sm2/sm2_crypt.c + $(OPENSSL_PATH)/crypto/sm2/sm2_err.c + $(OPENSSL_PATH)/crypto/sm2/sm2_pmeth.c + $(OPENSSL_PATH)/crypto/sm2/sm2_sign.c $(OPENSSL_PATH)/crypto/sm3/m_sm3.c $(OPENSSL_PATH)/crypto/sm3/sm3.c $(OPENSSL_PATH)/crypto/sm4/sm4.c @@ -496,6 +537,15 @@ $(OPENSSL_PATH)/crypto/conf/conf_local.h $(OPENSSL_PATH)/crypto/dh/dh_local.h $(OPENSSL_PATH)/crypto/dso/dso_local.h + $(OPENSSL_PATH)/crypto/ec/ec_local.h + $(OPENSSL_PATH)/crypto/ec/curve448/curve448_local.h + $(OPENSSL_PATH)/crypto/ec/curve448/curve448utils.h + $(OPENSSL_PATH)/crypto/ec/curve448/ed448.h + $(OPENSSL_PATH)/crypto/ec/curve448/field.h + $(OPENSSL_PATH)/crypto/ec/curve448/point_448.h + $(OPENSSL_PATH)/crypto/ec/curve448/word.h + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/arch_intrinsics.h + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/f_impl.h $(OPENSSL_PATH)/crypto/evp/evp_local.h $(OPENSSL_PATH)/crypto/hmac/hmac_local.h $(OPENSSL_PATH)/crypto/lhash/lhash_local.h diff --git CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf index 616ccd9f62..c88514efd0 100644 --- CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf +++ CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf @@ -199,6 +199,43 @@ $(OPENSSL_PATH)/crypto/dso/dso_vms.c $(OPENSSL_PATH)/crypto/dso/dso_win32.c $(OPENSSL_PATH)/crypto/ebcdic.c + $(OPENSSL_PATH)/crypto/ec/curve25519.c + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/f_impl.c + $(OPENSSL_PATH)/crypto/ec/curve448/curve448.c + $(OPENSSL_PATH)/crypto/ec/curve448/curve448_tables.c + $(OPENSSL_PATH)/crypto/ec/curve448/eddsa.c + $(OPENSSL_PATH)/crypto/ec/curve448/f_generic.c + $(OPENSSL_PATH)/crypto/ec/curve448/scalar.c + $(OPENSSL_PATH)/crypto/ec/ec2_oct.c + $(OPENSSL_PATH)/crypto/ec/ec2_smpl.c + $(OPENSSL_PATH)/crypto/ec/ec_ameth.c + $(OPENSSL_PATH)/crypto/ec/ec_asn1.c + $(OPENSSL_PATH)/crypto/ec/ec_check.c + $(OPENSSL_PATH)/crypto/ec/ec_curve.c + $(OPENSSL_PATH)/crypto/ec/ec_cvt.c + $(OPENSSL_PATH)/crypto/ec/ec_err.c + $(OPENSSL_PATH)/crypto/ec/ec_key.c + $(OPENSSL_PATH)/crypto/ec/ec_kmeth.c + $(OPENSSL_PATH)/crypto/ec/ec_lib.c + $(OPENSSL_PATH)/crypto/ec/ec_mult.c + $(OPENSSL_PATH)/crypto/ec/ec_oct.c + $(OPENSSL_PATH)/crypto/ec/ec_pmeth.c + $(OPENSSL_PATH)/crypto/ec/ec_print.c + $(OPENSSL_PATH)/crypto/ec/ecdh_kdf.c + $(OPENSSL_PATH)/crypto/ec/ecdh_ossl.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_ossl.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_sign.c + $(OPENSSL_PATH)/crypto/ec/ecdsa_vrf.c + $(OPENSSL_PATH)/crypto/ec/eck_prn.c + $(OPENSSL_PATH)/crypto/ec/ecp_mont.c + $(OPENSSL_PATH)/crypto/ec/ecp_nist.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp224.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp256.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistp521.c + $(OPENSSL_PATH)/crypto/ec/ecp_nistputil.c + $(OPENSSL_PATH)/crypto/ec/ecp_oct.c + $(OPENSSL_PATH)/crypto/ec/ecp_smpl.c + $(OPENSSL_PATH)/crypto/ec/ecx_meth.c $(OPENSSL_PATH)/crypto/err/err.c $(OPENSSL_PATH)/crypto/err/err_prn.c $(OPENSSL_PATH)/crypto/evp/bio_b64.c @@ -384,6 +421,10 @@ $(OPENSSL_PATH)/crypto/siphash/siphash.c $(OPENSSL_PATH)/crypto/siphash/siphash_ameth.c $(OPENSSL_PATH)/crypto/siphash/siphash_pmeth.c + $(OPENSSL_PATH)/crypto/sm2/sm2_crypt.c + $(OPENSSL_PATH)/crypto/sm2/sm2_err.c + $(OPENSSL_PATH)/crypto/sm2/sm2_pmeth.c + $(OPENSSL_PATH)/crypto/sm2/sm2_sign.c $(OPENSSL_PATH)/crypto/sm3/m_sm3.c $(OPENSSL_PATH)/crypto/sm3/sm3.c $(OPENSSL_PATH)/crypto/sm4/sm4.c @@ -496,6 +537,15 @@ $(OPENSSL_PATH)/crypto/conf/conf_local.h $(OPENSSL_PATH)/crypto/dh/dh_local.h $(OPENSSL_PATH)/crypto/dso/dso_local.h + $(OPENSSL_PATH)/crypto/ec/ec_local.h + $(OPENSSL_PATH)/crypto/ec/curve448/curve448_local.h + $(OPENSSL_PATH)/crypto/ec/curve448/curve448utils.h + $(OPENSSL_PATH)/crypto/ec/curve448/ed448.h + $(OPENSSL_PATH)/crypto/ec/curve448/field.h + $(OPENSSL_PATH)/crypto/ec/curve448/point_448.h + $(OPENSSL_PATH)/crypto/ec/curve448/word.h + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/arch_intrinsics.h + $(OPENSSL_PATH)/crypto/ec/curve448/arch_32/f_impl.h $(OPENSSL_PATH)/crypto/evp/evp_local.h $(OPENSSL_PATH)/crypto/hmac/hmac_local.h $(OPENSSL_PATH)/crypto/lhash/lhash_local.h diff --git CryptoPkg/Library/OpensslLib/openssl CryptoPkg/Library/OpensslLib/openssl --- CryptoPkg/Library/OpensslLib/openssl +++ CryptoPkg/Library/OpensslLib/openssl @@ -1 +1 @@ -Subproject commit e2e09d9fba1187f8d6aafaa34d4172f56f1ffb72 +Subproject commit e2e09d9fba1187f8d6aafaa34d4172f56f1ffb72-dirty diff --git CryptoPkg/Library/OpensslLib/process_files.pl CryptoPkg/Library/OpensslLib/process_files.pl index 57ce195394..baf7ba2881 100755 --- CryptoPkg/Library/OpensslLib/process_files.pl +++ CryptoPkg/Library/OpensslLib/process_files.pl @@ -9,6 +9,13 @@ # do not need to do this, since the results are stored in the EDK2 # git repository for them. # +# (C) Copyright 2019-2020 Hewlett Packard Enterprise Development LP<BR> +# This software contains information confidential and proprietary to +# Hewlett Packard Enterprise. It shall not be reproduced in whole or in part, +# or transferred to other documents, or disclosed to third parties, or used +# for any purpose other than that for which it was obtained without the prior +# written consent of Hewlett Packard Enterprise. +# use strict; use Cwd; use File::Copy; @@ -66,7 +73,9 @@ BEGIN { "no-dgram", "no-dsa", "no-dynamic-engine", - "no-ec", + #*HP_ISS: StartRemove + #"no-ec", + #*HP_ISS: EndRemove "no-ec2m", "no-engine", "no-err", diff --git CryptoPkg/Library/TlsLib/TlsConfig.c CryptoPkg/Library/TlsLib/TlsConfig.c index 307eb57896..26aea4571e 100644 --- CryptoPkg/Library/TlsLib/TlsConfig.c +++ CryptoPkg/Library/TlsLib/TlsConfig.c @@ -5,6 +5,13 @@ Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.<BR> (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR> SPDX-License-Identifier: BSD-2-Clause-Patent +(C) Copyright 2016-2020 Hewlett Packard Enterprise Development LP<BR> +This software contains information confidential and proprietary to +Hewlett Packard Enterprise. It shall not be reproduced in whole or in part, +or transferred to other documents, or disclosed to third parties, or used +for any purpose other than that for which it was obtained without the prior +written consent of Hewlett Packard Enterprise. + **/ #include "InternalTlsLib.h" @@ -62,6 +69,16 @@ STATIC CONST TLS_CIPHER_MAPPING TlsCipherMappingTable[] = { MAP ( 0x0068, "DH-DSS-AES256-SHA256" ), /// TLS_DH_DSS_WITH_AES_256_CBC_SHA256 MAP ( 0x0069, "DH-RSA-AES256-SHA256" ), /// TLS_DH_RSA_WITH_AES_256_CBC_SHA256 MAP ( 0x006B, "DHE-RSA-AES256-SHA256" ), /// TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 +//*HP_ISS_TLS_HPE_CIPHER_ADD: START + // + // TLS1.3 cipher suites (https://tools.ietf.org/html/rfc8446 pg.133) + // + MAP ( 0x1301, "TLS_AES_128_GCM_SHA256" ), /// TLS_AES_128_GCM_SHA256 + MAP ( 0x1302, "TLS_AES_256_GCM_SHA384" ), /// TLS_AES_256_GCM_SHA384 + MAP ( 0x1303, "TLS_CHACHA20_POLY1305_SHA256"), /// TLS_CHACHA20_POLY1305_SHA256 + MAP ( 0x1304, "TLS_AES_128_CCM_SHA256" ), /// TLS_AES_128_CCM_SHA256 + MAP ( 0x1305, "TLS_AES_128_CCM_8_SHA256" ), /// TLS_AES_128_CCM_8_SHA256 +//*HP_ISS_TLS_HPE_CIPHER_ADD: END }; /** @@ -169,6 +186,17 @@ TlsSetVersion ( SSL_set_min_proto_version (TlsConn->Ssl, TLS1_2_VERSION); SSL_set_max_proto_version (TlsConn->Ssl, TLS1_2_VERSION); break; + + //*HP_ISS_TLS1.3: Start + case TLS1_3_VERSION: + // + // TLS 1.3 + // + SSL_set_min_proto_version (TlsConn->Ssl, TLS1_3_VERSION); + SSL_set_max_proto_version (TlsConn->Ssl, TLS1_3_VERSION); + break; + //*HP_ISS_TLS1.3: End + default: // // Unsupported Protocol Version @@ -259,6 +287,10 @@ TlsSetCipherList ( CONST TLS_CIPHER_MAPPING *Mapping; CHAR8 *CipherString; CHAR8 *CipherStringPosition; + //*HP_ISS_TLS1.3: Start + INT32 Tls12Status; + INT32 Tls13Status; + //*HP_ISS_TLS1.3: End TlsConn = (TLS_CONNECTION *) Tls; if (TlsConn == NULL || TlsConn->Ssl == NULL || CipherId == NULL) { @@ -400,13 +432,18 @@ TlsSetCipherList ( ASSERT (CipherStringPosition == CipherString + CipherStringSize); ); + //*HP_ISS_TLS1.3: Start // // Sets the ciphers for use by the Tls object. + // TLS1.3 and 1.2 don't share the same cihper set API // - if (SSL_set_cipher_list (TlsConn->Ssl, CipherString) <= 0) { + Tls13Status = SSL_set_cipher_list (TlsConn->Ssl, CipherString); + Tls12Status = SSL_set_ciphersuites (TlsConn->Ssl, CipherString); + if (Tls12Status <= 0 && Tls13Status <= 0) { Status = EFI_UNSUPPORTED; goto FreeCipherString; } + //*HP_ISS_TLS1.3: End Status = EFI_SUCCESS; diff --git NetworkPkg/HttpDxe/HttpsSupport.c NetworkPkg/HttpDxe/HttpsSupport.c index 7e0bf85c3c..cf66dc44ef 100644 --- NetworkPkg/HttpDxe/HttpsSupport.c +++ NetworkPkg/HttpDxe/HttpsSupport.c @@ -5,6 +5,13 @@ Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.<BR> (C) Copyright 2016 Hewlett Packard Enterprise Development LP<BR> SPDX-License-Identifier: BSD-2-Clause-Patent +(C) Copyright 2016-2020 Hewlett Packard Enterprise Development LP<BR> +This software contains information confidential and proprietary to +Hewlett Packard Enterprise. It shall not be reproduced in whole or in part, +or transferred to other documents, or disclosed to third parties, or used +for any purpose other than that for which it was obtained without the prior +written consent of Hewlett Packard Enterprise. + **/ #include "HttpDriver.h" @@ -1049,7 +1056,9 @@ TlsReceiveOnePdu ( (RecordHeader.Version.Major == 0x03) && /// Major versions are same. (RecordHeader.Version.Minor == TLS10_PROTOCOL_VERSION_MINOR || RecordHeader.Version.Minor ==TLS11_PROTOCOL_VERSION_MINOR || - RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + //*HP_ISS_TLS1.3 RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR || //*HP_ISS_TLS1.3 + RecordHeader.Version.Minor == TLS13_PROTOCOL_VERSION_MINOR) //*HP_ISS_TLS1.3 ) { InsertTailList (NbufList, &PduHdr->List); } else { @@ -1667,7 +1676,9 @@ HttpsReceive ( (RecordHeader.Version.Major == 0x03) && (RecordHeader.Version.Minor == TLS10_PROTOCOL_VERSION_MINOR || RecordHeader.Version.Minor == TLS11_PROTOCOL_VERSION_MINOR || - RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + //*HP_ISS_TLS1.3 RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR || //*HP_ISS_TLS1.3 + RecordHeader.Version.Minor == TLS13_PROTOCOL_VERSION_MINOR) //*HP_ISS_TLS1.3 ) { // // Decrypt Packet. @@ -1773,7 +1784,9 @@ HttpsReceive ( (RecordHeader.Version.Major == 0x03) && (RecordHeader.Version.Minor == TLS10_PROTOCOL_VERSION_MINOR || RecordHeader.Version.Minor == TLS11_PROTOCOL_VERSION_MINOR || - RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + //*HP_ISS_TLS1.3 RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR) + RecordHeader.Version.Minor == TLS12_PROTOCOL_VERSION_MINOR || //*HP_ISS_TLS1.3 + RecordHeader.Version.Minor == TLS13_PROTOCOL_VERSION_MINOR) //*HP_ISS_TLS1.3 ) { BufferOutSize = DEF_BUF_LEN; BufferOut = AllocateZeroPool (BufferOutSize); [-- Attachment #3: process_openssl.txt --] [-- Type: text/plain, Size: 2061 bytes --] Matthew@DESKTOP-JSHK0AI MINGW64 /c/code/edk2/CryptoPkg/Library/OpensslLib $ ./process_files.pl openssl ***** Deprecated options: no-ui Configuring OpenSSL version 1.1.1g (0x1010107fL) for UEFI ============================== WARNING =============================== You have selected the --with-rand-seed=none option, which effectively disables automatic reseeding of the OpenSSL random generator. All operations depending on the random generator such as creating keys will not work unless the random generator is seeded manually by the application. Please read the 'Note on random number generation' section in the INSTALL instructions and the RAND_DRBG(7) manual page for more details. ============================== WARNING =============================== Creating configdata.pm Creating Makefile ********************************************************************** *** *** *** OpenSSL has been successfully configured *** *** *** *** If you encounter a problem while building, please open an *** *** issue on GitHub <https://github.com/openssl/openssl/issues> *** *** and include the output from the following command: *** *** *** *** perl configdata.pm --dump *** *** *** *** (If you are new to OpenSSL, you might want to consult the *** *** 'Troubleshooting' section in the INSTALL file first) *** *** *** ********************************************************************** --> Updating OpensslLib.inf ... Done! --> Updating OpensslLibCrypto.inf ... Done! --> Duplicating opensslconf.h into Include/openssl ... Done! --> Duplicating dso_conf.h into Include/crypto ... Done! Processing Files Done! [-- Attachment #4: openssl.patch --] [-- Type: application/octet-stream, Size: 1988 bytes --] diff --git ssl/ssl_ciph.c ssl/ssl_ciph.c index 735a483c64..74f02de695 100644 --- ssl/ssl_ciph.c +++ ssl/ssl_ciph.c @@ -1292,7 +1292,8 @@ static int ciphersuite_cb(const char *elem, int len, void *arg) cipher = ssl3_get_cipher_by_std_name(name); if (cipher == NULL) { SSLerr(SSL_F_CIPHERSUITE_CB, SSL_R_NO_CIPHER_MATCH); - return 0; + /* Ciphersuite not found but return 1 to parse rest of the list */ + return 1; } if (!sk_SSL_CIPHER_push(ciphersuites, cipher)) { @@ -1312,7 +1313,8 @@ static __owur int set_ciphersuites(STACK_OF(SSL_CIPHER) **currciphers, const cha /* Parse the list. We explicitly allow an empty list */ if (*str != '\0' - && !CONF_parse_list(str, ':', 1, ciphersuite_cb, newciphers)) { + && (CONF_parse_list(str, ':', 1, ciphersuite_cb, newciphers) <= 0 + || sk_SSL_CIPHER_num(newciphers) == 0 )) { sk_SSL_CIPHER_free(newciphers); return 0; } @@ -1599,8 +1601,19 @@ STACK_OF(SSL_CIPHER) *ssl_create_cipher_list(const SSL_METHOD *ssl_method, /* Add TLSv1.3 ciphers first - we always prefer those if possible */ for (i = 0; i < sk_SSL_CIPHER_num(tls13_ciphersuites); i++) { - if (!sk_SSL_CIPHER_push(cipherstack, - sk_SSL_CIPHER_value(tls13_ciphersuites, i))) { + const SSL_CIPHER *sslc = sk_SSL_CIPHER_value(tls13_ciphersuites, i); + + /* Don't include any TLSv1.3 ciphers that are disabled */ + if ((sslc->algorithm_enc & disabled_enc) != 0 + || (ssl_cipher_table_mac[sslc->algorithm2 + & SSL_HANDSHAKE_MAC_MASK].mask + & disabled_mac_mask) != 0) { + sk_SSL_CIPHER_delete(tls13_ciphersuites, i); + i--; + continue; + } + + if (!sk_SSL_CIPHER_push(cipherstack, sslc)) { sk_SSL_CIPHER_free(cipherstack); return NULL; } ^ permalink raw reply related [flat|nested] 17+ messages in thread
[parent not found: <162A80E91C03CB2F.12108@groups.io>]
* 回覆: [edk2-devel] Propose on enabling TLSv1.3 [not found] ` <162A80E91C03CB2F.12108@groups.io> @ 2020-08-19 23:16 ` Huang, Matthew (HPS SW) 2020-08-20 0:50 ` Zhiguang Liu 2020-09-04 2:32 ` Zhiguang Liu 0 siblings, 2 replies; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-08-19 23:16 UTC (permalink / raw) To: devel@edk2.groups.io, Huang, Matthew (HPS SW), zhiguang.liu@intel.com Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 6037 bytes --] Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io <devel@edk2.groups.io> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; zhiguang.liu@intel.com 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 17562 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-08-19 23:16 ` Huang, Matthew (HPS SW) @ 2020-08-20 0:50 ` Zhiguang Liu 2020-09-04 2:32 ` Zhiguang Liu 1 sibling, 0 replies; 17+ messages in thread From: Zhiguang Liu @ 2020-08-20 0:50 UTC (permalink / raw) To: Huang, Matthew (HPS SW), devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW) [-- Attachment #1: Type: text/plain, Size: 6777 bytes --] Hi Matthew, Sorry for the slow response. Please allow me some time to verify this change. Anyone who is interested in the topic are welcomed to give comments, thanks😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; Liu, Zhiguang <zhiguang.liu@intel.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 20168 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-08-19 23:16 ` Huang, Matthew (HPS SW) 2020-08-20 0:50 ` Zhiguang Liu @ 2020-09-04 2:32 ` Zhiguang Liu 2020-09-07 2:37 ` Zhiguang Liu 2020-11-19 2:07 ` Zhiguang Liu 1 sibling, 2 replies; 17+ messages in thread From: Zhiguang Liu @ 2020-09-04 2:32 UTC (permalink / raw) To: Huang, Matthew (HPS SW), devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com [-- Attachment #1: Type: text/plain, Size: 7080 bytes --] Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; Liu, Zhiguang <zhiguang.liu@intel.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 24935 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-09-04 2:32 ` Zhiguang Liu @ 2020-09-07 2:37 ` Zhiguang Liu 2020-09-07 5:29 ` Yao, Jiewen 2020-11-19 2:07 ` Zhiguang Liu 1 sibling, 1 reply; 17+ messages in thread From: Zhiguang Liu @ 2020-09-07 2:37 UTC (permalink / raw) To: Huang, Matthew (HPS SW), devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Liming Gao, Kinney, Michael D, Yao, Jiewen, Wang, Jian J [-- Attachment #1: Type: text/plain, Size: 8190 bytes --] Hi Matthew, When compiling in IA32 architecture using VS2017, build error happens: OpensslLib.lib(curve25519.obj) : error LNK2001: unresolved external symbol __allmul I think this is because there is multiplication of int64 in curve25519, which is a new added algorithm for tls 1.3. I suggest adding a nasm file to implement allmul fuction in CryptoPkg\Library\IntrinsicLib\Ia32\ Including CryptoPkg and MdePkg maintainers to give more comments. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 27953 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-09-07 2:37 ` Zhiguang Liu @ 2020-09-07 5:29 ` Yao, Jiewen 2020-09-07 5:39 ` Huang, Matthew (HPS SW) 0 siblings, 1 reply; 17+ messages in thread From: Yao, Jiewen @ 2020-09-07 5:29 UTC (permalink / raw) To: Liu, Zhiguang, Huang, Matthew (HPS SW), devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Liming Gao, Kinney, Michael D, Wang, Jian J [-- Attachment #1: Type: text/plain, Size: 9126 bytes --] adding a nasm file to implement allmul fuction in CryptoPkg\Library\IntrinsicLib\Ia32\ Acked-by: Jiewen Yao <Jiewen.yao@intel.com> From: Liu, Zhiguang <zhiguang.liu@intel.com> Sent: Monday, September 7, 2020 10:37 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com; Liming Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, When compiling in IA32 architecture using VS2017, build error happens: OpensslLib.lib(curve25519.obj) : error LNK2001: unresolved external symbol __allmul I think this is because there is multiplication of int64 in curve25519, which is a new added algorithm for tls 1.3. I suggest adding a nasm file to implement allmul fuction in CryptoPkg\Library\IntrinsicLib\Ia32\ Including CryptoPkg and MdePkg maintainers to give more comments. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 29866 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-09-07 5:29 ` Yao, Jiewen @ 2020-09-07 5:39 ` Huang, Matthew (HPS SW) 0 siblings, 0 replies; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-09-07 5:39 UTC (permalink / raw) To: Yao, Jiewen, Liu, Zhiguang, devel@edk2.groups.io Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Liming Gao, Kinney, Michael D, Wang, Jian J [-- Attachment #1: Type: text/plain, Size: 10211 bytes --] Thank you all so much, and if there’s any problem please let me know, thanks again. Matthew From: Yao, Jiewen <jiewen.yao@intel.com> Sent: Monday, September 7, 2020 1:29 PM To: Liu, Zhiguang <zhiguang.liu@intel.com>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com; Liming Gao <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>; Wang, Jian J <jian.j.wang@intel.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 adding a nasm file to implement allmul fuction in CryptoPkg\Library\IntrinsicLib\Ia32\ Acked-by: Jiewen Yao <Jiewen.yao@intel.com<mailto:Jiewen.yao@intel.com>> From: Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Sent: Monday, September 7, 2020 10:37 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com>; Liming Gao <gaoliming@byosoft.com.cn<mailto:gaoliming@byosoft.com.cn>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, When compiling in IA32 architecture using VS2017, build error happens: OpensslLib.lib(curve25519.obj) : error LNK2001: unresolved external symbol __allmul I think this is because there is multiplication of int64 in curve25519, which is a new added algorithm for tls 1.3. I suggest adding a nasm file to implement allmul fuction in CryptoPkg\Library\IntrinsicLib\Ia32\ Including CryptoPkg and MdePkg maintainers to give more comments. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 37038 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-09-04 2:32 ` Zhiguang Liu 2020-09-07 2:37 ` Zhiguang Liu @ 2020-11-19 2:07 ` Zhiguang Liu 2020-11-19 9:34 ` Laszlo Ersek 2020-11-25 5:12 ` Huang, Matthew (HPS SW) 1 sibling, 2 replies; 17+ messages in thread From: Zhiguang Liu @ 2020-11-19 2:07 UTC (permalink / raw) To: Huang, Matthew (HPS SW), devel@edk2.groups.io, Yao, Jiewen, Wang, Jian J, maciej.rabeda@linux.intel.com, lersek@redhat.com, Wu, Jiaxin, Fu, Siyuan, Xu, Min M, Zhang, Qi1, Kumar, Rahul1 Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Tian, Hot, Madhavi Sinha, Fnu [-- Attachment #1: Type: text/plain, Size: 11032 bytes --] Hi all, I did some research about TLS v1.3 and here is my suggestion. I want to first collect information if we should continue to support TLS v1.1 or below. I personally suggest stopping support TLS v1.1 or below, for this is a trend. The first suggestion is about TLS version configuration. The supported TLS version should be a range not just a fixed value. For example, a TLS version from 1.2 to 1.3 are both accepted. However, there is not a direct UEFI API to set TLS version as a range. SetSessionData method in EFI_TLS_PROTOCOL will set the maximum and minimum TLS version as a same value. I have two solutions about this issue and want to collect feedback. Firstly, use a PCD to set the minimum TLS version in TlsDxe driver’s entry point. Like: TlsCtxNew (PCD_Minimum_version_major, PCD_ Minimum_version_minor); Then the accepted TLS version will be from PCD_Minimum_version to 1.3 Secondly, use loop to try different TLS versions, which can be implemented in platform side. Like: TLSVersionList = [1.3, 1.2, 1.1]; for (int i=0; i<len(TLSVersionList); i++) { SetSessionData(EfiTlsVersion, TLSVersionList[i]); // then, try to connect, if it works, break } The second comment is about how to set Cipher list. We can now change the gEdkiiHttpTlsCipherListGuid variable to change cipher list. The same variable and API is used from TLS v1.0 to TLS v1.2 However, TLS v1.3 has a different API and totally different cipher list parameters. Below is the comparison: SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) The input cipher suite list must include at least one available cipher suite for TLSv1.2 and below. SSL_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites The input cipher suite list must only include available cipher suite for TLSv1.3. I suggest introducing another table TlsV13CipherMappingTable to store the cipher list suit for TLS v1.3. Before calling SSL_set_ciphersuites(), use the mapping table to filter the cipher list, only remain the available ones. In this way, we can save all the cipher lists and cipher suites for TLS 1.3 and TLS v1.2 or below in one same variable. And before calling API to set cipher list, use the corresponding mapping table to filter. Also, for current TlsCipherMappingTable used for TLS v1.2 or below, I think the below cipher list are all insecure for they use MD5 and SHA. We should remove them. MAP ( 0x0001, "NULL-MD5" ), MAP ( 0x0002, "NULL-SHA" ), MAP ( 0x0004, "RC4-MD5" ), MAP ( 0x0005, "RC4-SHA" ), MAP ( 0x000A, "DES-CBC3-SHA" ), MAP ( 0x0016, "DHE-RSA-DES-CBC3-SHA" ), MAP ( 0x002F, "AES128-SHA" ), MAP ( 0x0030, "DH-DSS-AES128-SHA" ), MAP ( 0x0031, "DH-RSA-AES128-SHA" ), MAP ( 0x0033, "DHE-RSA-AES128-SHA" ), MAP ( 0x0035, "AES256-SHA" ), MAP ( 0x0036, "DH-DSS-AES256-SHA" ), MAP ( 0x0037, "DH-RSA-AES256-SHA" ), MAP ( 0x0039, "DHE-RSA-AES256-SHA" ), And for TLS v1.3, I suggest we enable the following cipher suite. 1. TLS_AES_256_GCM_SHA384 2. TLS_AES_128_GCM_SHA256 3. TLS_AES_128_CCM_SHA256 4. TLS_CHACHA20_POLY1305_SHA256 Please correct me if I am wrong. Any comments are welcomed. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 40648 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-11-19 2:07 ` Zhiguang Liu @ 2020-11-19 9:34 ` Laszlo Ersek 2020-11-25 5:12 ` Huang, Matthew (HPS SW) 1 sibling, 0 replies; 17+ messages in thread From: Laszlo Ersek @ 2020-11-19 9:34 UTC (permalink / raw) To: Liu, Zhiguang, Huang, Matthew (HPS SW), devel@edk2.groups.io, Yao, Jiewen, Wang, Jian J, maciej.rabeda@linux.intel.com, Wu, Jiaxin, Fu, Siyuan, Xu, Min M, Zhang, Qi1, Kumar, Rahul1 Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Tian, Hot, Madhavi Sinha, Fnu, Ard Biesheuvel (ARM address), Nikos Mavrogiannopoulos, Tomas Mraz, Philippe Mathieu-Daudé On 11/19/20 03:07, Liu, Zhiguang wrote: > Hi all, > > I did some research about TLS v1.3 and here is my suggestion. Related BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2424 > > I want to first collect information if we should continue to support > TLS v1.1 or below. > I personally suggest stopping support TLS v1.1 or below, for this is a > trend. > > The first suggestion is about TLS version configuration. > The supported TLS version should be a range not just a fixed value. > For example, a TLS version from 1.2 to 1.3 are both accepted. > However, there is not a direct UEFI API to set TLS version as a range. > SetSessionData method in EFI_TLS_PROTOCOL will set the maximum and > minimum TLS version as a same value. > I have two solutions about this issue and want to collect feedback. > > Firstly, use a PCD to set the minimum TLS version in TlsDxe > driver\x19s entry point. Like: > TlsCtxNew (PCD_Minimum_version_major, PCD_ Minimum_version_minor); > Then the accepted TLS version will be from PCD_Minimum_version to 1.3 > > Secondly, use loop to try different TLS versions, which can be > implemented in platform side. Like: > TLSVersionList = [1.3, 1.2, 1.1]; > for (int i=0; i<len(TLSVersionList); i++) { > SetSessionData(EfiTlsVersion, TLSVersionList[i]); > // then, try to connect, if it works, break > } > > > The second comment is about how to set Cipher list. > We can now change the gEdkiiHttpTlsCipherListGuid variable to change > cipher list. > The same variable and API is used from TLS v1.0 to TLS v1.2 > However, TLS v1.3 has a different API and totally different cipher > list parameters. > Below is the comparison: > SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) > The input cipher suite list must include at least one available cipher > suite for TLSv1.2 and below. > SSL_set_ciphersuites() is used to configure the available TLSv1.3 > ciphersuites > The input cipher suite list must only include available cipher suite > for TLSv1.3. > > I suggest introducing another table TlsV13CipherMappingTable to store > the cipher list suit for TLS v1.3. > Before calling SSL_set_ciphersuites(), use the mapping table to filter > the cipher list, only remain the available ones. > In this way, we can save all the cipher lists and cipher suites for > TLS 1.3 and TLS v1.2 or below in one same variable. > And before calling API to set cipher list, use the corresponding > mapping table to filter. > > Also, for current TlsCipherMappingTable used for TLS v1.2 or below, I > think the below cipher list are all insecure for they use MD5 and SHA. > We should remove them. > MAP ( 0x0001, "NULL-MD5" ), > MAP ( 0x0002, "NULL-SHA" ), > MAP ( 0x0004, "RC4-MD5" ), > MAP ( 0x0005, "RC4-SHA" ), > MAP ( 0x000A, "DES-CBC3-SHA" ), > MAP ( 0x0016, "DHE-RSA-DES-CBC3-SHA" ), > MAP ( 0x002F, "AES128-SHA" ), > MAP ( 0x0030, "DH-DSS-AES128-SHA" ), > MAP ( 0x0031, "DH-RSA-AES128-SHA" ), > MAP ( 0x0033, "DHE-RSA-AES128-SHA" ), > MAP ( 0x0035, "AES256-SHA" ), > MAP ( 0x0036, "DH-DSS-AES256-SHA" ), > MAP ( 0x0037, "DH-RSA-AES256-SHA" ), > MAP ( 0x0039, "DHE-RSA-AES256-SHA" ), > > And for TLS v1.3, I suggest we enable the following cipher suite. > > 1. TLS_AES_256_GCM_SHA384 > 2. TLS_AES_128_GCM_SHA256 > 3. TLS_AES_128_CCM_SHA256 > 4. TLS_CHACHA20_POLY1305_SHA256 > > Please correct me if I am wrong. Any comments are welcomed. I'm not a crypto person, so please bear with me. At Red Hat, we discussed TLSv1.3 in edk2 in the year 2018. In particular, we discussed what UEFI (the spec) and edk2 (the reference implementation) would need, for honoring what we call the "crypto policy", with TLSv1.3. After lots of discussions (which was basically a "learning from zero" experience for me), I tried to summarize my then-understanding at: https://bugzilla.redhat.com/show_bug.cgi?id=1559564#c17 Let me re-hash that here, in order to remove the OVMF-specific bits, plus it's going to be easier for others to respond here in-line. There are five aspects of TLSv1.3 that we would like to control. These are: (a) TLS protocol version. (b) Acceptable ciphers. (c) Acceptable groups (secp256r1/ffdhe etc). (d) Acceptable signature algorithms (rsa-sha1, rsa-sha256, ...). (e) Minimum acceptable DH parameters (for <tls1.2). For each of these, it needs to be investigated whether the UEFI spec is already flexible enough to express the particular configuration trait. If so, then the question is whether edk2 implements that configuration interface already. (a) TLS protocol version: - Currently, the UEFI spec allows for a single version setting. - For accepting a version range (or set), spec changes don't look necessary. The set of desired TLS version should be possible to pass via the following interface: - EFI_TLS_PROTOCOL.SetSessionData() - DataType=EfiTlsExtensionData - ExtensionType=43 ("supported_versions"): https://tools.ietf.org/html/rfc8446#section-4.2.1 - Edk2 implementation: A PCD doesn't appear necessary. Edk2 does not implement DataType=EfiTlsExtensionData though, at the moment ("Status = EFI_UNSUPPORTED"). Suggestion (in accordance with the spec interface): #pragma pack (1) typedef struct { UINT16 ExtensionType; // this is where // the protocol // user would put // value 43 UINT16 Length; UINT8 Data[1]; // encode TLS // ProtocolVersion // (UINT16) values, // likely as // little-endian } EFI_TLS_EXTENSION; #pragma pack () Use of this interface would supersede / conflict with EfiTlsVersion. In other words, using this facility after setting EfiTlsVersion would fail, and vice versa. The return value could be EFI_ALREADY_STARTED. Multiple TCP connections should not be created, especially not driven from the platform side -- OpenSSL should be pre-configured with the acceptable version list, and negotiation should occur internally to TLS, using just one TCP socket. (b) Acceptable ciphers - The UEFI spec allows for an array of cipher IDs (EFI_TLS_CIPHER), which seems suitable wrt. TLSv1.3 as well. - Edk2 implements the interface already. - The edk2 implementation is not universally loved. There are (or have been) mismatches between the set of ciphers we include in the OpensslLib INF files and the "cipher suite filtering table" in the C code. Also, some contributors either dislike the specific content of the filter table, or even the fact that edk2 attempts to perform any kind of filtering there -- if a protocol client requests a particular cipher, there's an argument that the edk2 core should not judge whether that's a reasonable request or not. Under this idea the whole edk2-internal filtering should be removed (sane defaults should not be removed though). (c) Acceptable groups (secp256r1/ffdhe etc) - Regarding the spec, this config property should map to the following (no new interface needed): - EFI_TLS_PROTOCOL.SetSessionData() - DataType=EfiTlsExtensionData - ExtensionType=10 ("supported_groups"): https://tools.ietf.org/html/rfc8446#section-4.2.7 - Edk2 implementation: none currently; suggested: #pragma pack (1) typedef struct { UINT16 ExtensionType; // this is where // the protocol // user would put // value 10 UINT16 Length; UINT8 Data[1]; // encode TLS // NamedGroup (UINT16) // values, likely as // little-endian } EFI_TLS_EXTENSION; #pragma pack () (d) Acceptable signature algorithms (rsa-sha1, rsa-sha256, ...) Same status as seen under (a) and (c), only with ExtensionType=13/50 ("signature_algorithms" / "signature_algorithms_cert"): https://tools.ietf.org/html/rfc8446#section-4.2.3 Suggested implementation (in accordance with the spec interface): #pragma pack (1) typedef struct { UINT16 ExtensionType; // this is where // the protocol // user would put // value 10 or 50 UINT16 Length; UINT8 Data[1]; // encode TLS // SignatureScheme // (UINT16) values, // likely as // little-endian } EFI_TLS_EXTENSION; #pragma pack () (e) Minimum acceptable DH parameters (for <tls1.2) - UEFI spec interface: - key length is inexpressible - permitted groups map to (c) - no changes required because (at least from my notes from the last discussion at RH) expressing the permitted groups through (c) is sufficient - Edk2 implementation: none. However, a TLS protocol client can get around this limitation by forbidding such TLS cipher suites altogether that use DH key exchange (so DH parameters won't matter), via (b) / (c). So, if I remember correctly our perspective at Red Hat, - we'd need no spec changes, - we'd need support for DataType=EfiTlsExtensionData in EFI_TLS_PROTOCOL.SetSessionData(), wherein ExtensionType values 43, 10, and 13/50 should be propagated to OpenSSL, with their corresponding UINT16 (ProtocolVersion / NamedGroup / SignatureScheme) arrays encoded in EFI_TLS_EXTENSION.Length and EFI_TLS_EXTENSION.Data, - the cipher suite filtering that's internal to edk2 remains dubious -- minimally the INF file contents (OpenSSL source file list) should be synchronized with the filtering table(s). ... I'm fully aware this is not overly helpful, I'm just trying to bridge the gap between our crypto experts (who haven't delved too much into UEFI/edk2) and UEFI/edk2, with myself not being a crypto guy at all. Thanks Laszlo ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-11-19 2:07 ` Zhiguang Liu 2020-11-19 9:34 ` Laszlo Ersek @ 2020-11-25 5:12 ` Huang, Matthew (HPS SW) 2020-11-25 7:27 ` Zhiguang Liu 1 sibling, 1 reply; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-11-25 5:12 UTC (permalink / raw) To: Liu, Zhiguang, devel@edk2.groups.io, Yao, Jiewen, Wang, Jian J, maciej.rabeda@linux.intel.com, lersek@redhat.com, Wu, Jiaxin, Fu, Siyuan, Xu, Min M, Zhang, Qi1, Kumar, Rahul1 Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Tian, Hot, Madhavi Sinha, Fnu [-- Attachment #1: Type: text/plain, Size: 12916 bytes --] Hi Zhiguang: Agree that we should define a range type instead of assign a discrete value for TLS version, since TLS here we are talking about are client, it should be adapted by the server side without any problem if the handshake is properly executed. I’m okay with the separated tables handling TLSv12 & 13 respectively, but the variable name “HttpTlsCipherList” and GUID “gEdkiiHttpTlsCipherListGuid” can be confusing since the term “list” has the potential to mislead people to think that is a cipher list container for TLSv12. If we want to have the design to bind those two into one variable, maybe “HttpTlsCiphers” or “HttpTlsEnabledCiphers” would be a good start to thin out the spectrum. So about the TLSv13 portion, TLS-AES-128-CCM-SHA256 and TLS-AES-128-CCM-8-SHA256 are not recommended to be enabled, right? Matthew. From: Liu, Zhiguang <zhiguang.liu@intel.com> Sent: Thursday, November 19, 2020 10:08 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; maciej.rabeda@linux.intel.com; lersek@redhat.com; Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Xu, Min M <min.m.xu@intel.com>; Zhang, Qi1 <qi1.zhang@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com; Tian, Hot <hot.tian@intel.com>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi all, I did some research about TLS v1.3 and here is my suggestion. I want to first collect information if we should continue to support TLS v1.1 or below. I personally suggest stopping support TLS v1.1 or below, for this is a trend. The first suggestion is about TLS version configuration. The supported TLS version should be a range not just a fixed value. For example, a TLS version from 1.2 to 1.3 are both accepted. However, there is not a direct UEFI API to set TLS version as a range. SetSessionData method in EFI_TLS_PROTOCOL will set the maximum and minimum TLS version as a same value. I have two solutions about this issue and want to collect feedback. Firstly, use a PCD to set the minimum TLS version in TlsDxe driver’s entry point. Like: TlsCtxNew (PCD_Minimum_version_major, PCD_ Minimum_version_minor); Then the accepted TLS version will be from PCD_Minimum_version to 1.3 Secondly, use loop to try different TLS versions, which can be implemented in platform side. Like: TLSVersionList = [1.3, 1.2, 1.1]; for (int i=0; i<len(TLSVersionList); i++) { SetSessionData(EfiTlsVersion, TLSVersionList[i]); // then, try to connect, if it works, break } The second comment is about how to set Cipher list. We can now change the gEdkiiHttpTlsCipherListGuid variable to change cipher list. The same variable and API is used from TLS v1.0 to TLS v1.2 However, TLS v1.3 has a different API and totally different cipher list parameters. Below is the comparison: SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) The input cipher suite list must include at least one available cipher suite for TLSv1.2 and below. SSL_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites The input cipher suite list must only include available cipher suite for TLSv1.3. I suggest introducing another table TlsV13CipherMappingTable to store the cipher list suit for TLS v1.3. Before calling SSL_set_ciphersuites(), use the mapping table to filter the cipher list, only remain the available ones. In this way, we can save all the cipher lists and cipher suites for TLS 1.3 and TLS v1.2 or below in one same variable. And before calling API to set cipher list, use the corresponding mapping table to filter. Also, for current TlsCipherMappingTable used for TLS v1.2 or below, I think the below cipher list are all insecure for they use MD5 and SHA. We should remove them. MAP ( 0x0001, "NULL-MD5" ), MAP ( 0x0002, "NULL-SHA" ), MAP ( 0x0004, "RC4-MD5" ), MAP ( 0x0005, "RC4-SHA" ), MAP ( 0x000A, "DES-CBC3-SHA" ), MAP ( 0x0016, "DHE-RSA-DES-CBC3-SHA" ), MAP ( 0x002F, "AES128-SHA" ), MAP ( 0x0030, "DH-DSS-AES128-SHA" ), MAP ( 0x0031, "DH-RSA-AES128-SHA" ), MAP ( 0x0033, "DHE-RSA-AES128-SHA" ), MAP ( 0x0035, "AES256-SHA" ), MAP ( 0x0036, "DH-DSS-AES256-SHA" ), MAP ( 0x0037, "DH-RSA-AES256-SHA" ), MAP ( 0x0039, "DHE-RSA-AES256-SHA" ), And for TLS v1.3, I suggest we enable the following cipher suite. 1. TLS_AES_256_GCM_SHA384 2. TLS_AES_128_GCM_SHA256 3. TLS_AES_128_CCM_SHA256 4. TLS_CHACHA20_POLY1305_SHA256 Please correct me if I am wrong. Any comments are welcomed. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 50092 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-11-25 5:12 ` Huang, Matthew (HPS SW) @ 2020-11-25 7:27 ` Zhiguang Liu 2020-12-03 0:24 ` Huang, Matthew (HPS SW) 0 siblings, 1 reply; 17+ messages in thread From: Zhiguang Liu @ 2020-11-25 7:27 UTC (permalink / raw) To: Huang, Matthew (HPS SW), devel@edk2.groups.io, Yao, Jiewen, Wang, Jian J, maciej.rabeda@linux.intel.com, lersek@redhat.com, Wu, Jiaxin, Fu, Siyuan, Xu, Min M, Zhang, Qi1, Kumar, Rahul1 Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Tian, Hot, Madhavi Sinha, Fnu [-- Attachment #1: Type: text/plain, Size: 15095 bytes --] Hi Matthew, Thanks for the response. I agree that this variable name “HttpTlsCipherList” and GUID “gEdkiiHttpTlsCipherListGuid” is confusing, but I am afraid renaming will break back-compatibility. Or we can define another variable and GUID like “HttpTlsCipherSuites” and “gEdkiiHttpTlsCipherSuitesGuid” to separately restore the cipher suite for TLS v1.3. We may need network package maintainer to make the decision. For the recommended cipher suites, TLS-AES-128-CCM-SHA256 is on my recommendation list. TLS-AES-128-CCM-8-SHA256 is identical to the TLS-AES-128-CCM-SHA256, except that it uses 8 octets, instead of the full 16 octets used by TLS-AES-128-CCM-SHA256. Therefore, TLS-AES-128-CCM-8-SHA256 is weaker and I recommend to not enable it. Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com> Sent: Wednesday, November 25, 2020 1:13 PM To: Liu, Zhiguang <zhiguang.liu@intel.com>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; maciej.rabeda@linux.intel.com; lersek@redhat.com; Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Xu, Min M <min.m.xu@intel.com>; Zhang, Qi1 <qi1.zhang@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com; Tian, Hot <hot.tian@intel.com>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Agree that we should define a range type instead of assign a discrete value for TLS version, since TLS here we are talking about are client, it should be adapted by the server side without any problem if the handshake is properly executed. I’m okay with the separated tables handling TLSv12 & 13 respectively, but the variable name “HttpTlsCipherList” and GUID “gEdkiiHttpTlsCipherListGuid” can be confusing since the term “list” has the potential to mislead people to think that is a cipher list container for TLSv12. If we want to have the design to bind those two into one variable, maybe “HttpTlsCiphers” or “HttpTlsEnabledCiphers” would be a good start to thin out the spectrum. So about the TLSv13 portion, TLS-AES-128-CCM-SHA256 and TLS-AES-128-CCM-8-SHA256 are not recommended to be enabled, right? Matthew. From: Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Sent: Thursday, November 19, 2020 10:08 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; lersek@redhat.com<mailto:lersek@redhat.com>; Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>; Xu, Min M <min.m.xu@intel.com<mailto:min.m.xu@intel.com>>; Zhang, Qi1 <qi1.zhang@intel.com<mailto:qi1.zhang@intel.com>>; Kumar, Rahul1 <rahul1.kumar@intel.com<mailto:rahul1.kumar@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com>; Tian, Hot <hot.tian@intel.com<mailto:hot.tian@intel.com>>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com<mailto:fnu.madhavi.sinha@intel.com>> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi all, I did some research about TLS v1.3 and here is my suggestion. I want to first collect information if we should continue to support TLS v1.1 or below. I personally suggest stopping support TLS v1.1 or below, for this is a trend. The first suggestion is about TLS version configuration. The supported TLS version should be a range not just a fixed value. For example, a TLS version from 1.2 to 1.3 are both accepted. However, there is not a direct UEFI API to set TLS version as a range. SetSessionData method in EFI_TLS_PROTOCOL will set the maximum and minimum TLS version as a same value. I have two solutions about this issue and want to collect feedback. Firstly, use a PCD to set the minimum TLS version in TlsDxe driver’s entry point. Like: TlsCtxNew (PCD_Minimum_version_major, PCD_ Minimum_version_minor); Then the accepted TLS version will be from PCD_Minimum_version to 1.3 Secondly, use loop to try different TLS versions, which can be implemented in platform side. Like: TLSVersionList = [1.3, 1.2, 1.1]; for (int i=0; i<len(TLSVersionList); i++) { SetSessionData(EfiTlsVersion, TLSVersionList[i]); // then, try to connect, if it works, break } The second comment is about how to set Cipher list. We can now change the gEdkiiHttpTlsCipherListGuid variable to change cipher list. The same variable and API is used from TLS v1.0 to TLS v1.2 However, TLS v1.3 has a different API and totally different cipher list parameters. Below is the comparison: SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) The input cipher suite list must include at least one available cipher suite for TLSv1.2 and below. SSL_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites The input cipher suite list must only include available cipher suite for TLSv1.3. I suggest introducing another table TlsV13CipherMappingTable to store the cipher list suit for TLS v1.3. Before calling SSL_set_ciphersuites(), use the mapping table to filter the cipher list, only remain the available ones. In this way, we can save all the cipher lists and cipher suites for TLS 1.3 and TLS v1.2 or below in one same variable. And before calling API to set cipher list, use the corresponding mapping table to filter. Also, for current TlsCipherMappingTable used for TLS v1.2 or below, I think the below cipher list are all insecure for they use MD5 and SHA. We should remove them. MAP ( 0x0001, "NULL-MD5" ), MAP ( 0x0002, "NULL-SHA" ), MAP ( 0x0004, "RC4-MD5" ), MAP ( 0x0005, "RC4-SHA" ), MAP ( 0x000A, "DES-CBC3-SHA" ), MAP ( 0x0016, "DHE-RSA-DES-CBC3-SHA" ), MAP ( 0x002F, "AES128-SHA" ), MAP ( 0x0030, "DH-DSS-AES128-SHA" ), MAP ( 0x0031, "DH-RSA-AES128-SHA" ), MAP ( 0x0033, "DHE-RSA-AES128-SHA" ), MAP ( 0x0035, "AES256-SHA" ), MAP ( 0x0036, "DH-DSS-AES256-SHA" ), MAP ( 0x0037, "DH-RSA-AES256-SHA" ), MAP ( 0x0039, "DHE-RSA-AES256-SHA" ), And for TLS v1.3, I suggest we enable the following cipher suite. 1. TLS_AES_256_GCM_SHA384 2. TLS_AES_128_GCM_SHA256 3. TLS_AES_128_CCM_SHA256 4. TLS_CHACHA20_POLY1305_SHA256 Please correct me if I am wrong. Any comments are welcomed. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 51719 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [edk2-devel] Propose on enabling TLSv1.3 2020-11-25 7:27 ` Zhiguang Liu @ 2020-12-03 0:24 ` Huang, Matthew (HPS SW) 0 siblings, 0 replies; 17+ messages in thread From: Huang, Matthew (HPS SW) @ 2020-12-03 0:24 UTC (permalink / raw) To: Liu, Zhiguang, devel@edk2.groups.io, Yao, Jiewen, Wang, Jian J, maciej.rabeda@linux.intel.com, lersek@redhat.com, Wu, Jiaxin, Fu, Siyuan, Xu, Min M, Zhang, Qi1, Kumar, Rahul1 Cc: Wei, Kent (HPS SW), Lin, Derek (HPS SW), Wang, Nickle (HPS SW), Wang, Sunny (HPS SW), vladimir.olovyannikov@broadcom.com, Tian, Hot, Madhavi Sinha, Fnu [-- Attachment #1: Type: text/plain, Size: 16739 bytes --] Hi ZhiGuang: Is it possible for us make a draft code change to propose that to network pkg maintainers in order to speed things up? And about the 32bit arithmetic assemblies, if we do not have It, yet, I can provide it as well, thanks. Regards, Matthew. From: Liu, Zhiguang <zhiguang.liu@intel.com> Sent: Wednesday, November 25, 2020 3:27 PM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com>; devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; maciej.rabeda@linux.intel.com; lersek@redhat.com; Wu, Jiaxin <jiaxin.wu@intel.com>; Fu, Siyuan <siyuan.fu@intel.com>; Xu, Min M <min.m.xu@intel.com>; Zhang, Qi1 <qi1.zhang@intel.com>; Kumar, Rahul1 <rahul1.kumar@intel.com> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com>; Lin, Derek (HPS SW) <derek.lin2@hpe.com>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; vladimir.olovyannikov@broadcom.com; Tian, Hot <hot.tian@intel.com>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for the response. I agree that this variable name “HttpTlsCipherList” and GUID “gEdkiiHttpTlsCipherListGuid” is confusing, but I am afraid renaming will break back-compatibility. Or we can define another variable and GUID like “HttpTlsCipherSuites” and “gEdkiiHttpTlsCipherSuitesGuid” to separately restore the cipher suite for TLS v1.3. We may need network package maintainer to make the decision. For the recommended cipher suites, TLS-AES-128-CCM-SHA256 is on my recommendation list. TLS-AES-128-CCM-8-SHA256 is identical to the TLS-AES-128-CCM-SHA256, except that it uses 8 octets, instead of the full 16 octets used by TLS-AES-128-CCM-SHA256. Therefore, TLS-AES-128-CCM-8-SHA256 is weaker and I recommend to not enable it. Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Wednesday, November 25, 2020 1:13 PM To: Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; lersek@redhat.com<mailto:lersek@redhat.com>; Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>; Xu, Min M <min.m.xu@intel.com<mailto:min.m.xu@intel.com>>; Zhang, Qi1 <qi1.zhang@intel.com<mailto:qi1.zhang@intel.com>>; Kumar, Rahul1 <rahul1.kumar@intel.com<mailto:rahul1.kumar@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com>; Tian, Hot <hot.tian@intel.com<mailto:hot.tian@intel.com>>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com<mailto:fnu.madhavi.sinha@intel.com>> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Agree that we should define a range type instead of assign a discrete value for TLS version, since TLS here we are talking about are client, it should be adapted by the server side without any problem if the handshake is properly executed. I’m okay with the separated tables handling TLSv12 & 13 respectively, but the variable name “HttpTlsCipherList” and GUID “gEdkiiHttpTlsCipherListGuid” can be confusing since the term “list” has the potential to mislead people to think that is a cipher list container for TLSv12. If we want to have the design to bind those two into one variable, maybe “HttpTlsCiphers” or “HttpTlsEnabledCiphers” would be a good start to thin out the spectrum. So about the TLSv13 portion, TLS-AES-128-CCM-SHA256 and TLS-AES-128-CCM-8-SHA256 are not recommended to be enabled, right? Matthew. From: Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Sent: Thursday, November 19, 2020 10:08 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Wang, Jian J <jian.j.wang@intel.com<mailto:jian.j.wang@intel.com>>; maciej.rabeda@linux.intel.com<mailto:maciej.rabeda@linux.intel.com>; lersek@redhat.com<mailto:lersek@redhat.com>; Wu, Jiaxin <jiaxin.wu@intel.com<mailto:jiaxin.wu@intel.com>>; Fu, Siyuan <siyuan.fu@intel.com<mailto:siyuan.fu@intel.com>>; Xu, Min M <min.m.xu@intel.com<mailto:min.m.xu@intel.com>>; Zhang, Qi1 <qi1.zhang@intel.com<mailto:qi1.zhang@intel.com>>; Kumar, Rahul1 <rahul1.kumar@intel.com<mailto:rahul1.kumar@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com>; Tian, Hot <hot.tian@intel.com<mailto:hot.tian@intel.com>>; Madhavi Sinha, Fnu <fnu.madhavi.sinha@intel.com<mailto:fnu.madhavi.sinha@intel.com>> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi all, I did some research about TLS v1.3 and here is my suggestion. I want to first collect information if we should continue to support TLS v1.1 or below. I personally suggest stopping support TLS v1.1 or below, for this is a trend. The first suggestion is about TLS version configuration. The supported TLS version should be a range not just a fixed value. For example, a TLS version from 1.2 to 1.3 are both accepted. However, there is not a direct UEFI API to set TLS version as a range. SetSessionData method in EFI_TLS_PROTOCOL will set the maximum and minimum TLS version as a same value. I have two solutions about this issue and want to collect feedback. Firstly, use a PCD to set the minimum TLS version in TlsDxe driver’s entry point. Like: TlsCtxNew (PCD_Minimum_version_major, PCD_ Minimum_version_minor); Then the accepted TLS version will be from PCD_Minimum_version to 1.3 Secondly, use loop to try different TLS versions, which can be implemented in platform side. Like: TLSVersionList = [1.3, 1.2, 1.1]; for (int i=0; i<len(TLSVersionList); i++) { SetSessionData(EfiTlsVersion, TLSVersionList[i]); // then, try to connect, if it works, break } The second comment is about how to set Cipher list. We can now change the gEdkiiHttpTlsCipherListGuid variable to change cipher list. The same variable and API is used from TLS v1.0 to TLS v1.2 However, TLS v1.3 has a different API and totally different cipher list parameters. Below is the comparison: SSL_set_cipher_list() sets the list of ciphers (TLSv1.2 and below) The input cipher suite list must include at least one available cipher suite for TLSv1.2 and below. SSL_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites The input cipher suite list must only include available cipher suite for TLSv1.3. I suggest introducing another table TlsV13CipherMappingTable to store the cipher list suit for TLS v1.3. Before calling SSL_set_ciphersuites(), use the mapping table to filter the cipher list, only remain the available ones. In this way, we can save all the cipher lists and cipher suites for TLS 1.3 and TLS v1.2 or below in one same variable. And before calling API to set cipher list, use the corresponding mapping table to filter. Also, for current TlsCipherMappingTable used for TLS v1.2 or below, I think the below cipher list are all insecure for they use MD5 and SHA. We should remove them. MAP ( 0x0001, "NULL-MD5" ), MAP ( 0x0002, "NULL-SHA" ), MAP ( 0x0004, "RC4-MD5" ), MAP ( 0x0005, "RC4-SHA" ), MAP ( 0x000A, "DES-CBC3-SHA" ), MAP ( 0x0016, "DHE-RSA-DES-CBC3-SHA" ), MAP ( 0x002F, "AES128-SHA" ), MAP ( 0x0030, "DH-DSS-AES128-SHA" ), MAP ( 0x0031, "DH-RSA-AES128-SHA" ), MAP ( 0x0033, "DHE-RSA-AES128-SHA" ), MAP ( 0x0035, "AES256-SHA" ), MAP ( 0x0036, "DH-DSS-AES256-SHA" ), MAP ( 0x0037, "DH-RSA-AES256-SHA" ), MAP ( 0x0039, "DHE-RSA-AES256-SHA" ), And for TLS v1.3, I suggest we enable the following cipher suite. 1. TLS_AES_256_GCM_SHA384 2. TLS_AES_128_GCM_SHA256 3. TLS_AES_128_CCM_SHA256 4. TLS_CHACHA20_POLY1305_SHA256 Please correct me if I am wrong. Any comments are welcomed. Thanks Zhiguang From: Liu, Zhiguang Sent: Friday, September 4, 2020 10:32 AM To: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; vladimir.olovyannikov@broadcom.com<mailto:vladimir.olovyannikov@broadcom.com> Subject: RE: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Thanks for your patience. I have established a test environment these days. With your tls 1.3 patch and Vladimir’s patch about http shell command, ovmf can download a html file from a https server that only allows tls 1.3. This test proves that the basic functionality is good. However, I still need time to investigate the impact to security, image size and other aspects. I will let you know if any progress from my side. Thanks for your contribution 😊 Thanks Zhiguang From: Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Sent: Thursday, August 20, 2020 7:16 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; Liu, Zhiguang <zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Any comments on these patches? Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Wednesday, August 12, 2020 7:13 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2@be01087e07. As I mentioned, ‘process_files.pl’ is processed with ActivePerl 5.28 Build 0000 (64-bit) and MSYS2 MinGW 64-bit, log is attached as ‘process_openssl.txt’. The problems are still the same, current OpenSSL has two problems: 1. It will not ignore disabled TLSv1.3 cipher suites, which results in all the TLSv1.3 cipher suites defined in TlsCipherMappingTable will be published no matter what the actual value is in gEdkiiHttpTlsCipherListGuid.HttpTlsCipherList. 2. SSL_set_ciphersuites cannot handle non-TLSv1.3 ciphers, which results in the function fails to set any ciphersuite if there are TLSv1.2 ciphers in the ‘CipherString’ argument. They are minor ones, but would’ve caused the whole flow acts weird. Those two problems are more or less solved or discussed in the OpenSSL scene, but not included in EDK2 yet. If anyone wants to test TLSv1.3, attachment ‘openssl.patch’ is suggested to be applied for a more reasonable outcome. Regards, Matthew. 寄件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> 代理 Huang, Matthew (HPS SW) 寄件日期: Monday, August 10, 2020 12:26 PM 收件者: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; zhiguang.liu@intel.com<mailto:zhiguang.liu@intel.com> 副本: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> 主旨: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Zhiguang: Sure, I love to. But I’m new to the scene, please give me some time to figure out how to share the snippet properly, thanks. Regards, Matthew. From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Zhiguang Liu Sent: Monday, August 10, 2020 11:00 AM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang@hpe.com<mailto:chao-jui.huang@hpe.com>> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: Re: [edk2-devel] Propose on enabling TLSv1.3 Hi Matthew, Can you share the code about implementing tls 1.3 to the community? We can discuss the problems according to the code. Thanks Zhiguang From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW) Sent: Monday, August 3, 2020 1:55 PM To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Wei, Kent (HPS SW) <kent.wei@hpe.com<mailto:kent.wei@hpe.com>>; Lin, Derek (HPS SW) <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang@hpe.com<mailto:nickle.wang@hpe.com>>; Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>> Subject: [edk2-devel] Propose on enabling TLSv1.3 Hi: It’s Matthew from HPE UEFI team. There is no TLSv1.3 support under current EDK2 releases, and I’m working on enabling TLSv1.3 under UEFI and the result looks promising. OpenSSL have already made RFC8446 happens in late 2018, the submodule we’re having on the master branch is more than enough to make the whole thing work. There are several problems needed to be addressed:' 1. OpenSslLib needs a reconfiguration with “no-ec” option on in process_files.pl, and no off the shelf Perl built with native Windows command prompt could’ve processed the file correctly. But I’ve managed to remove the blockage using Perl MSYS2 build under Windows without any error. Since this is only a one-timer, I don’t think that would’ve caused too much of a trouble. The produced opensslconf.h seems correct, and this is all we need. 2. There are some policies issues caused by OpenSSL, OpenSSL explicitly describes that SSL_set_cipher_list is for TLS version 1.2 and lower, SSL_set_ciphersuites is for TLSv1.3, but these function are tangled to each other and the behavior is not equally fair. In current revision EDK2 included in the OpenSSL submodule, SSL_set_cipher_list can parse v1.3 cipher suites but will not apply them, meanwhile SSL_set_ciphersuites cannot support any cipher lower than v1.3. This will cause a problem that when user applies auto versioning, TLSv1.3 will not be applied even if v1.3 is enabled except setting an empty list using SSL_set_cipher_list. 3. Apart from point 2., SSL_set_ciphersuites in current revision EDK2 included in the OpenSSL submodule, cannot exclude ciphersuites that user disabled, so every cipher suites will be in the list for server to But I browsed all OpenSSL github PRs or merge-pending patches, both point 2 and 3 have somewhat one or more solutions going on, I’ve applied them for testing and the result is fairly satisfying. If there’s a chance we discuss this in code? It will be easier this way, I have a working patch we can start with, thanks. Regards, Matthew [-- Attachment #2: Type: text/html, Size: 62390 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2020-12-03 0:24 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-03 5:54 Propose on enabling TLSv1.3 Huang, Matthew (HPS SW)
2020-08-03 22:06 ` Michael D Kinney
2020-08-10 2:59 ` Zhiguang Liu
2020-08-10 4:26 ` [edk2-devel] " Huang, Matthew (HPS SW)
2020-11-19 17:09 ` Matthew Carlson
[not found] ` <1629CD946C53C473.23035@groups.io>
2020-08-12 11:12 ` 回覆: " Huang, Matthew (HPS SW)
[not found] ` <162A80E91C03CB2F.12108@groups.io>
2020-08-19 23:16 ` Huang, Matthew (HPS SW)
2020-08-20 0:50 ` Zhiguang Liu
2020-09-04 2:32 ` Zhiguang Liu
2020-09-07 2:37 ` Zhiguang Liu
2020-09-07 5:29 ` Yao, Jiewen
2020-09-07 5:39 ` Huang, Matthew (HPS SW)
2020-11-19 2:07 ` Zhiguang Liu
2020-11-19 9:34 ` Laszlo Ersek
2020-11-25 5:12 ` Huang, Matthew (HPS SW)
2020-11-25 7:27 ` Zhiguang Liu
2020-12-03 0:24 ` Huang, Matthew (HPS SW)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox