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 4261422333790 for ; Tue, 23 Jan 2018 06:56:19 -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 2B6CA31A0F6; Tue, 23 Jan 2018 15:01:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-122-72.rdu2.redhat.com [10.10.122.72]) by smtp.corp.redhat.com (Postfix) with ESMTP id DCD83608F0; Tue, 23 Jan 2018 15:01:44 +0000 (UTC) From: Laszlo Ersek 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> <7b529d2c-1e46-3bd5-d8a6-9225a630f23b@redhat.com> <895558F6EA4E3B41AC93A00D163B72741635F0B5@SHSMSX103.ccr.corp.intel.com> <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.com> Message-ID: <93bf358e-7e57-a0f0-b8ba-239e72036c27@redhat.com> Date: Tue, 23 Jan 2018 16:01:39 +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: <366c3083-0eb1-ecb4-2050-654c09135f8a@redhat.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.29]); Tue, 23 Jan 2018 15:01:46 +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: Tue, 23 Jan 2018 14:56:20 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Jiaxin, two updates: >>>> 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. > > > 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:!SEED:!eNULL:!aNULL:!MD5:!SSLv2" Is this feasible? Thanks, Laszlo