RAND_DRBG: add a function for setting the reseeding defaults
The introduction of thread local public and private DRBG instances (#5547)
makes it very cumbersome to change the reseeding (time) intervals for
those instances. This commit provides a function to set the default
values for all subsequently created DRBG instances.
int RAND_DRBG_set_reseed_defaults(
unsigned int master_reseed_interval,
unsigned int slave_reseed_interval,
time_t master_reseed_time_interval,
time_t slave_reseed_time_interval
);
The function is intended only to be used during application initialization,
before any threads are created and before any random bytes are generated.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5576)
Ben Kaduk [Fri, 9 Mar 2018 18:58:39 +0000 (12:58 -0600)]
Attempt to fix boringssl tests
Commit abe256e7951e6d57f8f6b4364ea696eb4ead3852 changed the config target
element from 'cxx' to 'CXX'; catch up accordingly.
Also use a space to offset the template boundary, per convention.
[extended tests]
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5577)
Benjamin Kaduk [Mon, 17 Jul 2017 17:44:03 +0000 (12:44 -0500)]
Document more X509_STORE functions
X509_STORE_set_verify_cb_func.pod has documentation for various callbacks
and function pointers that can be set and retrieved, but neither it nor
X509_STORE_new has much documentation for the actual purpose and usage
of X509_STORE objects. Remedy this disparity with new documentation
for adding certificates and CRLs, expected usage, and for modifying
the default verifification behavior.
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3958)
Benjamin Kaduk [Tue, 14 Mar 2017 19:41:08 +0000 (14:41 -0500)]
Reuse extension_is_relevant() in should_add_extension()
At the core of things is the concept that each extension is only
defined in certain context(s) -- the ClientHello, EncryptedExtensions,
etc., and sometimes only for a specific protocol or protocol range;
we want to enforce that we only parse or generate extensions in the
context(s) for which they are defined. There is some subtlety here,
in that the protocol version in use is not known when generating the
ClientHello (but it is known when the ClientHello extensions are
being parsed!), so the SSL_IS_TLS13() macro must be used with caution.
Nonetheless, by making assertions about whether we are acting in a
server role and whether the current context is (not) a ClientHello,
we can consolidate almost all of the logic for determining whether
an extension is permitted in a given protocol message, whether we
are generating or parsing that message.
The only logic that remains separate relates to generating the ClientHello,
as it depends on an external factor (the maximum permitted TLS version) that
is not defined in the parsing context.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/2945)
Benjamin Kaduk [Tue, 30 Jan 2018 18:55:44 +0000 (12:55 -0600)]
Fix type error in PEM processing
The get_name() helper was using a variable of type size_t to hold the
result of BIO_gets(), but BIO_gets() returns int and makes use of negative
values to indicate error conditions.
Change the type of the local variable to match, and propagate that
through to other places in the file to avoid -Wsign-compare issues.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5211)
Todd Short [Mon, 28 Dec 2015 14:13:20 +0000 (09:13 -0500)]
Add SSL/SSL_CTX_use_cert_and_key()
Add functions that will do the work of assigning certificate, privatekey
and chain certs to an SSL or SSL_CTX. If no privatekey is given, use the
publickey. This will permit the keys to pass validation for both ECDSA
and RSA. If a private key has already been set for the certificate, it
is discarded. A real private key can be set later.
This is an all-or-nothing setting of these parameters. Unlike the
SSL/SSL_CTX_use_certificate() and SSL/SSL_CTX_use_PrivateKey() functions,
the existing cert or privatekey is not modified (i.e. parameters copied).
This permits the existing cert/privatekey to be replaced.
It replaces the sequence of:
* SSL_use_certificate()
* SSL_use_privatekey()
* SSL_set1_chain()
And may actually be faster, as multiple checks are consolidated.
The private key can be NULL, if so an ENGINE module needs to contain the
actual private key that is to be used.
Note that ECDH (using the certificate's ECDSA key) ciphers do not work
without the private key being present, based on how the private key is
used in ECDH. ECDH does not offer PFS; ECDHE ciphers should be used instead.
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/1130)
$target{build_scheme} consists of fixed number of elements with 3rd
element denoting VC install-path "flavour", i.e. where to install things.
Instead of looking at 3rd, let's look at last. This allows to override
flavour from template in a simple way.
Configurations/10-main.conf: define generic "flavour" in VC-common
template. Since VC-W32 was the only recognized "flavour", remove
"flavour" definitions from all targets/templates, but VC-WIN32. And
rename VC-W32 to VC-WOW.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5502)
Richard Levitte [Tue, 6 Mar 2018 20:09:05 +0000 (21:09 +0100)]
Configure et al: Move the definition of library only flags
We're currently using the attributes 'defines', 'cppflags', 'cflags'
etc quite liberally, with no regard for where that ends up. Quite a
few of those flags are actually only relevant for the libraries
(mostly libcrypto), so it's safe to say that those could be applied to
the libraries only.
So, we move some of those flags to 'lib_defines', 'lib_cppflags',
'lib_cflags', etc.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5560)
Travis-ci log output is huge and overflows internal travis-ci view,
which makes it hard to find errors.
Redirect some output to a file and dump it only if it fails.
Remove "v" option from tar that builds and extracts the srcdist.
While running the tests manually, some non-POSIX (bashisms) with ==
vs = came to light.
Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5555)
Richard Levitte [Thu, 8 Mar 2018 17:49:37 +0000 (18:49 +0100)]
Configure: correct the check of env vars vs command line flags
The check to detect if env / make variables conflicted with compiler /
linker flags on the configure command line went a little too far, and
would stop the configuration process if any such command line flag was
given, with no regard for the env / make variables at all.
This change refines the check so the stop only gets triggered if any
such flags were given AND any of the corresponding variables are set.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5561)
Richard Levitte [Wed, 7 Mar 2018 21:44:59 +0000 (22:44 +0100)]
config: Pass diverse flags to Configure via the environment
Passing flags "discovered" by 'config' on the command line to
'Configure' mixes them up with flags given by the user. That is
contrary to their intention, so they need to be passed in a different
manner.
Enter the environment variables __CNF_CPPDEFINES, __CNF_CPPINCLUDES,
__CNF_CPPFLAGS, __CNF_CFLAGS, __CNF_CXXFLAGS, __CNF_LDFLAGS, and
__CNF_LDLIBS, initialised by 'config', and then used by Configure to
initialise these %config values: defines, includes, cppflags, cflags,
cxxflags, lflags, and ex_libs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
Richard Levitte [Tue, 6 Mar 2018 19:35:30 +0000 (20:35 +0100)]
Make "make variables" config attributes for overridable flags
With the support of "make variables" comes the possibility for the
user to override them. However, we need to make a difference between
defaults that we use (and that should be overridable by the user) and
flags that are crucial for building OpenSSL (should not be
overridable).
Typically, overridable flags are those setting optimization levels,
warnings levels, that kind of thing, while non-overridable flags are,
for example, macros that indicate aspects of how the config target
should be treated, such as L_ENDIAN and B_ENDIAN.
We do that differentiation by allowing upper case attributes in the
config targets, named exactly like the "make variables" we support,
and reserving the lower case attributes for non-overridable project
flags.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
Richard Levitte [Wed, 7 Mar 2018 19:31:15 +0000 (20:31 +0100)]
Configure et al: rename all dso_* to module_* in shared-info.pl
Because there are already attributes with the dso_ prefix that are
used instead of the corresponding lib_ attributes rather than in
addition to them, it gets confusing to have similar or exactly the
same attributes working with different semantics on Unix.
So we rename those by changing the prefix dso_ to module_, and having
those work just like the shared_ attributes, but for DSOs.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5534)
Bryan Donlan [Wed, 7 Mar 2018 21:01:06 +0000 (16:01 -0500)]
Fix issues in ia32 RDRAND asm leading to reduced entropy
This patch fixes two issues in the ia32 RDRAND assembly code that result in a
(possibly significant) loss of entropy.
The first, less significant, issue is that, by returning success as 0 from
OPENSSL_ia32_rdrand() and OPENSSL_ia32_rdseed(), a subtle bias was introduced.
Specifically, because the assembly routine copied the remaining number of
retries over the result when RDRAND/RDSEED returned 'successful but zero', a
bias towards values 1-8 (primarily 8) was introduced.
The second, more worrying issue was that, due to a mixup in registers, when a
buffer that was not size 0 or 1 mod 8 was passed to OPENSSL_ia32_rdrand_bytes
or OPENSSL_ia32_rdseed_bytes, the last (n mod 8) bytes were all the same value.
This issue impacts only the 64-bit variant of the assembly.
This change fixes both issues by first eliminating the only use of
OPENSSL_ia32_rdrand, replacing it with OPENSSL_ia32_rdrand_bytes, and fixes the
register mixup in OPENSSL_ia32_rdrand_bytes. It also adds a sanity test for
OPENSSL_ia32_rdrand_bytes and OPENSSL_ia32_rdseed_bytes to help catch problems
of this nature in the future.
Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5342)
Alex Gaynor [Thu, 8 Mar 2018 12:59:50 +0000 (07:59 -0500)]
Fixed several readability issues in DH_generate_parameters.pod
Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5553)
Matt Caswell [Tue, 6 Mar 2018 10:41:47 +0000 (10:41 +0000)]
Remove OPENSSL_USE_NODELETE guards in shlibloadtest
PR #3399 converted shlibloadtest to the new test framework. It also
seemed to add some `OPENSSL_USE_NODELETE` guards to the library
unloading part of the test. This part was added in a commit with this
description:
Review feedback; use single main, #ifdef ADD_TEST
Suppose OPENSSL_USE_NODELETE (via Nick Reilly)
Strangely though there doesn't seem to be any relevant review feedback
in that PR that could justify the addition of those guards. The guards
do not appear in 1.1.0.
Having the guards changes the nature of the test, so that we only test
library unloading on platforms where OPENSSL_USE_NODELETE is set (Linux
and Windows). I can't think of any good reason for this and as it doesn't
seem to be necessary in 1.1.0 so I think we should remove them.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5530)
Viktor Dukhovni [Mon, 5 Mar 2018 20:18:04 +0000 (15:18 -0500)]
Implement multi-process OCSP responder.
With "-multi" the OCSP responder forks multiple child processes,
and respawns them as needed. This can be used as a long-running
service, not just a demo program. Therefore the index file is
automatically re-read when changed. The responder also now optionally
times out client requests.
Andy Polyakov [Mon, 5 Mar 2018 16:10:03 +0000 (17:10 +0100)]
crypto/armcap.c: mask SHA512 hardware detection on iOS.
When running iOS application from command line it's impossible to
get past the failing capability detection. This is because it's
executed under debugger and iOS debugger is impossible to deal with.
[If Apple implements SHA512 in silicon, it would have to be detected
with sysctlbyname.]
Andy Polyakov [Mon, 5 Mar 2018 15:55:48 +0000 (16:55 +0100)]
Configurations/10-main.conf: add -fno-common back to darwin-ppc-cc.
-fno-common was removed for all Darwin targets in 0c8734198d4282f6997965a03cd2e0ceaf207549 with rationale "it's either
'ranlib -c' or '-fno-common'." However, it's still absolutely required
in 32-bit darwin-ppc-cc. And when trying things out I didn't quite
see why it was formulated as one-or-another choice, as 'ranlib -c'
shouldn't [and doesn't] have problems with object modules without
commons. [Well, to be frank, I didn't manage to reproduce the problem
the modification was meaning to resolve either...]
Alex Gaynor [Tue, 6 Mar 2018 18:07:33 +0000 (13:07 -0500)]
Fix a typo in the s_client man page
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5525)
Matt Caswell [Fri, 2 Mar 2018 15:02:11 +0000 (15:02 +0000)]
Fix status_request and SCT extensions
They are valid for use in a CertificateRequest message, but we did not
allow it. If a server sent such a message using either of those two
extensions then the handshake would abort.
This corrects that error, but does not add support for actually processing
the extensions. They are simply ignored, and a TODO is inserted to add
support at a later time.
This was found during interoperability testing with btls:
https://gitlab.com/ilari_l/btls
Prompted by these errors I reviewed the complete list of extensions and
compared them with the latest table in draft-24 to confirm there were no
other errors of a similar type. I did not find any.
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Ben Kaduk <kaduk@mit.edu>
(Merged from https://github.com/openssl/openssl/pull/5490)
Debugging asserts had implicit casts that triggered the warnings.
However, instead of making the casts explicit it's more appropriate
to perform checks that ensure that implicit casts were safe.
Alex Gaynor [Sat, 3 Mar 2018 16:37:07 +0000 (11:37 -0500)]
Fixed a typo in a man page
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5498)
Ivan Filenko [Sun, 25 Feb 2018 13:49:27 +0000 (16:49 +0300)]
Fix typo in ASN1_STRING_length doc
CLA: trivial
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5458)
Why is it redundant? We're looking at carry from addition of small,
11-bit number to 256-bit one. And carry would mean only one thing,
resulting first limb being small number and remaing ones - zeros.
Hence adding 38 to first limb can't carry.
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5476)
Benjamin Kaduk [Wed, 28 Feb 2018 20:49:59 +0000 (14:49 -0600)]
Do not set a nonzero default max_early_data
When early data support was first added, this seemed like a good
idea, as it would allow applications to just add SSL_read_early_data()
calls as needed and have things "Just Work". However, for applications
that do not use TLS 1.3 early data, there is a negative side effect.
Having a nonzero max_early_data in a SSL_CTX (and thus, SSL objects
derived from it) means that when generating a session ticket,
tls_construct_stoc_early_data() will indicate to the client that
the server supports early data. This is true, in that the implementation
of TLS 1.3 (i.e., OpenSSL) does support early data, but does not
necessarily indicate that the server application supports early data,
when the default value is nonzero. In this case a well-intentioned
client would send early data along with its resumption attempt, which
would then be ignored by the server application, a waste of network
bandwidth.
Since, in order to successfully use TLS 1.3 early data, the application
must introduce calls to SSL_read_early_data(), it is not much additional
burden to require that the application also calls
SSL_{CTX_,}set_max_early_data() in order to enable the feature; doing
so closes this scenario where early data packets would be sent on
the wire but ignored.
Update SSL_read_early_data.pod accordingly, and make s_server and
our test programs into applications that are compliant with the new
requirements on applications that use early data.
Fixes #4725
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5483)
David Makepeace [Wed, 28 Feb 2018 06:30:32 +0000 (16:30 +1000)]
Fixed typo in description of EVP_CIPHER_meth_set_iv_length().
Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/5477)
Paul Yang [Tue, 27 Feb 2018 02:47:16 +0000 (10:47 +0800)]
Fix the type of -out option
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)
Paul Yang [Tue, 13 Feb 2018 12:15:34 +0000 (20:15 +0800)]
Add test cases for this -out option check
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)
Paul Yang [Wed, 21 Jun 2017 15:02:12 +0000 (23:02 +0800)]
Check directory is able to create files for various -out option
This is to address issue #3404, only works in Unix-like platforms
Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3709)
David Benjamin [Wed, 21 Feb 2018 23:50:21 +0000 (18:50 -0500)]
Always use adr with __thumb2__.
Thumb2 addresses are a bit a mess, depending on whether a label is
interpreted as a function pointer value (for use with BX and BLX) or as
a program counter value (for use with PC-relative addressing). Clang's
integrated assembler mis-assembles this code. See
https://crbug.com/124610#c54 for details.
Instead, use the ADR pseudo-instruction which has clear semantics and
should be supported by every assembler that handles the OpenSSL Thumb2
code. (In other files, the ADR vs SUB conditionals are based on
__thumb2__ already. For some reason, this one is based on __APPLE__, I'm
guessing to deal with an older version of clang assembler.)
It's unclear to me which of clang or binutils is "correct" or if this is
even a well-defined notion beyond "whatever binutils does". But I will
note that https://github.com/openssl/openssl/pull/4669 suggests binutils
has also changed behavior around this before.
Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5431)
xemdetia [Tue, 27 Feb 2018 20:29:32 +0000 (15:29 -0500)]
Fix documentation link to reference man3
CLA: trivial
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com> Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5473)
bio_b64.c: prevent base64 filter BIO from decoding out-of-bound data
Fixes #5405, #1381
The base64 filter BIO reads its input in chunks of B64_BLOCK_SIZE bytes.
When processing input in PEM format it can happen in rare cases that
- the trailing PEM marker crosses the boundary of a chunk, and
- the beginning of the following chunk contains valid base64 encoded data.
This happened in issue #5405, where the PEM marker was split into
"-----END CER" and "TIFICATE-----" at the end of the first chunk.
The decoding of the first chunk terminated correctly at the '-' character,
which is treated as an EOF marker, and b64_read() returned. However,
when called the second time, b64_read() read the next chunk and interpreted
the string "TIFICATE" as valid base64 encoded data, adding 6 extra bytes
'4c 81 48 08 04 c4'.
This patch restores the assignment of the error code to 'ctx->cont', which
was deleted accidentally in commit 5562cfaca4f3 and which prevents b64_read()
from reading additional data on subsequent calls.
This issue was observed and reported by Annie Yousar.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5422)
projects / thirdparty / openssl.git / log
