[AMD Official Use Only - General] I am going to withdraw this patch set and replaced by https://edk2.groups.io/g/devel/message/113004.
Thanks Abner > -----Original Message----- > From: Chang, Abner > Sent: Friday, December 29, 2023 11:08 PM > To: Michael Brown <mc...@ipxe.org>; devel@edk2.groups.io > Cc: Saloni Kasbekar <saloni.kasbe...@intel.com>; Zachary Clark-williams > <zachary.clark-willi...@intel.com>; Nickle Wang <nick...@nvidia.com>; Igor > Kulchytskyy <ig...@ami.com> > Subject: RE: [edk2-devel] [RFC][PATCH 0/2] Introduce HTTPS Platform TLS > policy > > > > > -----Original Message----- > > From: Michael Brown <mc...@ipxe.org> > > Sent: Friday, December 29, 2023 8:01 AM > > To: devel@edk2.groups.io; Chang, Abner <abner.ch...@amd.com> > > Cc: Saloni Kasbekar <saloni.kasbe...@intel.com>; Zachary Clark-williams > > <zachary.clark-willi...@intel.com>; Nickle Wang <nick...@nvidia.com>; > Igor > > Kulchytskyy <ig...@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 (#113010): https://edk2.groups.io/g/devel/message/113010 Mute This Topic: https://groups.io/mt/103368438/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
