From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 12D35AC14BF for ; Tue, 2 Jan 2024 17:46:50 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=S8/Irmt0+ajWMNAycAHEHr9T56U1IHRDP1r9R047lKo=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:Autocrypt:In-Reply-To:Feedback-ID:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1704217609; v=1; b=LkCh0HQgk5nUY3JhIc0i+56FhlVRahNb5KaJvaPRprPVDLbJtT6srmviXswMSUX9WuaJoo2f 6jKWsBkRJA5lBLjCUKmfJwurRQVvI1aa1TvNqdbDY98QnGfG6dQsOz+GHkFPlfm32LLhL/G18IQ 1AwZWU7TiV7ZdH8r82AJ6ogs= X-Received: by 127.0.0.2 with SMTP id 9jHmYY7687511xHob2SxqplE; Tue, 02 Jan 2024 09:46:49 -0800 X-Received: from a7-19.smtp-out.eu-west-1.amazonses.com (a7-19.smtp-out.eu-west-1.amazonses.com [54.240.7.19]) by mx.groups.io with SMTP id smtpd.web11.34835.1704217608666267220 for ; Tue, 02 Jan 2024 09:46:49 -0800 Message-ID: <0102018ccb48f9cd-95add6c6-dcb8-4298-b3ba-61be39730b97-000000@eu-west-1.amazonses.com> Date: Tue, 2 Jan 2024 17:46:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy To: devel@edk2.groups.io, abner.chang@amd.com Cc: Saloni Kasbekar , Zachary Clark-williams , Nickle Wang , Igor Kulchytskyy References: <20231226112839.1152-1-abner.chang@amd.com> <0102018cb0c83b57-ba6b133e-5f5c-4d05-85dc-bd6e32c87e41-000000@eu-west-1.amazonses.com> <0102018cb10db8bd-9edca239-8a41-4946-ad58-63ddb5a25921-000000@eu-west-1.amazonses.com> <0102018cb2e039d3-9ec4b97f-d3eb-4b4c-a8fd-248d4916f6f8-000000@eu-west-1.amazonses.com> <0102018cc7481f4b-30b20784-217d-4677-8854-055c9e509c70-000000@eu-west-1.amazonses.com> <0102018cca323415-72e68e82-2db0-4821-897e-8eff33fbe586-000000@eu-west-1.amazonses.com> From: "Michael Brown" Autocrypt: addr=mcb30@ipxe.org; keydata= xsFNBGPmfF4BEAC3vcU4aLC/9Uy/rTpmYujbqxQNZje9E34jGvLxO3uYwj4BeHj1Nn5T2TDM Gkc4ngk+mGPsJsIn69YU5cfVN+ch9O7FVfsn6egZsCNeLy6Qz0o//gBaWJodFBeawuBjXXyV HnQZa1p7bA/Lws8minW7NrZ7XZgEBaiVm1v1dNbLEoWR8UL2AMtph5loCQ5jPYQNqp/wH9El /R30GjXvAd1riWyJR2TWSN23J9rnuH2Ue+N4yEnWxAsBQ6M/NFQ5z42w4mYdsnzy1w3PulrL icpSixXHkm3lQcKGtKKX41HvJukSpxCgbHfuHGEJZ7bdhgRic1DHKav0JR8kQhx3gnPh06z8 1Teu2NKkSsTR3Iv6E2x6Yy6H34lKWzBzd8TLNSevesDD/L6NU/HxT9AxrTBuypk9PZGe2VH1 W03XnR/0Mnr0QqQBXcIAERdgNzRJY4VKF75vedf8IooZFUQ4RUlqH+x3aZB9nJ9ET77mPaNi SQVQBxE68uzb7eh2Kf6z7ftOYpWPw1v5HyB3oMmafEDG36SIvNF2wnmNaLQDRnAbTcy4ERgy tpJ3wtQDJeXOePLv8hJ3q7DSuePl7cwz4xy0ZHglW/EXRXLnyRRACfDGowyENoStg06qF+qm edGu1wNtmDZ/lypWm/CkzzpUDFeGP5BLZlqwVX4hn88llfvVzwARAQABzR5NaWNoYWVsIEJy b3duIDxtY2IzMEBpcHhlLm9yZz7CwZEEEwEIADsWIQTgD69MBpjBm2slMvwCNbEKAOtEUAUC Y+Z8nwIbAwULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgAAKCRACNbEKAOtEUFlhD/9ElIUg JxBXpIbF8s7u79OdXLld2Z1DfVmhP5Q+GilPvEeAWHhp689S9B88aNvpwW5zJfxlxcJZO0ay jc7E/vtdNrkXGWNEEXBgdve6m+uL+pW/i5E2htqxbLyfgTJKmsvJ8graHbwrrBS/PA8KuwVJ eAGbBNi3f1gyQQWrLqfTkUpLtuj7A76iVVk0G0a78L69Al84qhK2imqpFJoZt1F8h0Z5ddGv mvf2M/DZp87UXvXjy7X6r7msbMZa6S/Jv0dtWHeZGl3Xu3qzbtjlqFyz2Q7TibHiirsgg/CV BsbH/LLbi/aNCCQ/85C6jAMB0lNzcVZ7ZiKKo+vBNMTycDFk70LA9yjlNf7exHejoXmPkLmH ddapYZ4dzwdOiJlaTu8NZgzXUCt3RDDA1qmZrAOBF/F+tPILAEhenl9kj3blD3mPV2SrWLWY dbahY9BsylUhj/qE1ik5CJXrPotmJhok9Vpg07xKDpVnZXuWLGNIE8018UumO7phLrWQwLb1 wJdN7PG165w4UWf4aQphfwaMKOVU3WDghz3aVSP9rgtm3RsUcYHPKx8IaPcDh2yf0bgG386i Axx3U3UQeyz2Pb9Vigo6DmPwXjLkFr/dukvVLVJLVkUab9ZhhERzWTEEMifUVEK2rGNvA87L VKJ2zOyxWx1e0CPj6fcGbkJ0D10XLs7BTQRj5nxeARAAz18zv2ksRiM6eEKG0qzpiKHVYlVy wtjla+m9wuAIwm314tffY5hjQN46uwTstdhQirjywF1EmcS6KNGiIjmoLim+dqyFP5d/UF5A VjLt0TYq7HjadIxbm2/CvcRnNJ01FkD99xLxV0hFTUAWAUX1mNqQ3MmWIjV89wiT06uuAUog m+jG3RRDyWbUnVELR60mhzccKsaEsjO/HqIERvBwL7tlOJewlPrVyz9Zed9Nhhv0KDAYmdEm kIEEbOfsjRu5I6nIY3NrX+QP9+nmgxADlsjvLXTSU0fT/g7IPEl3gpsQZAbgmrlGcPtvXod8 P4iOmL8GJDU1RdBE9TBOLEbu9UlDRD4zr6tdzRpB9wvXdtSUcNCdHVqJTfq2qjIlBk7x+zQD ayhxzDvTMxD/93K6txKXmVVtfMBsmt9KuD2JBUEAExjsLHqzg48nQg8wF9JYWCWGBb36qpd0 yC6VPzhSLe2Ov3/GyV5ZshO046+OiGxEeaHCwMnDTZF9xrQ5paCwWedlWKvGM2zB64AHuk+M v2ABK/gbDO7eS6p+xz11oD1NHr1HQLRtknfClIqj9AmjgX9maD+4GUrmHaxmkNilIukahotd Un9Up2gX05Wy/S3H/v8RB0kxwWg2Wh065dnyCF4Doe18bcYZvM+iMJmUBag6aDfQlryM04K7 z4ITYDkAEQEAAcLBdgQYAQgAIBYhBOAPr0wGmMGbayUy/AI1sQoA60RQBQJj5nxeAhsMAAoJ EAI1sQoA60RQZj4QAIkiRDVNWynZ4kEdpqmf6hpD++Zycz+LMne4iGRsiyyTf/rPNgskNLrU JD555yDvFiEAhOI27R8YNCJj5byXRDa/Bm6ueClFia+POibt28UEdyOFU9PVcgFaU+VxaBIP rHacHL6A7UKFjmBN7o8VkVF2xXlmFge795mP4/Y3t6qfWUTodrpw1w1t5/bZxZdWqX4pUCpY fEx87jm60+Mj0Tb4VPWXz0UD1q1BDcdYxNa2ISLaJhGJmjjks9eqdFOhPo1fTINMNWF2Alxi jA6WNT8nn9lm1kav75EMYMc8WIR9tb03i+IuKNp2IWwTGBqIUyQj00BhHkZQFl4HxZhV0gXE AWu34Q/Z7hOUXGXq2tvYCxDeaQb2wks93e62lrrUm1JGhPWkVoCI8Md8N2mkonqIfMK8lQ0W WbkYHdKBkgDqhDypNNhkjWNX3JL1kL0c3rqGL381iBAZaGQPygyCx2xH9PDNp59W6u8sXb13 +UX+kXdWU+KYbMTVoO/t4MxUJg6nXPJHz9NCkyluI820l+2OtXZZy0u196evIlUdD6RoTrNK z5OgFxNctVi9BPsQea9du+JlYJ460vZNPz180oczj7iqffd+p9DmAkeK25njWhg3qPeXiNZN 45J9eMChSOaJ0GMGUQndIIxz7PO8IzjbkSHLG5CKrR3MaphMB/0L In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Feedback-ID: 1.eu-west-1.fspj4M/5bzJ9NLRzJP0PaxRwxrpZqiDQJ1IF94CF2TA=:AmazonSES X-SES-Outgoing: 2024.01.02-54.240.7.19 Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,mcb30@ipxe.org List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: moD462UnCc7pysTa8PPlAVHHx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=LkCh0HQg; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On 02/01/2024 16:31, Chang, Abner via groups.io wrote: >> From: Michael Brown >> - Allow the call to Request() to perform its normal TLS configuration >> via TlsConfigureSession(), as though the connection were going to >> perform host verification etc as per the platform default policy. This >> configuration should succeed, with no error returned. > > This is not correct. The first Request would be failed at TlsConfigureCertificate here https://github.com/tianocore/edk2/blob/master/NetworkPkg/HttpDxe/HttpsSupport.c#L711 I assume this is because we expect that the TlsCaCertificate variable may be empty or non-existent? Would it make sense to have an EFI_NOT_FOUND from TlsConfigCertificate() be ignored, as is already done for TlsConfigCipherList() just above? Something like: Status = TlsConfigCertificate (HttpInstance); if (EFI_ERROR (Status) && (Status != EFI_NOT_FOUND)) { DEBUG ((DEBUG_ERROR, "TLS Certificate Config Error!\n")); return Status; } i.e. treat an absent TlsCaCertificate variable as meaning "there are no explicit CA certificates", allowing TlsDxe to do whatever it does in that situation (which is presumably to fail any attempted certificate verifications). That would eliminate this problem in the RedfishRestExDxe case. > and SetSessionData to EfiTlsVerifyHost here: https://github.com/tianocore/edk2/blob/master/NetworkPkg/HttpDxe/HttpsSupport.c#L679. I don't understand why this call would be expected to fail. It's not performing any verification at this stage, just recording the hostname from the URI for subsequent use in certificate verification. I would expect this call to succeed and record whatever hostname is present in the request from RedfishRestExDxe. This hostname will subsequently be ignored for verification, since the HttpEventInitSession callback will set EFI_TLS_VERIFY_NONE. >> - In the RedfishRestExDxe callback, check for HttpEventInitSession and >> use calls to EFI_TLS_CONFIGURATION_PROTOCOL.SetData() to modify the TLS >> configuration to e.g. set EFI_TLS_VERIFY_NONE. > Here is the thing. Even we reconfigure TLS configuration data at HttpEventInitSession in RestEx, the EfiHttpRequest still returns fail to the caller here: https://github.com/tianocore/edk2/blob/master/NetworkPkg/HttpDxe/HttpImpl.c#L599. Not to mention the reason of failures may not be caused by TlsConfigureSession. There are failures for some other reasons in HttpInitSession. Also, what the caller suppose to do when it gets error returned? How does caller knows the error is just because the TLS configuration failure and it has to reconfigure TLS and retry HttpRequest? The logic doesn’t make sense if the caller assumes the failure is caused by TLS configure at HttpEventInitSession callback. Actually, having a high layer application to reconfigure TLS configuration data because the failure caused by not well-considered default TLS config values also doesn’t make sense, right? I would expect this to be resolved by the above suggestions. HttpInitSession() should succeed. The HttpEventInitSession callback should be called with an EFI_SUCCESS status code, and there is no need for the caller to retry anything. >> To make the callback implementation easier, you may want to extend >> HttpNotify() to take HTTP_PROTOCOL *HttpInstance as its first parameter, >> and then pass HttpInstance->Handle as an additional parameter to the >> callback method, i.e.: >> >> typedef >> VOID >> (EFIAPI *EDKII_HTTP_CALLBACK)( >> IN EDKII_HTTP_CALLBACK_PROTOCOL *This, >> IN EFI_HANDLE HttpHandle, >> IN EDKII_HTTP_CALLBACK_EVENT Event, >> IN EFI_STATUS EventStatus >> ); > We shouldn’t change the prototype as the callback mechanism may used by OEM/ODM platform code which is not part of tianocore. This change breaks backward compatible. Honestly, leverage HTTP callback function doesn’t really serve the purpose well. This is the HttpDxe design defect as we don’t the used case like in-band Redfish communication. OEM/ODM code should restrict itself to using APIs covered by the UEFI specification. If OEM/ODMs choose to rely on EDK2 private implementation details (such as EDKII_HTTP_CALLBACK) then they must be prepared to update their code when the private implementation detail changes. Thanks, Michael -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#113040): https://edk2.groups.io/g/devel/message/113040 Mute This Topic: https://groups.io/mt/103368438/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-