These'll get removed once most of renego support is gone, but this is to prove
removing the warning alert from the previous commit still prevents legacy
renegotiations.
Change-Id: I7d9d95e1d4c5d23d3b6d170938a5499a65f2d5ea
Reviewed-on: https://boringssl-review.googlesource.com/2236
Reviewed-by: Adam Langley <agl@google.com>
Ensure that the client rejects it with UNEXPECTED_MESSAGE, not by attempting to
decode it.
Change-Id: Ifc5613cf1152e0f7dcbee73e05df1ef367dfbfd5
Reviewed-on: https://boringssl-review.googlesource.com/2232
Reviewed-by: Adam Langley <agl@google.com>
There's not much point in retaining the identity hint in the SSL_SESSION. This
avoids the complexity around setting psk_identity hint on either the SSL or the
SSL_SESSION. Introduce a peer_psk_identity_hint for the client to store the one
received from the server.
This changes the semantics of SSL_get_psk_identity_hint; it now only returns
the value configured for the server. The client learns the hint through the
callback. This is compatible with the one use of this API in conscrypt (it
pulls the hint back out to pass to a callback).
Change-Id: I6d9131636b47f13ac5800b4451436a057021054a
Reviewed-on: https://boringssl-review.googlesource.com/2213
Reviewed-by: Adam Langley <agl@google.com>
This is an experimental flag that dates back to SSLeay 0.8.1b or earlier. It's
never set internally and never set in consumers.
Change-Id: I922583635c9f3d8d93f08f1707531ad22a26ae6a
Reviewed-on: https://boringssl-review.googlesource.com/2214
Reviewed-by: Adam Langley <agl@google.com>
At the record layer, DTLS maintains a window of seen sequence numbers to detect
replays. Add tests to cover that case. Test both repeated sequence numbers
within the window and sequence numbers past the window's left edge. Also test
receiving sequence numbers far past the window's right edge.
Change-Id: If6a7a24869db37fdd8fb3c4b3521b730e31f8f86
Reviewed-on: https://boringssl-review.googlesource.com/2221
Reviewed-by: Adam Langley <agl@google.com>
If psk_len were 0, it would already have been an error earlier. The PSK cipher
suites don't lose the other_secret || psk construction if the PSK happens to be
empty.
Change-Id: I1917236720d0862658562bc8f014cb827ee9aed5
Reviewed-on: https://boringssl-review.googlesource.com/2233
Reviewed-by: Adam Langley <agl@google.com>
Server-side support was removed in 77a942b7fe,
but client-side support was retained as it appeared NSS supported this.
However, this is not the case: ssl3_HandleServerKeyExchange only allows a
ServerKeyExchange message if hs.ws is in an appropriate state.
ssl3_AuthCertificate only sets it to allow ServerKeyExchange if it is a key
exchange that normally uses it or if is_limited is set. is_limited is only set
for the export cipher suites.
Thus we can safely remove this without waiting on gathering UMA data.
BUG=chromium:400587
Change-Id: I9aefb742dbb2d99c13340ab48017e1ceee04bc2f
Reviewed-on: https://boringssl-review.googlesource.com/2230
Reviewed-by: Adam Langley <agl@google.com>
This was added in upstream's 82e610e2cfbbb5fd29c09785b6909a91e606f347. The
commit message cites draft-ietf-tls-renegotiation which was on
draft-ietf-tls-renegotiation-01 at the time. The text in question (6.2 Server
Considerations) is no longer in RFC 5746. The RFC now recommends terminating
the connection which is much simpler.
It also was wrong anyway as it checked s->ctx->options instead of s->options
for SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.
Removing that block will result in the connection being terminated in
ssl_scan_clienthello_tlsext.
Change-Id: Ie222c78babd3654c5023ad07ac0d8e0adde68698
Reviewed-on: https://boringssl-review.googlesource.com/2235
Reviewed-by: Adam Langley <agl@google.com>
Parameters like these should not change between 32-bit and 64-bit. 64 is also
the value recommended in RFC 6347, section 4.1.2.6. Document those fields while
I'm here.
Change-Id: I8481ee0765ff3d261a96a2e1a53b6ad6695b2d42
Reviewed-on: https://boringssl-review.googlesource.com/2222
Reviewed-by: Adam Langley <agl@google.com>
This was added in http://rt.openssl.org/Ticket/Display.html?id=2033 to support
a mode where a DTLS socket would statelessly perform the ClientHello /
HelloVerifyRequest portion of the handshake, to be handed off to a socket
specific to this peer address.
This is not used by WebRTC or other current consumers. If we need to support
something like this, it would be cleaner to do the listen portion (cookieless
ClientHello + HelloVerifyRequest) externally and then spin up an SSL instance
on receipt of a cookied ClientHello. This would require a slightly more complex
BIO to replay the second ClientHello but would avoid peppering the DTLS
handshake state with a special short-circuiting mode.
Change-Id: I7a413932edfb62f8b9368912a9a0621d4155f1aa
Reviewed-on: https://boringssl-review.googlesource.com/2220
Reviewed-by: Adam Langley <agl@google.com>
(Imported form upstream's 455b65dfab0de51c9f67b3c909311770f2b3f801 and
0d6a11a91f4de238ce533c40bd9507fe5d95f288)
Change-Id: Ia195c7fe753cfa3a7f8c91d2d7b2cd40a547be43
Imported from upstream's 9bed73adaa6f834177f29e478d9a2247a6577c04.
Upstream's commit appears to have been based on BoringSSL's commits to
improve the constant-time behaviour of RSA padding checks and thus I've
not tried to import those bits of the change.
Change-Id: I0ea5775b0f1e18741bbbc9f792a6af0d3d2a4caf
Pull constant-time methods out to a separate header, add tests.
(Imported from upstream's 9a9b0c0401cae443f115ff19921d347b20aa396b and
27739e92659d38cdefa21e51b7f52b81a7ac3388)
Change-Id: Id570f5c531aca791112929e6258989f43c8a78d7
State hanging off the SSL gets freed in two places.
Change-Id: I41a8d2a7cab35f0098396006e1f6380038ec471a
Reviewed-on: https://boringssl-review.googlesource.com/2212
Reviewed-by: Adam Langley <agl@google.com>
Also add a few other assertions.
Change-Id: Iae0c65802f4d05c7585e2790be5295f478e1f614
Reviewed-on: https://boringssl-review.googlesource.com/2210
Reviewed-by: Adam Langley <agl@google.com>
s->s3 is never NULL if an ssl3_* function is called, and we'll crash later
anyway. (This also makes scan-build stop believing it can be NULL.)
Change-Id: Ibf8433bd4d945f9bf5416d72946102a9e50d2787
Reviewed-on: https://boringssl-review.googlesource.com/2206
Reviewed-by: Adam Langley <agl@google.com>
Check the return value while we're here. This avoids some arithmetic and
appease scan-build's dead assignment flagger.
Change-Id: If3615076e091eb44b9e3e9d50cd64f80e645337e
Reviewed-on: https://boringssl-review.googlesource.com/2204
Reviewed-by: Adam Langley <agl@google.com>
Without SSL_MODE_AUTO_RETRY, even blocking mode will return
SSL_ERROR_WANT_{READ|WRITE} in the event of a renegotiation.
The comments in the code speak only of "nasty problems" unless this is
done. The original commit that added SSL_MODE_AUTO_RETRY
(54f10e6adce56eb2e59936e32216162aadc5d050) gives a little more detail:
The [...] behaviour is needed by applications such as s_client and
s_server that use select() to determine when to use SSL_read.
Without the -nbio flag, s_client will use select() to find when the
socket is readable and then call SSL_read with a blocking socket.
However, this will still block in the event of an incomplete record, so
the delay is already unbounded. This it's very unclear what the point of
this behaviour ever was.
Perhaps if the read and write paths were different sockets where the
read socket was non-blocking but the write socket was blocking. But that
seems like an implausible situation to worry too much about.
Change-Id: I9d9f2526afc2e0fd0e5440e9a047f419a2d61afa
Reviewed-on: https://boringssl-review.googlesource.com/2140
Reviewed-by: Adam Langley <agl@google.com>
This code isn't compiled in. It seems there was some half-baked logic for a
7-byte alert that includes more information about handshake messages
retransmit.
No such alert exists, and the code had a FIXME anyway. If it gets resurrected
in DTLS 1.3 or some extension, we can deal with it then.
Change-Id: I8784ea8ee44bb8da4b0fe5d5d507997526557432
Reviewed-on: https://boringssl-review.googlesource.com/2121
Reviewed-by: Adam Langley <agl@google.com>
This code was dead as ssl3_get_client_certificate no longer allows a
ClientHello; the hash would be reset, but then the handshake would fail anyway.
Change-Id: Ib98e6a319c048c263d7ee3a27832ea57bdd0e2ad
Reviewed-on: https://boringssl-review.googlesource.com/2120
Reviewed-by: Adam Langley <agl@google.com>
This change adds support to the Go code for renegotiation as a client,
meaning that we can test BoringSSL's renegotiation as a server.
Change-Id: Iaa9fb1a6022c51023bce36c47d4ef7abee74344b
Reviewed-on: https://boringssl-review.googlesource.com/2082
Reviewed-by: Adam Langley <agl@google.com>
Minor change, but they're the users of the old API left within
BoringSSL.
Change-Id: Ic24e0d006c97fa5265abc3373d3f98aa8d2f8b1e
Reviewed-on: https://boringssl-review.googlesource.com/2100
Reviewed-by: Adam Langley <agl@google.com>
If generating the master secret or applying the PSK post-processing fails,
we'll double-free all the ECDH state.
Change-Id: Id52931af73bdef5eceb06f7e64d32fdda629521e
Reviewed-on: https://boringssl-review.googlesource.com/2063
Reviewed-by: Adam Langley <agl@google.com>
Like ssl3_get_client_key_exchange, it is split into three parts:
- If PSK, query the PSK and write out the PSK identity.
- Compute the base pre-master secret.
- If PSK, compute the final pre-master secret.
This also fixes some double-frees on malloc failures in the ECDHE case. And it
avoids using the handshake output buffer to start the premaster secret.
Change-Id: I8631ee33c1e9c19604b3dcce2c676c83893c308d
Reviewed-on: https://boringssl-review.googlesource.com/2062
Reviewed-by: Adam Langley <agl@google.com>
pskKeyAgreement is now a wrapper over a base key agreement.
Change-Id: Ic18862d3e98f7513476f878b8df5dcd8d36a0eac
Reviewed-on: https://boringssl-review.googlesource.com/2053
Reviewed-by: Adam Langley <agl@google.com>
The current implementation switches the order of other_secret and psk;
other_secret is first. Fix it and rewrite with CBB instead. The server half got
fixed on accident in a prior refactor.
Change-Id: Ib52a756aadd66e4bf22c66794447f71f4772da09
Reviewed-on: https://boringssl-review.googlesource.com/2052
Reviewed-by: Adam Langley <agl@google.com>
Only the three plain PSK suites for now. ECDHE_PSK_WITH_AES_128_GCM_SHA256 will
be in a follow-up.
Change-Id: Iafc116a5b2798c61d90c139b461cf98897ae23b3
Reviewed-on: https://boringssl-review.googlesource.com/2051
Reviewed-by: Adam Langley <agl@google.com>
Deprecate the old two-pass version of the function. If the ticket is too long,
replace it with a placeholder value but keep the connection working.
Change-Id: Ib9fdea66389b171862143d79b5540ea90a9bd5fb
Reviewed-on: https://boringssl-review.googlesource.com/2011
Reviewed-by: Adam Langley <agl@google.com>
The old ones inverted their return value. Add SSL_(CTX_)set_srtp_profiles which
return success/failure correctly and deprecate the old functions. Also align
srtp.h with the new style since it's very short.
When this rolls through, we can move WebRTC over to the new ones.
Change-Id: Ie55282e8858331910bba6ad330c8bcdd0e38f2f8
Reviewed-on: https://boringssl-review.googlesource.com/2060
Reviewed-by: Adam Langley <agl@google.com>
Doing some archeaology, since the initial OpenSSL commit, key_arg has been
omitted from the serialization if key_arg_length was 0. Since this is an
SSLv2-only field and resuming an SSLv2 session with SSLv3+ is not possible,
there is no need to support parsing those sessions.
Interestingly, it is actually not the case that key_arg_length was only ever
set in SSLv2, historically. In the initial commit of OpenSSL, SSLeay 0.8.1b,
key_arg was used to store what appears to be the IV. That was then removed in
the next commit, an import of SSLeay 0.9.0b, at which point key_arg was only
ever set in SSLv3. That is old enough that there is certainly no need to
parse pre-SSLeay-0.9.0b sessions...
Change-Id: Ia768a2d97ddbe60309be20e2efe488640c4776d9
Reviewed-on: https://boringssl-review.googlesource.com/2050
Reviewed-by: Adam Langley <agl@google.com>
No more need for all the macros. For now, this still follows the two-pass i2d_*
API despite paying a now-unnecessary malloc. The follow-on commit will expose a
more reasonable API and deprecate this one.
Change-Id: I50ec63e65afbd455ad3bcd2f1ae3c782d9e8f9d2
Reviewed-on: https://boringssl-review.googlesource.com/2000
Reviewed-by: Adam Langley <agl@google.com>
Do away with all those unreadable macros. Also fix many many memory leaks in
the SSL_SESSION reuse case. Add a number of helper functions in CBS to help
with parsing optional fields.
Change-Id: I2ce8fd0d5b060a1b56e7f99f7780997fabc5ce41
Reviewed-on: https://boringssl-review.googlesource.com/1998
Reviewed-by: Adam Langley <agl@google.com>
There's only one caller and it doesn't use that feature. While I'm here, tidy
that function a little. Don't bother passing FALLBACK_SCSV into
ssl3_get_cipher_by_value.
Change-Id: Ie71298aeaaab6e24401e0a6c2c0d2281caa93ba4
Reviewed-on: https://boringssl-review.googlesource.com/2030
Reviewed-by: Adam Langley <agl@google.com>
There's no need to store them on the session. They're temporary handshake
state and weren't serialized in d2i_SSL_SESSION anyway.
Change-Id: I830d378ab49aaa4fc6c4c7a6a8c035e2263fb763
Reviewed-on: https://boringssl-review.googlesource.com/1990
Reviewed-by: Adam Langley <agl@google.com>
This removes the need to track the client cipher list in the SSL_SESSION. It
also eliminates a field in SSL_SESSION that wasn't serialized by
i2d_SSL_SESSION. It's only used to implement SSL_get_shared_ciphers which is
only used by debug code.
Moreover, it doesn't work anyway. The SSLv2 logic pruned that field to the
common ciphers, but the SSLv3+ logic just stores the client list as-is. I found
no internal callers that were actually compiled (if need be we can stub in
something that always returns the empty string or so).
Change-Id: I55ad45964fb4037fd623f7591bc574b2983c0698
Reviewed-on: https://boringssl-review.googlesource.com/1866
Reviewed-by: Adam Langley <agl@google.com>
