Sure. I don't have our specific use case in the PR. Only a test (ssl_hook_test.cc) to exercise the underlying hooks.
Our goal is to allow a plugin to arbitrarily change some config selected attribute of an outgoing SSL object before Traffic Server sends the Client Hello. For example, change the client certificate it will offer. We can set that value in records.config and override it in ssl_server_.name.yaml, but perhaps we have an even more dynamic scenario and want a plugin to set the client_certificate file. With the changes in this PR, we should be able to create a plugin that creates a continuation that gets called on the TS_EVENT_VCONN_OUTBOUND_START hook. From that callback we get a reference to the TSVConn corresponding to the newly created outbound connection. We can use the new API TSNetInvokingTxnGet(vconn) to retrieve the TSHttpTxn (HttpSM) that created the outbound connection request. From that transaction object we should be able to fetch any headers and URL's to determine what client certificate we want to use. Then the code calls TSVConnSSLConnectionGet(vconn) to get the TSSslConnection object that the code can cast to (SSL *) and use whatever openssl API call it needs to update the client certificate file. On Tue, Oct 9, 2018 at 6:27 PM Steven R. Feltner <sfelt...@godaddy.com> wrote: > I've browsed through the PR, and I see where you've used the proposed > hooks in ssl_hook_test.cc, but I am missing what the use case for these > hooks would be. Can you elaborate a bit? > > Thanks, > Steven > > On 10/9/18, 4:12 PM, "Susan Hinrichs" <shinr...@oath.com.INVALID> wrote: > > I am proposing changes to enable a plugin to access the outbound SSL > object > and override elements as it likes before the outgoing TLS handhake > completes. > > To acheive this, I have put up PR #4377, which adds the following hooks > * TS_VCONN_OUTBOUND_START_HOOK > * TS_VCONN_OUTBOUND_CLOSE_HOOK > These are analogous to the TS_VCONN_START_HOOK and TS_VCONN_CLOSE hook, > except that they apply to the outbound connections instead of the > inbound > connections. The START hook can be delayed and restarted. The CLOSE > hooks > must be reenabled immediately. The callback is given the TSVConn of > the > outbound connection. > > In addition, I propose the following new Plugin APIs to fetch > continuation > that requested the new outbound connection > > * TSCont TSNetInvokingContGet(TSVConn conn) > > * TSHttpTxn TSNetInvokingTxnGet(TSVConn conn) > > > Please review and share your thoughts. > > > Thanks, > > Susan > > >
