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.

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_SHA256
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>
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 <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:

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.
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 <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 <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