Unable to get certificate in TS_SSL_VERIFY_SERVER_HOOK

[CrendKing]

@shinrich Thanks for the recent commits about the TS_SSL_VERIFY_SERVER_HOOK. I tried to update our plugin to use the new hook. Unfortunately I found two problems of the current implementation. Could you please help verify?

1. Both TS_SSL_VERIFY_SERVER_HOOK and TS_VCONN_OUTBOUND_START_HOOK can only be global hook, not transaction hook. The advantage of transaction hook is that it can be used per remap rule. Imagine we have 100 remaps, only 1 of them uses this plugin. Instead of being able to add hook during TSRemapDoRemap on-demand, now we have to call TSNetInvokingTxnGet and get related fields to see if the connction needs special TLS verification, most of the time.
   I understand the document says TLS hook runs before HTTP transaction, thus TLS hooks can't be transaction hook, but I believe that doc is out of date. According to this, TS_SSL_VERIFY_SERVER_HOOK happens just barely before TS_HTTP_SEND_REQUEST_HDR_HOOK. Is it possible to make relevant TLS hooks transaction hooks?

2. Once inside the hook, we can only get the SSL * by calling TSVConnSSLConnectionGet (BTW, the documentation has wrong camel case typo). AFAIK, there is no way to server certificate X509 * from client side SSL *. All OpenSSL documentation and Google search suggest to use SSL_CTX_set_verify to get X509_STORE_CTX * in the callback. Unfortunately, the hook can't get either (ref). The test only used SSL_get_servername, whose information comes from the Hello message, not the server certificate. I could be wrong though.

[shinrich]

To your second point. SSL_get_peer_certificate should get the origin's certificate from the SSL object.
https://www.openssl.org/docs/man1.0.2/ssl/SSL_get_peer_certificate.html

About your first point, that is a good point. Since it is outbound, we could restrict it per transaction. Let me think about that a bit.

[shinrich]

Chatted a bit with @SolidWallOfCode and think perhaps the thing is to add plugin options to outbound actions in ssl_server_name rather than in remap.config.

So the proposal,

- fqdn: test.example.com
  verify_server_properties: SIGNATURE
  verify_server_callbacks:
  - plugin: myplugin.so
    args: [ "one", "/etc/random" ]
  - plugin: myotherplugin.so
    args: []

In this case, we specify that the myplugin.so and myotherplugin.so should be registered for the verify_server_cert hook if the outbound SNI name is test.example.com. Would that work for you case?

[CrendKing]

SSL_get_peer_certificate only returns the certificate AFTER the handshake is successfully completed. Since TS_SSL_VERIFY_SERVER_HOOK happens during handshake, you can't get the certificate yet.

For example, I have a program that hooks to both TS_SSL_VERIFY_SERVER_HOOK and TS_HTTP_READ_RESPONSE_HDR_HOOK. SSL_get_peer_certificate(ssl) already returns NULL in the first hook, but gives me server certificate in the second hook.

Regarding the suggestion to use ssl_server_name.yaml to limit the scope, my concern is flexibility. Remap rule is finer-grain than FQDN matching. I can think of use case where additional verifications are needed for some paths but not others, even they are served in the same host. For instance, https://host123.domain.com/login_service verifies the cert while https://host123.domain.com/faq does not. This usually happens for hosts with multi-tenant services.

I think this boils down to how much cost to make SSL hooks transactional vs implementing the proposal.

[shinrich]

Ok looks like I only tested with the server name, and my test was concentrating on exercising the stop handshake path. We could add another call to fetch the X509_STORE_CTX from the ssl object.

You are probably right that adding a hook via the transaction object would be useful for the SERVER_VERIFY hook and the OUTBOUND hooks. Let me think on how to wire that up.

[shinrich]

Coming back to this. Will add a means to get to the X509_STORE_CTX object from the callback.

[bryancall]

@shinrich Has this been done?

[shinrich]

Yes, this was addressed with commit f2519d1