From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from a7-12.smtp-out.eu-west-1.amazonses.com (a7-12.smtp-out.eu-west-1.amazonses.com [54.240.7.12]) by mx.groups.io with SMTP id smtpd.web11.11204.1678184347801571497 for ; Tue, 07 Mar 2023 02:19:08 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@ipxe.org header.s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2 header.b=kQm9eYGF; spf=pass (domain: eu-west-1.amazonses.com, ip: 54.240.7.12, mailfrom: 01020186bb94ef66-3ef05d85-42ce-48e1-b75b-f7ec9420ab8d-000000@eu-west-1.amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=cphpx6z2rfcgehlykjjh3gknqe3hsoe2; d=ipxe.org; t=1678184345; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=AD4khZ9tCGHA6NA7qChqXp6IGuPJDCE8ZEQnGB5UVJ4=; b=kQm9eYGFxGT4SkLpaLLKR7SOqkWeWDB/4L2Y+QvjBqr+VxCOIM4TJd0ja+WFKkJ0 L+cMaDPS8RE6x0qFw4YmM/zcECN49FQ/Jmzbka9FSRD4bql0iQC8VRt32wvGwYE2cjj 4hyCTKxmWuO+Rm5fzuXEV1zJsDHE28acNMo3YOKB1hPMHRQ+G79CguRXQw8MKWGxfQU KqMF/KK7z2M+TPdtIfjtlGed+7ZA25Z6a96fHC1G9cRYFreSYGzhKlGyrnhcBMu4hsx jpmhB/FDwzY6tx08PeeTrLFngsjztc/yE7gdUkWZf74b9tizcyz2vp3OlJGIrDzJMk6 nzPzoUg6OA== DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ihchhvubuqgjsxyuhssfvqohv7z3u4hn; d=amazonses.com; t=1678184345; h=Message-ID:Date:MIME-Version:To:Cc:References:From:Subject:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=AD4khZ9tCGHA6NA7qChqXp6IGuPJDCE8ZEQnGB5UVJ4=; b=Nfnux5zaM04Gd6yh9rb93aH5ofynkjhVn+rCknM4zMQC/C9DDN07OzNjA+MOO7Zr skBQLSocnojRwYSyDLig28o9z+2mXrMQj9do1Uv1l+YhjuZg2nCvTfI/CGLva6AXR+L XFlRFVzQCYnuTdGzD3s6Rca0h7RJRyEjcR6vJIwU= Message-ID: <01020186bb94ef66-3ef05d85-42ce-48e1-b75b-f7ec9420ab8d-000000@eu-west-1.amazonses.com> Date: Tue, 7 Mar 2023 10:19:05 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 To: devel@edk2.groups.io, nicklew@nvidia.com, Maciej Rabeda , Siyuan Fu Cc: Abner Chang , Igor Kulchytskyy , Nick Ramirez References: <20230201034636.619-1-nicklew@nvidia.com> <010201860c96846b-a8bde2d8-b485-4c67-8946-70263fa807d9-000000@eu-west-1.amazonses.com> <010201860cbb9236-cbe26a21-cdb6-4d78-aaee-2626fccd5b61-000000@eu-west-1.amazonses.com> <173FEE62613A7ADA.16586@groups.io> From: "Michael Brown" Subject: Re: [edk2-devel] [PATCH 1/2] NetworkPkg/HttpDxe: provide function to disable TLS host verify 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: 2023.03.07-54.240.7.12 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 07/03/2023 08:21, Nickle Wang via groups.io wrote: > I got an idea to handle this issue. > > EFI_HTTP_SERVICE_BINDING_PROTOCOL is defined in UEFI specification for > caller to create HTTP protocol on child instance. How about I propose a > new service binding protocol called > EFI_HTTP_*NO_TLS_HOST_VERIFY*_SERVICE_BINDING_PROTOCOL, and the > EFI_HTTP_PROTOCOL created by this service binding protocol will not do > TLS host verify during HTTPS communication. > > When caller like to disable host verify on HTTPS communication, caller > use this service binding protocol to create special HTTP instance. For > other case, caller use regular EFI_HTTP_SERVICE_BINDING_PROTOCOL to get > normal EFI_HTTP_PROTOCOL instance. That seems very hacky, and does not help to address the general problem of being able to more flexibly configure HTTP connections. From a quick look through the UEFI spec, it looks as though EFI_TLS_PROTOCOL.SetSessionData() should already allow you to set EfiTlsVerifyMethod with a value of EFI_TLS_VERIFY_NONE. The implementation of HttpDxe makes it very messy to gain access to the EFI_TLS_PROTOCOL instance, since it will be created only when EFI_HTTP_PROTOCOL.Request() is called. I think you may have to use gBS->RegisterProtocolNotify() in order to intercept the point at which EFI_TLS_PROTOCOL is installed. In your notification event callback, you would then check to see if the handle is a child of the EFI_HTTP_PROTOCOL handle and, if so, call EFI_TLS_PROTOCOL.SetSessionData() to disable host verification. You would need to be using a newly created EFI_HTTP_PROTOCOL instance, so that you could be sure that there was no existing EFI_TLS_PROTOCOL instance already in place. I haven't tested any of the above, but it looks as though it should work and allow you to disable host verification for a single EFI_HTTP_PROTOCOL instance, without any specification changes. Michael