From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=192.55.52.88; helo=mga01.intel.com; envelope-from=jiaxin.wu@intel.com; receiver=edk2-devel@lists.01.org Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) (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 E2B2521E48F2F for ; Tue, 23 Jan 2018 19:35:01 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jan 2018 19:40:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,405,1511856000"; d="scan'208";a="198310250" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by fmsmga006.fm.intel.com with ESMTP; 23 Jan 2018 19:40:29 -0800 Received: from fmsmsx126.amr.corp.intel.com (10.18.125.43) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Jan 2018 19:40:29 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX126.amr.corp.intel.com (10.18.125.43) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 23 Jan 2018 19:40:28 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.213]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.159]) with mapi id 14.03.0319.002; Wed, 24 Jan 2018 11:40:26 +0800 From: "Wu, Jiaxin" To: "Wu, Jiaxin" , Laszlo Ersek , "Fu, Siyuan" , "Ye, Ting" , "Long, Qin" , "Yao, Jiewen" , "Hsiung, Harry L" CC: edk2-devel-01 Thread-Topic: setting the TLS cipher list for HTTPS booting Thread-Index: AQHTkTKC7SSIQqPfwE6mEzdxVropQKN8Nf+ggALqwACAAZWo0IAARlKAgAAQ6YCAATdDQIAAHRVg Date: Wed, 24 Jan 2018 03:40:26 +0000 Message-ID: <895558F6EA4E3B41AC93A00D163B72741635F7FE@SHSMSX103.ccr.corp.intel.com> References: <5307d880-d016-ad91-04f5-6b83eb40f905@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635E571@SHSMSX103.ccr.corp.intel.com> <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F0B5@SHSMSX103.ccr.corp.intel.com> <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.com> <93bf358e-7e57-a0f0-b8ba-239e72036c27@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F6BC@SHSMSX103.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B72741635F6BC@SHSMSX103.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiODg5MWE5NzMtMzAyZC00NTM4LTg3OGEtZjRhZjBmZWQ1Y2IxIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Iks4bUdUK1ArSGd6NHBUa2tqV1A0K0pabGgrVzdBWUNaQ0hPc1k4ZnRWMXM9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 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: Wed, 24 Jan 2018 03:35:02 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Laszlo, More comments: >=20 > 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. >=20 > Each solutions have its own advantages and disadvantages: > 1) PCD can simplify the problem and it's easy to use for the other platfo= rm 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-cl= ass > library into HttpDxe that introduces a new DEPEX on the protocol. Other > platforms would not delay HttpDxe."]. If the user doesn't want HTTPS feat= ure > but only HTTP, it has to include one NULL protocol. >=20 I checked the PciHostBridgeDxe driver to call the EDKII_IOMMU_PROTOCOL, whi= ch makes me better understanding your comments.=20 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf { ... NULL|OvmfPkg/Library/PlatformHasIoMmuLib/PlatformHasIoMmuLib.inf } So, as you said, it's just the platform behavior so as to hook the platform= produces the EDKII_IOMMU_PROTOCOL protocol first, then dispatch PciHostBri= dgeDxe driver. That's good to me. For HTTPS configuration, the HttpDxe configuration is only happened during = the protocol instance calling, which is created by service binding protocol= . So, it looks only happened after EndofDxe phase. If so, it will be no suc= h optional dependency to wait for the platform DXE driver produces the EDKI= I_PLATFORM_HTTPS_CONFIG_PROTOCOL. Anyway, for above two solutions, I need review them with other colleagues a= nd help to collect the comments for both of them, then feedback to you. Tha= nk you so such. > 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 soluti= on > coding, you know we are always thinking from the user's perspective:). >=20 >=20 > > > > > > If you really think that HttpDxe should only care about these two ite= ms > > > (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 th= e > > 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? >=20 > It looks impossible to simply forward the *textual*cipher list to OpenSSL= from > the aspect of EFI_TLS_PROTOCOL. >=20 > //************************************************************ > // 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 Messa= ges. > The value of > EFI_TLS_CIPHER is from TLS Cipher Suite Registry of IANA. >=20 >=20 > > > > Thanks, > > Laszlo >=20 >=20 Thanks, Jiaxin