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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
