Re: setting the TLS cipher list for HTTPS booting

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

> 
> Hello Jiaxin, Siyuan,
> 
> it seems that the "preferred set of ciphers" can be controlled at the
> TLS session level.


Jiaxin: Yes, TLS CipherList can be configured by TLS protocol.  


> 
> With regard to HTTPS booting, "NetworkPkg/HttpDxe" makes several calls
> to EFI_TLS_PROTOCOL.SetSessionData() -- in the file
> "NetworkPkg/HttpDxe/HttpsSupport.c", -- but it never passes
> "EfiTlsCipherList" as argument for the "DataType" parameter.
> 


Jiaxin: Correct, currently, HttpDxe as a TLS protocol consumer doesn't set the its own preferred CipherList because it prefers to use the default CipherList, which has been configured by TLS driver by default. The TLS default setting was happened during the creation  of new OpenSSL SSL_CTX object. The flow path is shown as below: 
TlsCtxNew -> SSL_CTX_new -> ssl_create_cipher_list. 
So, the default CipherList is:
 # define SSL_DEFAULT_CIPHER_LIST "ALL:!COMPLEMENTOFDEFAULT:!eNULL"


> Is there a way for platform code to control the list of ciphers?


Jiaxin: Currently, not support yet.


> 
> This is different from other "global" TLS aspects, such as
> EFI_TLS_CONFIGURATION_PROTOCOL, because the latter is a singleton
> "service" protocol, while EFI_TLS_PROTOCOL instances are created by
> clients as-needed, via TLS service binding. So, I think if a platform
> wanted to control this on the session level, then it would have to "ask"
> HttpDxe somehow.
> 


Jiaxin: EFI_TLS_CONFIGURATION_PROTOCOL provides the capability to set the client certificate/key pairs, different clients may use the different certificate/key Paris (so does OpenSSL). Based on this, it's not a singleton "service" protocol. So, in TlsDxe driver, we bind it to the same ChildHandle as TLS protocol.
  Status = gBS->InstallMultipleProtocolInterfaces (
                  ChildHandle,
                  &gEfiTlsProtocolGuid,
                  &TlsInstance->Tls,
                  &gEfiTlsConfigurationProtocolGuid,
                  &TlsInstance->TlsConfig,
                  NULL
                  );
But above implementation also doesn't prevent all the clients use the same certificate/key Paris since they can use its own EFI_TLS_CONFIGURATION_PROTOCOL to configure the same "global" certificate/key pair (on the session level). That's depend on the TLS consumer.


> If you agree -- do you suggest a dynamic PCD, or an extension to the
> UEFI spec (at the HTTP level)?
> 


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?

> Thanks!
> Laszlo