I was mostly under the impression that Matt Caswell was planning to add
a generic "early callback" that gets called just after extensions are
read but before they are processed, and was waiting to see what that
looked like and whether the same API could be reasonably backported to
1.1.0 (not necessarily in the upstream repo, of course).  But I also
haven't had a chance to work through the extensions processing revamp
that landed this week, yet.

Just moving the existing servername_callback earlier is rather
non-trivial, since it expects to be able to reach into the session in
various ways, and of course there's no session yet.  Some things can be
worked around, like SSL_get_servername(), but I'm not sure I can
enumerate all the things that existing servername_callbacks are supposed
to be able to do, so it's hard to be confident that I can move the
servername_callback that early without introducing regressions somewhere.

-Ben

On 12/09/2016 04:41 PM, Fedor Indutny wrote:
> Oh, just to restate it. I'm willing to submit the patch if we agree on
> what exactly it should do.
>
> On Fri, Dec 9, 2016 at 11:29 PM, Fedor Indutny <fe...@indutny.com
> <mailto:fe...@indutny.com>> wrote:
>
>     Hello Benjamin,
>
>     On Fri, Dec 9, 2016 at 11:24 PM, Benjamin Kaduk <bka...@akamai.com
>     <mailto:bka...@akamai.com>> wrote:
>
>         On 12/09/2016 01:43 PM, Fedor Indutny wrote:
>>         Hello,
>>
>>         During development of one feature for my TLS proxy bud, I
>>         have discovered that the cert_cb is invoked only for newly
>>         generated tickets/sessions. The reasoning behind this is
>>         clear, but I believe that it is most likely needs a revision.
>>         Here is my reasoning:
>>
>>         The major use case is choosing a certificate/private key
>>         either dynamically (based on various parameters of SSL
>>         structure) or asynchronously (by
>>         using SSL_ERROR_WANT_X509_LOOKUP). However when the TLS
>>         ticket is provided by the client, it will be parsed and
>>         loaded using the ticket key from the main context, without
>>         giving a way for application to override it for particular
>>         servername (from SNI). Furthermore, with the TLS ticket
>>         provided application can no longer chose to provide a
>>         different certificate in case of expiration or revocation.
>>
>
>         If you had a callback that ran before session resumption
>         (possibly the existing SNI callback, possibly a new callback),
>         would that allow you to solve your problem?  I would very much
>         like to see such an early callback so as to be able to do SNI
>         processing before resumption, possibly even before version
>         negotiation.  (And yes, I should put my money where my mouth
>         is and come up with a patch.)
>
>
>     That's exactly what I am asking for. Putting it before session
>     resumption will be enough for my use case, though.
>
>     Thank you,
>     Fedor.
>      
>
>
>         -Ben
>
>         --
>         openssl-dev mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-dev
>         
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DgMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=sbnZWkN6RGNdcWHXUctjpQ0dDo4FpOmhAvXjeqlWq5A&s=l0X6ypyf5fI7pSlZ5EV9nBMPp-xa-2XNJGj-sONAPho&e=>
>
>
>
>
>

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Reply via email to