Merge the server-side support of ALPN from the NSS upstream.

Merge the server-side support of ALPN from the NSS upstream.

NSS upstream patches:
https://hg.mozilla.org/projects/nss/rev/2cb5c73ac307
https://hg.mozilla.org/projects/nss/rev/544eb0f50d40

R=agl@chromium.org
BUG=416841
Committed: https://crrev.com/c9089fa21c59d9797398e660e4943b9423db1296
Cr-Commit-Position: refs/heads/master@{#297772}

[wtc, 2014-09-23 12:53:21]

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/SSLe...
File net/third_party/nss/ssl/SSLerrs.h (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/SSLe...
net/third_party/nss/ssl/SSLerrs.h:422:
ER3(SSL_ERROR_INAPPROPRIATE_FALLBACK_ALERT, (SSL_ERROR_BASE + 131),

Since the TLS_FALLBACK_SCSV has also been committed in the NSS upstream, I
decided to reorder the error codes so that these three error codes have the same
values as in the NSS upstream, and move the three Channel ID error codes to the
end of the list.

[wtc, 2014-09-26 16:39:20]

Adam: please review this CL. Thanks!

[agl, 2014-09-26 17:39:46]

Sorry, this got lost in perf and the signature verification release.

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:658: /* The callback might say OK, but then
it's picked a default.
It's acceptable for ALPN too. Most implementations will pretend not to support
ALPN if they don't recognise any of the protocols. The callback should be able
to pass on unknown protocols.

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:886: /* we're in over our heads if any of
these fail */
This comment isn't useful.

[wtc, 2014-09-26 18:12:00]

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:658: /* The callback might say OK, but then
it's picked a default.

On 2014/09/26 17:39:46, agl wrote:
> It's acceptable for ALPN too. Most implementations will pretend not to support
> ALPN if they don't recognise any of the protocols. The callback should be able
> to pass on unknown protocols.

Are you suggesting that we should delete this if statement (lines 656 - 664)?

I will ask Martin Thomson why he added this if statement.

[agl, 2014-09-26 18:14:53]

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:658: /* The callback might say OK, but then
it's picked a default.
On 2014/09/26 18:12:00, wtc wrote:
> 
> On 2014/09/26 17:39:46, agl wrote:
> > It's acceptable for ALPN too. Most implementations will pretend not to
support
> > ALPN if they don't recognise any of the protocols. The callback should be
able
> > to pass on unknown protocols.
> 
> Are you suggesting that we should delete this if statement (lines 656 - 664)?
> 
> I will ask Martin Thomson why he added this if statement.

I imagine that he's following the wording of the RFC. But, in practice, everyone
wants the ability to be able to skip ALPN if the client's protocol is
unrecognised. I think NSS should be able to do that.

However, if that's going to take a while, I think it's find to land as is and
possibly resync with NSS again later.

[wtc, 2014-09-26 18:16:57]

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:658: /* The callback might say OK, but then
it's picked a default.

OK, I took a quick look. This if statement is the only place in the patch that
uses the no_application_protocol alert. So I believe it is intended to implement
the requirement in RFC 7301 Section 3.2 for the server to send a fatal
no_application_protocol alert under this condition:

http://tools.ietf.org/html/rfc7301#section-3.2

[wtc, 2014-09-29 17:59:11]

Adam: please review patch set 2. Thanks.

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:658: /* The callback might say OK, but then
it's picked a default.

On 2014/09/26 18:14:53, agl wrote:
>
> I imagine that he's following the wording of the RFC. But, in practice,
everyone
> wants the ability to be able to skip ALPN if the client's protocol is
> unrecognised. I think NSS should be able to do that.
> 
> However, if that's going to take a while, I think it's find to land as is and
> possibly resync with NSS again later.

Yes, I'd like to merge the current NSS upstream as is. I'll start an email to
discuss this issue.

https://codereview.chromium.org/595823003/diff/1/net/third_party/nss/ssl/ssl3...
net/third_party/nss/ssl/ssl3ext.c:886: /* we're in over our heads if any of
these fail */
On 2014/09/26 17:39:46, agl wrote:
> This comment isn't useful.

Done.

[wtc, 2014-10-02 00:56:07]

Adam: ping.

[agl, 2014-10-02 01:27:36]

lgtm

[wtc, 2014-10-02 01:44:45]

The CQ bit was checked by wtc@chromium.org

[commit-bot: I haz the power, 2014-10-02 01:45:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/595823003/20001

[commit-bot: I haz the power, 2014-10-02 02:41:48]

Committed patchset #2 (id:20001) as c30b16c016615b5c67cbee514473c846126b5cfc

[commit-bot: I haz the power, 2014-10-02 02:42:27]

Patchset 2 (id:??) landed as
https://crrev.com/c9089fa21c59d9797398e660e4943b9423db1296
Cr-Commit-Position: refs/heads/master@{#297772}