1. Is there any plan to support the below chiper in CryptoPkg? Cipher Suite ID - Cipher Suite String 0xC030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 0xC02F - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 0xCCA8 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 2. When will a complete implementation of TLS_1.3 in CryptoPkg will be available?
(In reply to prarthanasv from comment #0) > 1. Is there any plan to support the below chiper in CryptoPkg? > > Cipher Suite ID - Cipher Suite String > 0xC030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > 0xC02F - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > 0xCCA8 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 Can these be "simply" added to "TlsCipherMappingTable" in "CryptoPkg/Library/TlsLib/TlsConfig.c", perhaps? > 2. When will a complete implementation of TLS_1.3 in CryptoPkg will be > available? TLSv1.3 lets the TLS consumer module control more crypto aspects than TLSv1.2 does. This means that CryptoPkg will have to expose additional interfaces -- some of those new interfaces may even require UEFI spec changes. For (some) details, please see: https://bugzilla.redhat.com/show_bug.cgi?id=1559564#c17
(In reply to Laszlo Ersek from comment #1) > (In reply to prarthanasv from comment #0) > > 1. Is there any plan to support the below chiper in CryptoPkg? > > > > Cipher Suite ID - Cipher Suite String > > 0xC030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > 0xC02F - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > 0xCCA8 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 > > Can these be "simply" added to "TlsCipherMappingTable" in > "CryptoPkg/Library/TlsLib/TlsConfig.c", perhaps? > For first two cipher, yes; For third one, no. You need to remove following two macro definitions. #ifndef OPENSSL_NO_CHACHA # define OPENSSL_NO_CHACHA #endif #ifndef OPENSSL_NO_POLY1305 # define OPENSSL_NO_POLY1305 #endif
(In reply to Wang, Jian J from comment #2) > (In reply to Laszlo Ersek from comment #1) > > (In reply to prarthanasv from comment #0) > > > 1. Is there any plan to support the below chiper in CryptoPkg? > > > > > > Cipher Suite ID - Cipher Suite String > > > 0xC030 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > > 0xC02F - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > > > 0xCCA8 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 > > > > Can these be "simply" added to "TlsCipherMappingTable" in > > "CryptoPkg/Library/TlsLib/TlsConfig.c", perhaps? > > > > For first two cipher, yes; > For third one, no. You need to remove following two macro definitions. > > #ifndef OPENSSL_NO_CHACHA > # define OPENSSL_NO_CHACHA > #endif > > #ifndef OPENSSL_NO_POLY1305 > # define OPENSSL_NO_POLY1305 > #endif Sorry, it's removing those macro from file CryptoPkg\Library\Include\openssl\opensslconf.h. In addition, HttpDxe uses UEFI variable "HttpTlsCipherList" to store supported cipher suites and pass the value of it to TlsLib. If this driver is used, the variable should also be updated to contain new cipher suite ids.
One cannot "Add" ciphers by using the TlsCipherMappingTable or by adding them into the HttpTlsCipherList. To use any of the ECxxx ciphers, you have to reconfigure openssl removing the "no-ec" option in process_file.pl done by TianoCore, and reconfigure Openssl. Note: This requires a Linux system as none of the Windows perl options like the UEFI selection of "/" characters a file delimiters. Once doing this, if you expect to pass in these ECxxx ciphers in the HttpTlsCipherList, then the TlsCipherMappingTable needs to be updated.
We have this change in Project Mu (https://github.com/microsoft/mu_tiano_plus/tree/release/202005/CryptoPkg/Library/OpensslLib) that adds ECC ciphers. Is anyone actively tackling this? Otherwise, I'll stage a patch series that fixes this.
*** Bug 2810 has been marked as a duplicate of this bug. ***
Created attachment 538 [details] Acessing from UEFI https boot to Apache2.4 https services We have implemented a workable TLSv1.3 based on configured process_files.pl using ActivePerl Windows + MSYS2 build and several modification in TlsLib. But there are some minor issues we might need to discuss with the OpenSSL side, most of them are policy ones. We could start to discuss if anyone likes to move foward.
Related discussion: [edk2-devel] Propose on enabling TLSv1.3 https://edk2.groups.io/g/devel/message/63676 msgid: <DF4PR8401MB1067E1659BBAA855D904A51CCD4D0@DF4PR8401MB1067.NAMPRD84.PROD.OUTLOOK.COM> https://www.redhat.com/archives/edk2-devel-archive/2020-August/msg00160.html https://www.redhat.com/archives/edk2-devel-archive/2020-September/msg00161.html https://www.redhat.com/archives/edk2-devel-archive/2020-November/msg00842.html
Please let us know if there is any further update on implementing TLS_1.3
A tangential note: my understanding is that OpenSSL 3.0 is about to be released: https://www.openssl.org/blog/blog/2021/06/17/OpenSSL3.0ReleaseCandidate/ Perhaps as preparation for TLSv1.3 support, we should consider advancing edk2 to OpenSSL 3.0, without any functionality changes at first. The idea is to adapt edk2 (CryptoPkg/BaseCryptLib) to any API-level changes: >| OpenSSL 3.0 is a major release, which means that the library ABI is >| changed requiring recompilation of all dependent applications and there >| are also minor API breaking changes. For most applications that need to >| be upgraded to work with 3.0 we expect that a simple recompile will be >| sufficient. However, it is likely that application developers will notice >| new deprecation warnings when compiling their applications. Many of the >| “low level” cryptographic API functions have been deprecated in >| preference to the higher level “EVP” APIs. For detailed guidance on >| how to migrate applications to work with OpenSSL 3.0, refer to our >| migration guide. https://www.openssl.org/docs/manmaster/man7/migration_guide.html
I feel this one includes too many things: 1) ECC enabling. (https://bugzilla.tianocore.org/show_bug.cgi?id=2810) 2) TLS 1.3 enabling. (This one) 3) OpenSSL 3.0 enabling. (Laszlo's comment) I prefer we use three different Bugzilla to resolve them one by one. Maybe 2) depends on 1). But I do not see a strong dependency for rest. ECC can be used without enabling TLS 1.3. In case we want ECC for other use case. TLS 1.3 can be enabled in OpenSSL 1.1.1.
Hi Jiewen, should I file a separate feature request for OpenSSL 3.0 support (with no functional changes in edk2)? Thanks, Laszlo
sure. please.
Thank you Jiewen, filed this: CryptoPkg: consume OpenSSL 3.0 https://bugzilla.tianocore.org/show_bug.cgi?id=3466 and also made it block the present bug. (If that dependency is incorrect, then please remove / adjust it as appopriate.) Thanks!
Please update if there is any progress on TLS_1.3 support changes in CryptoPkg.
