- DTLS server code didn't account for the new ClientHello state. This looks
like it only matters if a DTLS server uses select_certificate_cb and returns
asynchronously.
- State A transitions immediately to B and is redundant. No code distinguishes
A and B.
- The ssl_get_message call transitions to the second state (originally C). This
makes the explicit transition to C a no-op. More of a problem,
ssl_get_message may return asynchronously and remain in its second state if the
handshake body had not completed yet. Fix this by splitting state C in two.
Combined with the above change, this results in only the top few states getting
reshuffled.
This fixes the server async tests.
Change-Id: I46703bcd205988b118217b6424ba4f88e731be5a
Reviewed-on: https://boringssl-review.googlesource.com/1412
Reviewed-by: Adam Langley <agl@google.com>
A single va_list may not be used twice. Nothing calls BIO_vprintf and it just
(v)snprintfs into a buffer anyway, so remove it. If it's actually needed, we
can fiddle with va_copy and the lack of it in C89 later, but anything that
actually cares can just assemble the output externally.
Add a test in bio_test.c.
BUG=399546
Change-Id: Ia40a68b31cb5984d817e9c55351f49d9d6c964c1
Reviewed-on: https://boringssl-review.googlesource.com/1391
Reviewed-by: Adam Langley <agl@google.com>
PEDANTIC was not closed, but rather the compiler being used.
Change-Id: I743118f1481adddcd163406be72926fff6c87338
Reviewed-on: https://boringssl-review.googlesource.com/1388
Reviewed-by: Adam Langley <agl@google.com>
With the removal of the freelist itself, these macros are
superfluous. Remove them in favore of OPENSSL_malloc and OPENSSL_free.
Change-Id: I4bfeff8ea087b9e16c7c32d7c1bdb7a07e7dd03e
Reviewed-on: https://boringssl-review.googlesource.com/1389
Reviewed-by: Adam Langley <agl@google.com>
The memory freelist maintained by OpenSSL claims to be a performance
optimization for platforms that have a slow malloc/free
implementation. This should not be the case on modern
linux/glibc. Remove the freelist as it poses a potential security
hazard of buffer-reuse that is of "initialized" memory that will not
be caught be tools such as valgrind.
Change-Id: I3cfa6a05f9bdfbbba7820060bae5a673dee43014
Reviewed-on: https://boringssl-review.googlesource.com/1385
Reviewed-by: Adam Langley <agl@google.com>
The code guarded by PKCS1_CHECK appears to be unhelpful, and the guard
is explicitly undefined in ssl_locl.h Remove both.
Change-Id: I3cd45a744a8f35b02181b1e48fd1ef11af5e6f4a
Reviewed-on: https://boringssl-review.googlesource.com/1383
Reviewed-by: Adam Langley <agl@google.com>
Use it to test DHE-RSA in BoringSSL.
Change-Id: I88f7bfa76507a6f60234d61d494c9f94b7df4e0a
Reviewed-on: https://boringssl-review.googlesource.com/1377
Reviewed-by: Adam Langley <agl@google.com>
Default to the number of CPUs. Avoids the tests launching 64 valgrinds in
parallel on machines without gobs of memory.
Change-Id: I9eeb365b48aa7407e303d161f90ce69a591a884c
Reviewed-on: https://boringssl-review.googlesource.com/1375
Reviewed-by: Adam Langley <agl@google.com>
Assert that inappropriate fallbacks are detected, but if the client_version
matches the server's highest version, do not abort the handshake.
Change-Id: I9d72570bce45e1eb23fc2b74a3c5fca10562e573
Reviewed-on: https://boringssl-review.googlesource.com/1373
Reviewed-by: Adam Langley <agl@google.com>
Should have test coverage there as long as we care about supporting it.
Change-Id: Ic67539228b550f2ebd0b543d5a58640913b0474b
Reviewed-on: https://boringssl-review.googlesource.com/1371
Reviewed-by: Adam Langley <agl@google.com>
TODO indicated that it was unused, and commented. Any existing users are already broken.
Change-Id: I75ebaf3f20015845d8c81eecffe2a4dfbdbe18e8
Reviewed-on: https://boringssl-review.googlesource.com/1386
Reviewed-by: Adam Langley <agl@google.com>
A modern TLS library without full support for TLS does not make sense.
Change-Id: I032537d1412f6e4effc9a2dd47123baf0084b4c6
Reviewed-on: https://boringssl-review.googlesource.com/1382
Reviewed-by: Adam Langley <agl@google.com>
OPENSSL_FIPS was removed in 64f4c91b89,
but these definitions in crypto/pem remained.
Change-Id: Ia85dd3fd7161f0b33b471b17643767b2b33fdda6
Reviewed-on: https://boringssl-review.googlesource.com/1381
Reviewed-by: Adam Langley <agl@google.com>
OPENSSL_NO_CAMELLIA has already been effectively defined, including in
opensslfeatures.h. This commit removes the last ifdef-protected code
guarded by OPENSSL_NO_CAMELLIA.
Change-Id: I58dc79dbe7a77843a641d9216f40f1d7d63fcc40
Reviewed-on: https://boringssl-review.googlesource.com/1380
Reviewed-by: Adam Langley <agl@google.com>
It's not built. The problem is worked around by the padding extension now.
Change-Id: If577efdae57d1bca4e0a626486fc0502c3567ebb
Reviewed-on: https://boringssl-review.googlesource.com/1374
Reviewed-by: Adam Langley <agl@google.com>
I didn't mark these functions as OPENSSL_EXPORT in the first place
because I was hoping that they wouldn't be needed. However, WebRTC and
libjingle are using them.
Change-Id: I7a9de770a0a2213e99725b9b5ac7d3d13754ebfd
The original functions do an ascii_to_ucs2 transformation on the password.
Deprecate them in favor of making that encoding the caller's problem.
ascii_to_ucs2 doesn't handle, say, UTF-8 anyway. And with the original OpenSSL
function, some ciphers would do the transformation, and some wouldn't making
the text-string/bytes-string confusion even messier.
BUG=399121
Change-Id: I7d1cea20a260f21eec2e8ffb7cd6be239fe92873
Reviewed-on: https://boringssl-review.googlesource.com/1347
Reviewed-by: Adam Langley <agl@google.com>
PNaCl builds BoringSSL with OPENSSL_NO_ASM, but the new OPENSSL_cleanse
was using inline assembly anyway. It appears that even though the inline
asm was empty, it still breaks the PNaCl build:
disallowed: inline assembly: call void asm sideeffect "", "r,~{memory}"(i8* %.asptr319), !dbg !96986
With this change, we don't have any compiler scarecrows for
OPENSSL_cleanse any longer when using OPENSSL_NO_ASM :( Maybe, one day,
we'll get memset_s in our base platform.
Change-Id: Ia359f6bcc2000be18a6f15de10fc683452151741
Reviewed-on: https://boringssl-review.googlesource.com/1353
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Some phones have a buggy NEON unit and the Poly1305 NEON code fails on
them, even though other NEON code appears to work fine.
This change:
1) Fixes a bug where NEON was assumed even when the code wasn't compiled
in NEON mode.
2) Adds a second NEON control bit that can be disabled in order to run
NEON code, but not the Poly1305 NEON code.
https://code.google.com/p/chromium/issues/detail?id=341598
Change-Id: Icb121bf8dba47c7a46c7667f676ff7a4bc973625
Reviewed-on: https://boringssl-review.googlesource.com/1351
Reviewed-by: Adam Langley <agl@google.com>
This change marks public symbols as dynamically exported. This means
that it becomes viable to build a shared library of libcrypto and libssl
with -fvisibility=hidden.
On Windows, one not only needs to mark functions for export in a
component, but also for import when using them from a different
component. Because of this we have to build with
|BORINGSSL_IMPLEMENTATION| defined when building the code. Other
components, when including our headers, won't have that defined and then
the |OPENSSL_EXPORT| tag becomes an import tag instead. See the #defines
in base.h
In the asm code, symbols are now hidden by default and those that need
to be exported are wrapped by a C function.
In order to support Chromium, a couple of libssl functions were moved to
ssl.h from ssl_locl.h: ssl_get_new_session and ssl_update_cache.
Change-Id: Ib4b76e2f1983ee066e7806c24721e8626d08a261
Reviewed-on: https://boringssl-review.googlesource.com/1350
Reviewed-by: Adam Langley <agl@google.com>
CMake calls "uname" in order to detect the CPU architecture,
so $(CMAKE_SYSTEM_PROCESSOR) varies from platform to platform.
This changes adds support for "i386" and "amd64" values, which
are used by BSDs for the x86 family of CPUs.
Change-Id: I532ce787a9ac06220c92a6d8c78ad5a55d8c40bf
Signed-off-by: Piotr Sikora <piotr@cloudflare.com>
Reviewed-on: https://boringssl-review.googlesource.com/1360
Reviewed-by: Adam Langley <agl@google.com>
Compilers have a bad habit of removing "superfluous" memset calls that
are trying to zero memory. For example, when memset()ing a buffer and
then free()ing it, the compiler might decide that the memset is
unobservable and thus can be removed.
Previously we tried to stop this by a) implementing memset in assembly
on x86 and b) putting the function in its own file for other platforms.
This change removes those tricks in favour of using asm directives to
scare the compiler away. As best as our compiler folks can tell, this is
sufficient and will continue to be so.
Change-Id: I40e0a62c3043038bafd8c63a91814a75a3c59269
Reviewed-on: https://boringssl-review.googlesource.com/1339
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Windows complains when the declaration of a function doesn't match the
definition. In this case, the |bits| argument (not a pointer, just an
unsigned) was marked as const in the definition only.
Normally const isn't used for non-pointer arguments so I've removed it
in this case to make Windows compile.
https://code.google.com/p/chromium/issues/detail?id=398960
Change-Id: If7386cf61f9dfbf6b32bfada1a49d5742fe94396
Reviewed-on: https://boringssl-review.googlesource.com/1338
Reviewed-by: Adam Langley <agl@google.com>
Chromium is no longer using it.
Change-Id: If56340627d2024ff3fb8561405dd0cfc6f4787cb
Reviewed-on: https://boringssl-review.googlesource.com/1346
Reviewed-by: Adam Langley <agl@google.com>
Caught by clang scan-build. (The allocation was larger than it should have
been.)
Change-Id: Ideb800118f65aaba1ee85b7611c8a705671025a8
Reviewed-on: https://boringssl-review.googlesource.com/1340
Reviewed-by: Adam Langley <agl@google.com>
Where possible, functions should return one for success and zero for
error. The use of additional negative values to indicate an error is,
itself, error prone.
This change fixes many EVP functions to remove the possibility of
negative return values. Existing code that is testing for <= 0 will
continue to function, although there is the possibility that some code
was differentiating between negative values (error) and zero (invalid
signature) for the verify functions and will now show the wrong error
message.
Change-Id: I982512596bb18a82df65861394dbd7487783bd3d
Reviewed-on: https://boringssl-review.googlesource.com/1333
Reviewed-by: Adam Langley <agl@google.com>
Use same logic when determining when to expect a client certificate for
both TLS and DTLS.
PR#3452
(Imported from upstream's 666a597ffb9bcf3ba2d49e711fcca28df91eff9d)
Change-Id: Ia267255a32c0b3b9a7da1c53f13ef6f620ff5ec1
