From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CD98221D2BF00 for ; Mon, 22 Jan 2018 01:32:09 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 13C9B5D675; Mon, 22 Jan 2018 09:37:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-63.rdu2.redhat.com [10.10.121.63]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5D3AA88889; Mon, 22 Jan 2018 09:37:33 +0000 (UTC) To: "Wu, Jiaxin" , "Fu, Siyuan" , "Ye, Ting" , "Long, Qin" , "Hsiung, Harry L" Cc: edk2-devel-01 References: <5307d880-d016-ad91-04f5-6b83eb40f905@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> From: Laszlo Ersek Message-ID: <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> Date: Mon, 22 Jan 2018 10:37:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 22 Jan 2018 09:37:35 +0000 (UTC) Subject: Re: setting the TLS cipher list for HTTPS booting X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 09:32:10 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/20/18 07:18, Wu, Jiaxin wrote: >> >> 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. Thank you for the correction. Do I understand correctly that, consequently, these characteristics have to be set in NetworkPkg/HttpDxe as well, similarly to the cipher list? If that's correct, what would be the best way for a platform to control these settings? Introducing separate dynamic PCDs is perhaps overkill. Sometimes platform customization is implemented by the core module calling out to an optional platform-provided protocol. For example, PciHostBridgeDxe calls EDKII_IOMMU_PROTOCOL, if the platform provides one. Alternatively, PciBusDxe calls EFI_PCI_HOT_PLUG_INIT_PROTOCOL, if the platform provides one. Can we introduce a similar protocol here, so that HttpDxe can ask the platform about the TLS preferences, and then configure TLS accordingly? Sticking with the IOMMU example: in OVMF, we don't *always* have an IOMMU protocol, but when we do, then we want PciHostBridgeDxe to wait for the protocol (with a depex). So what we do is, we have a very small library instance, OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf with an empty constructor, and a DEPEX like this: [Depex] gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid (The latter protocol is from OvmfPkg.dec.) Then, in the OVMF DSC files, we hook this library into PciHostBridgeDxe, as a NULL class library. The end result is that PciHostBridgeDxe will only be dispatched after OVMF platform code determines whether an IOMMU is present or not. If not, then gIoMmuAbsentProtocolGuid is installed (and PciHostBridgeDxe will be launched without an IOMMU). Otherwise gEdkiiIoMmuProtocolGuid is installed by OVMF, and then PciHostBridgeDxe is guaranteed to use the IOMMU. In the HTTPS boot case, I'd make HttpDxe wait for the platform TLS settings similarly -- NetworkPkg/HttpDxe would only have to look up the protocol, and use it (for configuring TLS) if the protocol is there. This looks more flexible than a large set of dynamic PCDs. ... We have such names already: EDKII_PLATFORM_LOGO_PROTOCOL EDKII_PLATFORM_VTD_POLICY_PROTOCOL So we could introduce EDKII_PLATFORM_HTTPS_CONFIG_PROTOCOL, with the following member functions: .GetData () .GetSessionData () They would have similar signatures to EFI_TLS_CONFIGURATION_PROTOCOL.GetData() and EFI_TLS_PROTOCOL.GetSessionData(). "NetworkPkg/HttpDxe" could call each of these functions in a loop (iterating over EFI_TLS_CONFIG_DATA_TYPE and EFI_TLS_SESSION_DATA_TYPE, up to EfiTlsConfigDataTypeMaximum and EfiTlsSessionDataTypeMaximum, respectively). If the platform has nothing to say about a given item, it returns EFI_UNSUPPORTED. Otherwise, the platform returns the data that the platform would like HttpDxe to set for that TLS setting. > >> 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? I feel the platform protocol could be more flexible and extensible. Thank you! Laszlo