Update libssl to NSS 3.18 RTM

Update the bundled libssl to NSS 3.18 RTM

BUG=469516
Committed: https://crrev.com/d5139059122edc3c22dfa0e60ad2e4d3167e27fc
Cr-Commit-Position: refs/heads/master@{#323840}

[Ryan Sleevi, 2015-04-02 23:35:39]

rsleevi@chromium.org changed reviewers:
+ davidben@chromium.org

[Ryan Sleevi, 2015-04-02 23:35:40]

David: For your review
wtc: FYI

There are three patches I seem to have botched, but as I mentioned, my uprev
staging dir has completely hosed in git. With the provision of fixing these
three, I think we're good.

As also mentioned, it might be easier to git cl patch locally and then use your
favourite diff viewer with ignore-whitespace on. Upstream's gone through some
churn (or my git & hg dirs are even more messed up than I realized)

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
File net/third_party/nss/ssl/ssl3con.c (left):

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
net/third_party/nss/ssl/ssl3con.c:5399: }
David: Do you recall if there were ordering issues with the order in which the
SCSV appeared?

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
File net/third_party/nss/ssl/ssl3ext.c (left):

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
net/third_party/nss/ssl/ssl3ext.c:308: { ssl_signature_algorithms_xtn,
&ssl3_ClientSendSigAlgsXtn }
this is the other bug; I'm not sure how my patch merge dropped this change

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
File net/third_party/nss/ssl/sslenum.c (right):

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
net/third_party/nss/ssl/sslenum.c:49: * the third one.
Oops, botched this.

[Ryan Sleevi, 2015-04-03 05:19:20]

OK, good to review now. Patch snafus fixed, streamlined my process a little for
generating them. Hooray for git and bash.

[davidben, 2015-04-03 19:06:18]

lgtm. I'm super-dubious of this draft-TLS-1.3 code, but it's fine because we
won't be enabling it.

I didn't review the patches or the whitespaced version of the diff. (I can't
read diffdiffs.) I'm assuming that the patches and script correctly produce this
end state.

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
File net/third_party/nss/ssl/ssl3con.c (left):

https://codereview.chromium.org/1053903002/diff/1/net/third_party/nss/ssl/ssl...
net/third_party/nss/ssl/ssl3con.c:5399: }
On 2015/04/02 23:35:40, Ryan Sleevi wrote:
> David: Do you recall if there were ordering issues with the order in which the
> SCSV appeared?

Not that I'm aware of. I've heard rumors that there are servers which only pay
attention to the last byte, so putting it at the end is probably prudent. But I
see no other cipher suite in IANA's registry that ends in 0x00, so it should be
fine.

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/REA...
File net/third_party/nss/README.chromium (left):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/REA...
net/third_party/nss/README.chromium:106: patches/reorderextensions.patch
This patch wasn't dropped.

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/dtlscon.c (right):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/dtlscon.c:97: return SSL_LIBRARY_VERSION_TLS_1_2 + 1;
(1_3? Hopefully all this draft-1.3 code doesn't do anything or we have worse
problems, but that's fishy.)

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/ssl.h (right):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl.h:189: #define SSL_REUSE_SERVER_ECDHE_KEY 27
Follow-up: we probably should unset this in SSLServerSocketNSS and WebRTC.

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/ssl3con.c (right):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:677: case
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305:
I believe these two want to go in line 688.

I'm extremely suspicious of this logic. It looks completely wrong. If you even
*support* draft-TLS-1.3, you can't *advertise* non-PFS+AEAD ciphers? I would
think it's only if the server picks it. Also the export block doesn't have this
check, so apparently advertising draft-TLS-1.3 still allows you to advertise
export ciphers.

Not that we care. Hopefully we'll be done with NSS before TLS 1.3 stops
changing.

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:945:
PORT_SetError(SSL_ERROR_UNSUPPORTED_VERSION);
NOTE: This changes an error code we care about. However, we map it to the same,
so it's fine. In fact, now that NSS and BoringSSL both distinguish this case
(the gave back too low a version), it may be worth distinguishing it on our end
as a follow-up so we can give different errors for "the server gave a
handshake_failure, presumably because it didn't like our version or cipher
suites" and "the server gave a ServerHello, but it responded with SSL 3.0, so we
don't like it".

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:9159: };
(Hrm. Looks like this code used to just get it wrong outright? I don't see a
corresponding change elsewhere.)

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/ssl3ext.c (right):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3ext.c:994: }
Weird. Looks like this was done as part of
https://bugzilla.mozilla.org/show_bug.cgi?id=753136

BoringSSL treats this as fatal right now. No evidence of issues. Being strict
here seems much more prudent. RFC 5077 does not say the server can use a
non-empty one.

[Ryan Sleevi, 2015-04-03 20:48:25]

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
File net/third_party/nss/ssl/ssl3con.c (right):

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:677: case
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305:
On 2015/04/03 19:06:18, David Benjamin wrote:
> I believe these two want to go in line 688.
> 

Fair enough. It has no ill effect.

> I'm extremely suspicious of this logic. It looks completely wrong. If you even
> *support* draft-TLS-1.3, you can't *advertise* non-PFS+AEAD ciphers? I would
> think it's only if the server picks it. Also the export block doesn't have
this
> check, so apparently advertising draft-TLS-1.3 still allows you to advertise
> export ciphers.

Hah! Should mention this to ekr if you want.

> 
> Not that we care. Hopefully we'll be done with NSS before TLS 1.3 stops
> changing.

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:945:
PORT_SetError(SSL_ERROR_UNSUPPORTED_VERSION);
On 2015/04/03 19:06:18, David Benjamin wrote:
> NOTE: This changes an error code we care about. However, we map it to the
same,
> so it's fine. In fact, now that NSS and BoringSSL both distinguish this case
> (the gave back too low a version), it may be worth distinguishing it on our
end
> as a follow-up so we can give different errors for "the server gave a
> handshake_failure, presumably because it didn't like our version or cipher
> suites" and "the server gave a ServerHello, but it responded with SSL 3.0, so
we
> don't like it".

yup

https://codereview.chromium.org/1053903002/diff/40001/net/third_party/nss/ssl...
net/third_party/nss/ssl/ssl3con.c:9159: };
On 2015/04/03 19:06:18, David Benjamin wrote:
> (Hrm. Looks like this code used to just get it wrong outright? I don't see a
> corresponding change elsewhere.)

yup

[Ryan Sleevi, 2015-04-03 20:53:42]

The CQ bit was checked by rsleevi@chromium.org

[Ryan Sleevi, 2015-04-03 20:53:43]

The patchset sent to the CQ was uploaded after l-g-t-m from
davidben@chromium.org
Link to the patchset: https://codereview.chromium.org/1053903002/#ps80001
(title: "Fix typo")

[commit-bot: I haz the power, 2015-04-03 20:54:18]

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

[commit-bot: I haz the power, 2015-04-03 22:47:06]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2015-04-03 22:52:48]

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