On 1/29/2015 1:16 PM, James Peach wrote:
On Jan 27, 2015, at 9:58 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
On 1/27/2015 11:12 AM, James Peach wrote:
On Jan 27, 2015, at 8:34 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
On 1/27/2015 10:30 AM, James Peach wrote:
On Jan 27, 2015, at 8:18 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
Originally, I was planning on leaving in plugin support for both the SNI
callback and the cert callback. But as I reflect, I question that decision. I
think it adds complexity without giving more power to the plugin writer.
Both callbacks take place at the same point in the handshake. From both
callbacks you can set the certificate. Depending on the version and patch
level, only one of the callbacks will let you pause processing.
Perhaps it is better to support only point for the plugin to callback after the
client hello during the handshake processing? If we did that, ATS could adapt
depending on the linked version of openssl and the plugin would not change.
I'd still add a TS_SSL_CERT_HOOK for clarity, but I'd make it the same value as
TS_SSL_SNI_HOOK.
Why do you need to make this change? What is the compatibility impact?
Well we do need to support the certificate callbacks in openssl 1.0.2, so we
have a means to pause handshake processing to load certificates, etc in a stock
version of openssl.
Sorry I wasn't especially clear. I intended to ask why we need to change the
hook name? Are the hooks so different that we can't do the right thing under
the covers?
Ultimately, I think the name TS_SSL_CERT_HOOK is clearer. From the plugin
writer's perspective, the callback is being used for certificate processing.
But I'm proposing keeping TS_SSL_SNI_HOOK and just having TS_SSL_CERT_HOOK as
an alias for the time being.
If openssl 1.0.1 is linked, it would execute the plugin's callback during the
SNI callback. If openssl 1.0.2 is linked, it would execute the plugin's
callback during the certificate callback.
Did openssl 1.0.1 contain your patch? If there is no released version of
openssl that contains the original callback you added, what is is that we need
to support?
My patch was not rolled into open ssl. The only reason to continue to support
it is that we had previously supported it. If you are unable to move to
openssl 1.0.2, then at least you can patch up openssl 1.0.1 (though if you can
run with a patched version you can likely upgrade too).
My second idea, would have the least impact upon people who have already
invested effort in writing plugins on the SNI callback.
Judging from your questions, you don't see a reason to support both a SNI
callback and a certificate callback either. Is that right?
I don't really know. Are they different in the new OpenSSL API?
The certificate callback does more since it is also called on client
certificate processing (if that is involved in the handshake).
On reflection, I don't think the SNI callback does anything more for us than
the certificate callback. The servername is available in both. Both are
executed after the client hello before ATS sends out any handshake messages.
Ok, then I think we should remove support for the non-upstream patch ASAP.
The I'm writing things, if you have openssl 1.0.2, the
TS_SSL_CERT_HOOK/TS_SSL_SNI_HOOK will be triggered from the certificate
callback.
Otherwise it will be triggered from the SNI callback. The server side
cert callback does not exist before 1.0.2. If you have the 1.0.1 patch
installed, you can pause processing from the callback.
In practice, I would assume most people who care to pause processing at
this point will move to openssl 1.0.2.
J
