public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Chang, Abner via groups.io" <abner.chang=amd.com@groups.io>
To: Michael Brown <mcb30@ipxe.org>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>,
	Zachary Clark-williams <zachary.clark-williams@intel.com>,
	Nickle Wang <nicklew@nvidia.com>,
	Igor Kulchytskyy <igork@ami.com>
Subject: Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy
Date: Fri, 29 Dec 2023 15:07:35 +0000	[thread overview]
Message-ID: <MN2PR12MB39667B61B8AF57340295961EEA9DA@MN2PR12MB3966.namprd12.prod.outlook.com> (raw)
In-Reply-To: <0102018cb2e039d3-9ec4b97f-d3eb-4b4c-a8fd-248d4916f6f8-000000@eu-west-1.amazonses.com>

[AMD Official Use Only - General]

> -----Original Message-----
> From: Michael Brown <mcb30@ipxe.org>
> Sent: Friday, December 29, 2023 8:01 AM
> To: devel@edk2.groups.io; Chang, Abner <Abner.Chang@amd.com>
> Cc: Saloni Kasbekar <saloni.kasbekar@intel.com>; Zachary Clark-williams
> <zachary.clark-williams@intel.com>; Nickle Wang <nicklew@nvidia.com>; Igor
> Kulchytskyy <igork@ami.com>
> Subject: Re: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS
> policy
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 28/12/2023 23:37, Chang, Abner via groups.io wrote:
> >> As far as I am aware, EfiHttpRequest sets up all of the relevant data
> >> structures but functions as a non-blocking open.  If you reconfigure the
> >> TLS session immediately after return from EfiHttpRequest() then this
> >> reconfiguration should take effect before any network packets have been
> >> transmitted or received.  I have not tested this, though.
> >>
> >> If the immediate reconfiguration does not work, then your suggestion of
> >> hooking SetSessionData() sounds like the easiest approach.
> > I think the non-blocking transfer still sends out the request but just not
> waiting the response there, have to check the implementation.
>
> The code seems to construct the HTTP request and enqueue it, but unless
> it blocks polling on the network somewhere then the most it can do in
> terms of network I/O is to send out the initial TCP SYN.  (Not even
> that, if a DNS lookup is required.)

Hi Michael,
To locate TLS protocol from the HTTP handle and configure TLS configuration data at the return from EfiHttpRequest during that short window of non-blocking request is not reliable. It also doesn't make sense to ask upper layer application to do this when it first time invokes EfiHttpRequest.
I already refactored TlsCreateChild to install TLS protocol on HTTP handle. I also implemented the corresponding code in Redfish REST EX to listen the installation of TLS protocol and hook the SetSessionData. It works fine on the system, however I really don’t like having the upper layer application to do this much just for overriding TLS configuration data. The code looked a specific implementation to hack the TLS protocol interface. Plus I still have to add few code in TlsConfigCertificate to skip configure certificate with checking TlsVerifyMethod.
We should sit back to consider introducing a new protocol for upper layer application to provide their own TLS configuration data, as the root cause is that hard coded TLS configuration data in HttpSupport.c. We shouldn't have the code like that and add the burdens to application.

What my thought is as below and maybe more elegant than the patch a sent,
- Still install TLS on HTTP handle, then upper layer application can listen to the installation of EFI TLS protocol to find the correct HTTP handle.
- Move TLS_CONFIG_DATA in a public header file.
- Introduce a new protocol called EDKII_HTTP_TLS_CONFIGURATION_DATA
- Upper layer application installs this protocol with their own TLS_CONFIG_DATA.
- TlsConfigureSession locates EDKII_HTTP_TLS_CONFIGURATION_DATA to replace the default TLS_CONFIG_DATA.

This way we can remove that hardcoded code and fix the root cause, also the upper layer application do not have to take the burden.
What do you think?
Thanks
Abner


>
> The implementation could plausibly construct and enqueue the
> ClientHello, in which case it would be too late to modify the cipher
> suite list, but any attempt to verify the hostname definitely can't
> happen until a lot of network I/O has taken place.


>
> Good luck! :)
>
> Thanks,
>
> Michael



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113000): https://edk2.groups.io/g/devel/message/113000
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]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-12-29 15:07 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-26 11:28 [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS policy Chang, Abner via groups.io
2023-12-26 11:28 ` [edk2-devel] [RFC][PATCH 1/2] NetworkPkg: EDKII HTTPS platform " Chang, Abner via groups.io
2023-12-26 11:28 ` [edk2-devel] [RFC][PATCH 2/2] NetworkPkg: Check " Chang, Abner via groups.io
2023-12-27 15:55 ` [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform " Michael Brown
2023-12-28  2:47   ` Chang, Abner via groups.io
2023-12-28 14:16     ` Michael Brown
2023-12-28 15:04       ` Chang, Abner via groups.io
2023-12-28 15:31         ` Michael Brown
2023-12-28 23:37           ` Chang, Abner via groups.io
2023-12-29  0:01             ` Michael Brown
2023-12-29 15:07               ` Chang, Abner via groups.io [this message]
2023-12-30 11:31                 ` Chang, Abner via groups.io
2024-01-01 23:07                 ` Michael Brown
2024-01-02  6:06                   ` Chang, Abner via groups.io
2024-01-02 12:42                     ` Michael Brown
2024-01-02 16:31                       ` Chang, Abner via groups.io
2024-01-02 17:46                         ` Michael Brown
2024-01-04  3:13                           ` Chang, Abner via groups.io
2024-01-05  8:41                         ` Chang, Abner via groups.io
2024-01-05 17:16                           ` Michael Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR12MB39667B61B8AF57340295961EEA9DA@MN2PR12MB3966.namprd12.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox