Re: setting the TLS cipher list for HTTPS booting

[Laszlo Ersek <lersek@redhat.com>]

Hi Jiaxin,

two updates:

>>>> Jiaxin: I agree with the dynamic PCD solution for the CipherList
>>>> setting, the PCD format can use as following one:
>>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists
>>> |{0x0}|VOID*|0x0000000D
>>>> If the platform wants to set the below CipherSuites (RFC 5246
>>>> defined):
>>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
>>>> 	CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
>>>> The PCD can be configured by the corresponding platform as below,
>>>> otherwise it will use the OpenSSL default one:
>>>> 	gEfiNetworkPkgTokenSpaceGuid.PcdHttpsTlsCipherLists |{0x00,0x35,
>>> 0x00,0x3D }|VOID*|4
>>>> what do you think?

> Functionally, I agree that OVMF can make the feature work, without any
> changes to the HttpDxe driver, *but* only for the following two
> configuration items:
> 
> - CA certificate, through the (already existing) non-volatile UEFI
>   variable
> 
> - cipher suites (through the new dynamic PCD called
>   "PcdHttpsTlsCipherLists")
> 
> What about the rest of the configuration items? Should we introduce
> dynamic PCDs for those as well, individually?
> 
> I cannot tell what other config items should be exposed right from the
> start. That's why I'm suggesting HTTPS_CONFIG_PROTOCOL -- it looks
> flexible and reasonably future-proof.
> 
> BTW, I'm not asking that you write any code for this; I plan to submit
> the patches myself (for HttpDxe as well). We just have to figure out the
> direction first.
> 
> 
> If you really think that HttpDxe should only care about these two items
> (CA cert and cipher list), then I have another question: do you think it
> makes sense to introduce another non-volatile UEFI variable, for the
> cipher suites too? This would make things uniform, and perhaps
> TlsAuthConfigDxe could expose the cipher suites too, as a list of
> checkboxes. Just an idea.

So, apparently we indeed care about these two options mostly, i.e., the
CA certs, and the cipher suites.

However, I was informed that OVMF should simply forward the *textual*
cipher list representation, with preferably no processing at all before
the string reaches the OpenSSL code. In other words, OVMF should set the
PCD -- or, even better, variable -- to a *character string* like this:

"kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA:!SEED:!eNULL:!aNULL:!MD5:!SSLv2"

Is this feasible?

Thanks,
Laszlo