Re: setting the TLS cipher list for HTTPS booting

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

Hi Laszlo,

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

Dynamic PCDs is just one of the solutions for the required settings, just like the platform protocol (HTTPS_CONFIG_PROTOCOL), provides the capability to support the global HTTPS configuration. 

Each solutions have its own advantages and disadvantages: 
1) PCD can simplify the problem and it's easy to use for the other platform not only OVMF, but as you said, it's perhaps overkill. 
2) The additional platform protocol looks flexible and reasonably, but it makes the specific platform have the optional dependency ["OVMF hooks a NULL-class library into HttpDxe that introduces a new DEPEX on the protocol. Other platforms would not delay HttpDxe."]. If the user doesn't want HTTPS feature but only HTTP, it has to include one NULL protocol. 

Now, I think we are discussing the most appropriate way for the HTTPS controlling. It's NOT related to who should be responsible for the solution coding, you know we are always thinking from the user's perspective:).


> >
> > 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:!SEE
> D:!eNULL:!aNULL:!MD5:!SSLv2"
> 
> Is this feasible?

It looks impossible to simply forward the *textual*cipher list to OpenSSL from the aspect of EFI_TLS_PROTOCOL. 

//************************************************************
// EFI_TLS_CIPHER
//************************************************************
typedef struct {
UINT8 Data1;
UINT8 Data2;
} EFI_TLS_CIPHER;
Note: The definition of EFI_TLS_CIPHER is from RFC 5246 A.4.1.Hello Messages. The value of
EFI_TLS_CIPHER is from TLS Cipher Suite Registry of IANA.


> 
> Thanks,
> Laszlo


Thanks,
Jiaxin