Allow NPN enable on a per-SSL connection basis...

Allow NPN enable on a per-SSL connection basis
Also moves the NPN / snap start function declerations under OPENSSL_NO_TLSEXT guard (to match their definitions)

This is needed for http://codereview.chromium.org/5728001/

[joth, 2010-12-09 18:48:15]

agl, what's the best way to go about patches to openssl's npn code.
Do them here, then upstream?
I need to fixup the .patches too. Should I make a new .patch ontop the existing
ones, or rollout the snap start and update next_proto_neg.patch ?

Cheers!

[agl, 2010-12-09 18:56:35]

Before reviewing the code, I want to understand the motivation.

The callback gets an SSL* passed in. From there you should be able to access any
structures needed in order to determine and adjust the NPN selection. (You can
stick an opaque pointer in the SSL*).

So, why do you need this?

[joth, 2010-12-09 19:31:53]

On 9 December 2010 18:56, <agl@chromium.org> wrote:

> Before reviewing the code, I want to understand the motivation.
>
> The callback gets an SSL* passed in. From there you should be able to
> access any
> structures needed in order to determine and adjust the NPN selection. (You
> can
> stick an opaque pointer in the SSL*).
>
> So, why do you need this?
>
>
>
It fixes a todo in http://codereview.chromium.org/5728001/ about avoiding
getting the callback on sockets that don't want to use NPN.

AIUI calling SSL_CTX_set_next_proto_select_cb means *all* client connections
on that CTX will send the NPN request, and we're oblidged to reply with a
protocol choice when the callback arrives, even if that specific SSL did not
want to use NPN. Rather than take the pot-luck guess that http/1.1 is the
appropriate choice, this allows us to enable NPN only on those SSLs that
need it. (I understand that in current usage chrome will either always or
never request npn, but wanted to future proof it in case this policy
decision changes)

Lemme know if I'm worrying about an impossible situation.

[agl, 2010-12-09 19:34:50]

On Thu, Dec 9, 2010 at 2:31 PM, Jonathan Dixon <joth@chromium.org> wrote:
> It fixes a todo in http://codereview.chromium.org/5728001/ about avoiding
> getting the callback on sockets that don't want to use NPN.
> AIUI calling SSL_CTX_set_next_proto_select_cb means *all* client connections
> on that CTX will send the NPN request, and we're oblidged to reply with a
> protocol choice when the callback arrives, even if that specific SSL did not
> want to use NPN. Rather than take the pot-luck guess that http/1.1 is the
> appropriate choice, this allows us to enable NPN only on those SSLs that
> need it. (I understand that in current usage chrome will either always or
> never request npn, but wanted to future proof it in case this policy
> decision changes)
> Lemme know if I'm worrying about an impossible situation.

We should always enable NPN and negotiate with "http/1.1" if that's
what we're doing. I don't think the extension should appear and
disappear.


AGL