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.