> 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. J
