CBB_init_fixed() should not call free because it can lead to use after
free or double free bugs. The caller should be responsible for
creating and destroying the buffer.
In the current code, ssl3_get_v2_client_hello() may free s->init_buf->data
via CBB_init_fixed(). It can also be freed via SSL_free(s) since
ssl3_get_v2_client_hello() doesn't set it to NULL and CBB_init_fixed()
can't set the caller's pointer to NULL.
Change-Id: Ia05a67ae25af7eb4fb04f08f20d50d912b41e38b
No behavior change. This is in preparation for buffering a flight of handshake
messages to reorder vigorously on flush.
Change-Id: Ic348829b340bf58d28f332027646559cb11046ac
Reviewed-on: https://boringssl-review.googlesource.com/3215
Reviewed-by: Adam Langley <agl@google.com>
It dates to 2000 from upstream and is only used when serving client auth to
Netscape. It will also get in the way when we get to merging DTLS and TLS
handshake functions because NETSCAPE_HANG_BUG is not valid for DTLS as it is
(the handshake fragmentation code will get confused).
Removing per comment on https://boringssl-review.googlesource.com/#/c/2602/
Change-Id: Ia2d086205bbfed002dc33b2203a47206f373b820
Reviewed-on: https://boringssl-review.googlesource.com/3214
Reviewed-by: Adam Langley <agl@google.com>
All but one field is a no-op.
Change-Id: Ib7bc59a12ce792d5e42fb6e04a4aff54f42643a9
Reviewed-on: https://boringssl-review.googlesource.com/3213
Reviewed-by: Adam Langley <agl@google.com>
This extends the packet adaptor protocol to send three commands:
type command =
| Packet of []byte
| Timeout of time.Duration
| TimeoutAck
When the shim processes a Timeout in BIO_read, it sends TimeoutAck, fails the
BIO_read, returns out of the SSL stack, advances the clock, calls
DTLSv1_handle_timeout, and continues.
If the Go side sends Timeout right between sending handshake flight N and
reading flight N+1, the shim won't read the Timeout until it has sent flight
N+1 (it only processes packet commands in BIO_read), so the TimeoutAck comes
after N+1. Go then drops all packets before the TimeoutAck, thus dropping one
transmit of flight N+1 without having to actually process the packets to
determine the end of the flight. The shim then sees the updated clock, calls
DTLSv1_handle_timeout, and re-sends flight N+1 for Go to process for real.
When dropping packets, Go checks the epoch and increments sequence numbers so
that we can continue to be strict here. This requires tracking the initial
sequence number of the next epoch.
The final Finished message takes an additional special-case to test. DTLS
triggers retransmits on either a timeout or seeing a stale flight. OpenSSL only
implements the former which should be sufficient (and is necessary) EXCEPT for
the final Finished message. If the peer's final Finished message is lost, it
won't be waiting for a message from us, so it won't time out anything. That
retransmit must be triggered on stale message, so we retransmit the Finished
message in Go.
Change-Id: I3ffbdb1de525beb2ee831b304670a3387877634c
Reviewed-on: https://boringssl-review.googlesource.com/3212
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit c67a3ae6ba. With a
deterministic clock, we can now go back to being strict about retransmits. Our
tests will now require that the shim only retransmit when we expect it to.
Change-Id: Iab1deb9665dcd294790c8253d920089e83a9140c
Reviewed-on: https://boringssl-review.googlesource.com/3211
Reviewed-by: Adam Langley <agl@google.com>
This is so the tests needn't be sensitive to the clock. It is, unfortunately, a
test-only hook, but the DTLS retransmit/timeout logic more-or-less requires it
currently. Use this hook to, for now, freeze the clock at zero. This makes the
tests deterministic.
It might be worth designing a saner API in the future. The current one,
notably, requires that the caller's clock be compatible with the one we
internally use. It's also not clear whether the caller needs to call
DTLSv1_handle_timeout or can just rely on the state machine doing it internally
(as it does do). But mock clocks are relatively tame and WebRTC wants to
compile against upstream OpenSSL for now, so we're limited in how much new API
we can build.
Change-Id: I7aad51570596f69275ed0fc1a8892393e4b7ba13
Reviewed-on: https://boringssl-review.googlesource.com/3210
Reviewed-by: Adam Langley <agl@google.com>
When addressing [1], I checked the AEAD code but brain-farted: a key is
aligned in that code, but it's the Poly1305 key, which doesn't matter
here.
It would be nice to align the ChaCha key too, but Android doesn't have
|posix_memalign| in the versions that we care about. It does have
|memalign|, but that's documented as "obsolete" and we don't have a
concept of an Android OS yet and I don't want to add one just for this.
So this change uses the buffer for loading the key again.
(Note that we never used to check for alignment of the |key| before
calling this. We must have gotten it for free somehow when checking the
alignment of |in| and |out|. But there are clearly some paths that don't
have an aligned key:
https://code.google.com/p/chromium/issues/detail?id=454308.)
At least the generation script started paying off immediately ☺.
[1] https://boringssl-review.googlesource.com/#/c/3132/1/crypto/chacha/chacha_vec.c@185
Change-Id: I4f893ba0733440fddd453f9636cc2aeaf05076ed
Reviewed-on: https://boringssl-review.googlesource.com/3270
Reviewed-by: Adam Langley <agl@google.com>
Thanks to an anonymous bug report.
Change-Id: Icdde78c82c8ee13fb64e0124712b240295677f63
Reviewed-on: https://boringssl-review.googlesource.com/3260
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Android didn't have getauxval until Jelly Bean (4.1). This means that
BoringSSL running on older Androids won't be able to detect NEON
support. (This is moot for Chromium because Chromium calls
android_getCpuFeatures and sets the NEON flag itself, but other users of
BoringSSL on Android probably won't do that.)
This change mirrors a little of what upstream does and tries running a
NEON instruction with a handler for SIGILL installed.
Change-Id: I853b85c37ffb049b240582d71fcf07adedc37a30
Reviewed-on: https://boringssl-review.googlesource.com/3190
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Including string.h in base.h causes any file that includes a BoringSSL
header to include string.h. Generally this wouldn't be a problem,
although string.h might slow down the compile if it wasn't otherwise
needed. However, it also causes problems for ipsec-tools in Android
because OpenSSL didn't have this behaviour.
This change removes string.h from base.h and, instead, adds it to each
.c file that requires it.
Change-Id: I5968e50b0e230fd3adf9b72dd2836e6f52d6fb37
Reviewed-on: https://boringssl-review.googlesource.com/3200
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
|num_rounds| is neither a parameter nor manifest constant.
Change-Id: I6c1d3a3819731f53fdd01eef6bb4de8a45176a1d
Reviewed-on: https://boringssl-review.googlesource.com/3180
Reviewed-by: Adam Langley <agl@google.com>
Obviously I shouldn't be doing this by hand each time.
Change-Id: I64e3f5ede5c47eddbff3b18172a95becc681b486
Reviewed-on: https://boringssl-review.googlesource.com/3170
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
I put the header back, but missed the #endif at the end of the file.
Regenerating this is clearly too error prone – I'll write a script to do
it for the future.
Change-Id: I06968c9f7a4673f5942725e727c67cb4e01d361a
A handful of latin-1 codepoints existed a trio of files. This change
switches the encoding to UTF-8.
Change-Id: I00309e4d1ee3101e0cc02abc53196eafa17a4fa5
The special-case in HMAC is no longer needed. Test that HMAC_CTX is initialized
with the zero key.
Change-Id: I4ee2b495047760765c7d7fdfb4ccb510723aa263
Reviewed-on: https://boringssl-review.googlesource.com/3121
Reviewed-by: Adam Langley <agl@google.com>
By copying the input and output data via an aligned buffer, the
alignment requirements for the NEON ChaCha implementation on ARM can be
eliminted. This does, however, reduce the speed when aligned buffers are
used. However, updating the GCC version used to generate the ASM more
than makes up for that.
On a SnapDragon 801 (OnePlus One) the aligned speed was 214.6 MB/s and
the unaligned speed was 112.1 MB/s. Now both are 218.4 MB/s. A Nexus 7
also shows a slight speed up.
Change-Id: I68321ba56767fa5354b31a1491a539b299236e9a
Reviewed-on: https://boringssl-review.googlesource.com/3132
Reviewed-by: Adam Langley <agl@google.com>
This avoids having Windows be different and is also easier for testing
because it's a simple matter to unalign the pointer if needed.
Change-Id: I32cfa5834e3fe4f16304a25092b9c71946d4744d
Reviewed-on: https://boringssl-review.googlesource.com/3131
Reviewed-by: Adam Langley <agl@google.com>
This avoids a conflict with the Chromium build system, which
defines WIN32_LEAN_AND_MEAN with a different value.
BUG=crbug.com/453196
Change-Id: Ia15ec7c20325c1961af4f32e5208266e5f846f35
Reviewed-on: https://boringssl-review.googlesource.com/3150
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Avoid "warning C4530: C++ exception handler used, but unwind semantics
are not enabled. Specify /EHsc" when compiling MSVC's <xlocale> by
disabling the exception code in MSVC's STL using _HAS_EXCEPTIONS=0.
Change-Id: I75aeb445d58cc9fb44467a6044386ae6b519cca8
Reviewed-on: https://boringssl-review.googlesource.com/3111
Reviewed-by: Adam Langley <agl@google.com>
The variable switches the default type for add_library from STATIC to SHARED.
We can condition additional stuff on that for convenience. (tabtest still
doesn't build.)
BoringSSL as any kind of stable system shared library is still very much
unsupported, but this is probably handy for making sure we don't forget all
those pesky OPENSSL_EXPORTs.
Change-Id: I66ab80bcddbf3724e03e85384141fdf4f4acbc2e
Reviewed-on: https://boringssl-review.googlesource.com/3092
Reviewed-by: Adam Langley <agl@google.com>
Forgot to export those when adding them.
Change-Id: I206f488eb38e5ff55b8c212911aced0cf28b7664
Reviewed-on: https://boringssl-review.googlesource.com/3090
Reviewed-by: Adam Langley <agl@google.com>
This reverts commit cd5c892a87. We'd rather get
rid of crypto/conf altogether, and these tests will require that we
OPENSSL_EXPORT conf.h's functions.
Change-Id: I271511ba321201e60de94e5c79c4b565ce31728f
Reviewed-on: https://boringssl-review.googlesource.com/3120
Reviewed-by: Adam Langley <agl@google.com>
Define WIN32_LEAN_AND_MEAN before including Windows Platform SDK
headers to preempt naming conflicts and to make the build faster. Avoid
including those headers in BoringSSL headers. Document that Platform
SDK 8.1 or later is required on Windows.
Change-Id: I907ada21dc722527ea37e839c71c5157455a7003
Reviewed-on: https://boringssl-review.googlesource.com/3100
Reviewed-by: Adam Langley <agl@google.com>
This matches the Chromium build, in both static and components builds. (Also
happens to sort out an undocumented requirement of the standalone shared
library build.)
Change-Id: Ib47fc4c2143115fe6faf9b83079576075efd72bb
Reviewed-on: https://boringssl-review.googlesource.com/3091
Reviewed-by: Adam Langley <agl@google.com>
We deal with the difference between binary and text modes on Windows by
doing all I/O in binary mode (including, in particular,
stdin/stdout/stderr) and by treating text mode as equivalent to binary
mode (i.e. we use Unix line ending semantics).
Change-Id: I76a46d8d02cd7efe1931c8272d8f2c311aef3acb
Reviewed-on: https://boringssl-review.googlesource.com/3070
Reviewed-by: Adam Langley <agl@google.com>
In an attempt to assign a zero-length HMAC key, consumers might
incorrectly call:
HMAC_Init_ex(key=NULL, key_len=0)
This does not work as expected since |key==NULL| has special semantics.
This bug may consequently result in uninitialized memory being used for
the HMAC key data.
This workaround doesn't fix all the problems associated with this
pattern, however by defaulting to a zero key the results are more
predictable than before.
BUG=http://crbug.com/449409
Change-Id: I777276d57c61f1c0cce80b18e28a9b063784733f
Reviewed-on: https://boringssl-review.googlesource.com/3040
Reviewed-by: Adam Langley <agl@google.com>
CMake 3.0 changed the identifier for Apple-supplied Clang to
AppleClang.
CMake 3.1 changed the behavior of variable expansion in quoted
strings and complains with warning CMP0054 twice without these
changes.
BUG=crbug.com/451610
Change-Id: I0f1514ec302cf5f1b5cfc2c5a1c71c9e20d5e855
Reviewed-on: https://boringssl-review.googlesource.com/3011
Reviewed-by: Adam Langley <agl@google.com>
The initial instructions given don't work on Windows for a variety of
reasons. Document the prerequisite tools and the limitations on
Windows.
BUG=crbug.com/451610
Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3
Reviewed-on: https://boringssl-review.googlesource.com/3010
Reviewed-by: Adam Langley <agl@google.com>
I hear all the cool projects have those.
Change-Id: I0fb82ddb3f7c1768523311637099baf26c574c75
Reviewed-on: https://boringssl-review.googlesource.com/3062
Reviewed-by: Adam Langley <agl@google.com>
This matches the Chromium build.
Change-Id: I6ebd01c6ecb67c79577f98cf468dc204721595ef
Reviewed-on: https://boringssl-review.googlesource.com/3063
Reviewed-by: Adam Langley <agl@google.com>
out2 wasn't sized to account for stateful AEAD open requiring a seal overhead's
worth of scratch space. Also, pass in sizeof(out2) rather than a computed
ciphertext length, so the max_out check would have actually caught this.
Change-Id: Ibe689424f6c8ad550b3a45266699892076e7ba5e
Reviewed-on: https://boringssl-review.googlesource.com/3060
Reviewed-by: Adam Langley <agl@google.com>
Te4 is used in in crypto/aes/aes.c. It's used upstream in an alternate
implementation of AES_set_encrypt_key not included in our version.
Change-Id: I5704dbc714bdb05ef515cbf2aff5e43c3b62c5b2
Reviewed-on: https://boringssl-review.googlesource.com/3061
Reviewed-by: Adam Langley <agl@google.com>
Android might want to replace the system *sum (i.e. md5sum, sha256sum
etc) binaries with a symlink to the BoringSSL tool binary.
This change also allows the tool to figure out what to do based on
argv[0] if it matches one of the known commands.
Change-Id: Ia4fc3cff45ce2ae623dae6786eea5d7ad127d44b
Reviewed-on: https://boringssl-review.googlesource.com/2940
Reviewed-by: Adam Langley <agl@google.com>
Previously, the data for the common DH parameters was given twice: once
with 64-bit limbs and again with 32-bit limbs. A simple macro can
eliminate this duplication.
Change-Id: I15af008a769616f8146845cc8dd0e6526aa142ba
Reviewed-on: https://boringssl-review.googlesource.com/2950
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
This is fatal for TLS but buffered in DTLS. The buffering isn't strictly
necessary (it would be just as valid to drop the record on the floor), but so
long as we want this behavior it should have a test.
Change-Id: I5846bb2fe80d78e25b6dfad51bcfcff2dc427c3f
Reviewed-on: https://boringssl-review.googlesource.com/3029
Reviewed-by: Adam Langley <agl@google.com>
They're not in the duplicated handshake state machines anyway. But we still
shouldn't negotiate them. d1_pkt.c assumes Finished is the only post-CCS
handshake message. An unexpected handshake message in the current epoch may
either be a retransmit/out-of-order message from the previous handshake, or a
message from the next handshake (also potentially out-of-order). In the former
case, we shouldn't spin up another handshake state machine instance.
(This assumption is required due to a protocol bug. DTLS resets sequence
numbers after a handshake, so it is necessary to categorize handshake fragments
by pre-CCS and post-CCS to distinguish between retransmit and renego.)
Change-Id: Ib3c1c7085c729e36a40f7ff14494733156924a24
Reviewed-on: https://boringssl-review.googlesource.com/3028
Reviewed-by: Adam Langley <agl@google.com>
