[AMD Official Use Only - General] > -----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 (#113000): https://edk2.groups.io/g/devel/message/113000 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] -=-=-=-=-=-=-=-=-=-=-=-
