[edk2-devel] Propose on enabling TLSv1.3
Huang, Matthew (HPS SW)
chao-jui.huang at hpe.com
Wed Nov 25 05:12:37 UTC 2020
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 at intel.com>
Sent: Thursday, November 19, 2020 10:08 AM
To: Huang, Matthew (HPS SW) <chao-jui.huang at hpe.com>; devel at edk2.groups.io; Yao, Jiewen <jiewen.yao at intel.com>; Wang, Jian J <jian.j.wang at intel.com>; maciej.rabeda at linux.intel.com; lersek at redhat.com; Wu, Jiaxin <jiaxin.wu at intel.com>; Fu, Siyuan <siyuan.fu at intel.com>; Xu, Min M <min.m.xu at intel.com>; Zhang, Qi1 <qi1.zhang at intel.com>; Kumar, Rahul1 <rahul1.kumar at intel.com>
Cc: Wei, Kent (HPS SW) <kent.wei at hpe.com>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com>; Wang, Sunny (HPS SW) <sunnywang at hpe.com>; vladimir.olovyannikov at broadcom.com; Tian, Hot <hot.tian at intel.com>; Madhavi Sinha, Fnu <fnu.madhavi.sinha at 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 at hpe.com<mailto:chao-jui.huang at hpe.com>>; devel at edk2.groups.io<mailto:devel at edk2.groups.io>
Cc: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at hpe.com>>; vladimir.olovyannikov at broadcom.com<mailto:vladimir.olovyannikov at 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 at hpe.com<mailto:chao-jui.huang at hpe.com>>
Sent: Thursday, August 20, 2020 7:16 AM
To: devel at edk2.groups.io<mailto:devel at edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang at hpe.com<mailto:chao-jui.huang at hpe.com>>; Liu, Zhiguang <zhiguang.liu at intel.com<mailto:zhiguang.liu at intel.com>>
Cc: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at hpe.com>>
Subject: 回覆: [edk2-devel] Propose on enabling TLSv1.3
Hi Zhiguang:
Any comments on these patches?
Matthew.
寄件者: devel at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> 代理 Huang, Matthew (HPS SW)
寄件日期: Wednesday, August 12, 2020 7:13 PM
收件者: devel at edk2.groups.io<mailto:devel at edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang at hpe.com<mailto:chao-jui.huang at hpe.com>>; zhiguang.liu at intel.com<mailto:zhiguang.liu at intel.com>
副本: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at hpe.com>>
主旨: 回覆: [edk2-devel] Propose on enabling TLSv1.3
Hi Zhiguang:
Please refer to the attached ‘tlsv13.patch’ based on tianocore/edk2 at 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 at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> 代理 Huang, Matthew (HPS SW)
寄件日期: Monday, August 10, 2020 12:26 PM
收件者: devel at edk2.groups.io<mailto:devel at edk2.groups.io>; zhiguang.liu at intel.com<mailto:zhiguang.liu at intel.com>
副本: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at 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 at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Zhiguang Liu
Sent: Monday, August 10, 2020 11:00 AM
To: devel at edk2.groups.io<mailto:devel at edk2.groups.io>; Huang, Matthew (HPS SW) <chao-jui.huang at hpe.com<mailto:chao-jui.huang at hpe.com>>
Cc: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at 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 at edk2.groups.io<mailto:devel at edk2.groups.io> <devel at edk2.groups.io<mailto:devel at edk2.groups.io>> On Behalf Of Huang, Matthew (HPS SW)
Sent: Monday, August 3, 2020 1:55 PM
To: devel at edk2.groups.io<mailto:devel at edk2.groups.io>
Cc: Wei, Kent (HPS SW) <kent.wei at hpe.com<mailto:kent.wei at hpe.com>>; Lin, Derek (HPS SW) <derek.lin2 at hpe.com<mailto:derek.lin2 at hpe.com>>; Wang, Nickle (HPS SW) <nickle.wang at hpe.com<mailto:nickle.wang at hpe.com>>; Wang, Sunny (HPS SW) <sunnywang at hpe.com<mailto:sunnywang at 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
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#67937): https://edk2.groups.io/g/devel/message/67937
Mute This Topic: https://groups.io/mt/76622099/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20201125/f217afb8/attachment.htm>
More information about the edk2-devel-archive
mailing list