[API] Proposal for new TLS hooks on outbound connection and accessor functions

[Susan Hinrichs]

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

[Steven R. Feltner]

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" <***@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.

[Susan Hinrichs]

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.

Post by Steven R. Feltner
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
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

[Susan Hinrichs]

Alan also mentioned that these hooks might be useful to implement outbound
proxy protocol. However, at the moment, these hooks are only in place for
TLS connections. Would probably need to generalize them to deal with proxy
protocol over non-TLS connections.

Post by Susan Hinrichs
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.

Post by Steven R. Feltner
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
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

[Steven R. Feltner]

Thanks for the explanation and comments.

I am definitely +1 on this proposal.

Thanks,
Steven

On 10/10/18, 12:14 PM, "Susan Hinrichs" <***@oath.com.INVALID> wrote:

Alan also mentioned that these hooks might be useful to implement outbound
proxy protocol. However, at the moment, these hooks are only in place for
TLS connections. Would probably need to generalize them to deal with proxy
protocol over non-TLS connections.

Post by Susan Hinrichs
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.

Post by Steven R. Feltner
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
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