The TS_RESP_verify_response() function is used for verifying the response
from a TSA. You can set the provided TS_VERIFY_CTX with different flags
depending on what aspects of the response you wish to verify.
A seg fault will occur if you supply the TS_VFY_SIGNER or TS_VFY_TSA_NAME
flags without also specifying TS_VFY_SIGNATURE.
Reviewed-by: Rich Salz <rsalz@openssl.org>
If a user specifies -unix, -6, etc., then the program tries to
use the last one specified. This is confusing code and leads to
scripting errors. Instead, allow only one type.
Reviewed-by: Andy Polyakov <appro@openssl.org>
We already test in EC_POINT_oct2point that points are on the curve. To
be on the safe side, move this check to
EC_POINT_set_affine_coordinates_* so as to also check point coordinates
received through some other method.
We do not check projective coordinates, though, as
- it's unlikely that applications would be receiving this primarily
internal representation from untrusted sources, and
- it's possible that the projective setters are used in a setting where
performance matters.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Files like dh.pod, etc., mostly duplicated the API-specific pod files.
Removed the duplicated content; that often mean the whole file could
be removed. Some of the content about internals got moved into README
files in the source tree. Some content (e.g., err.pod) got moved
into other pod pages.
Annotate generic pages, remove dup NAME
Reviewed-by: Richard Levitte <levitte@openssl.org>
When session tickets are used, it's possible that SNI might swtich the
SSL_CTX on an SSL. Normally, this is not a problem, because the
initial_ctx/session_ctx are used for all session ticket/id processes.
However, when the SNI callback occurs, it's possible that the callback
may update the options in the SSL from the SSL_CTX, and this could
cause SSL_OP_NO_TICKET to be set. If this occurs, then two bad things
can happen:
1. The session ticket TLSEXT may not be written when the ticket expected
flag is set. The state machine transistions to writing the ticket, and
the client responds with an error as its not expecting a ticket.
2. When creating the session ticket, if the ticket key cb returns 0
the crypto/hmac contexts are not initialized, and the code crashes when
trying to encrypt the session ticket.
To fix 1, if the ticket TLSEXT is not written out, clear the expected
ticket flag.
To fix 2, consider a return of 0 from the ticket key cb a recoverable
error, and write a 0 length ticket and continue. The client-side code
can explicitly handle this case.
Fix these two cases, and add unit test code to validate ticket behavior.
Reviewed-by: Emilia Käsper <emilia@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1098)
Various fixes to get the following to compile:
./config no-asm -ansi -D_DEFAULT_SOURCE
RT4479
RT4480
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Sessions are stored on the session_ctx, which doesn't change after
SSL_set_SSL_CTX().
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
The previous commit changed how we handle out-of-context empty records.
This commit adds some tests for the various scenarios. There are three
tests:
1: Check that if we inject an out-of-context empty record then we fail
2: Check that if we inject an in-context empty record then we succeed
3: Check that if we inject too many in-context empty records then we fail.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Previously if we received an empty record we just threw it away and
ignored it. Really though if we get an empty record of a different content
type to what we are expecting then that should be an error, i.e. we should
reject out of context empty records. This commit makes the necessary changes
to achieve that.
RT#4395
Reviewed-by: Andy Polyakov <appro@openssl.org>
The previous commit fixed a bug with BN_mod_word() which would have been
caught if we had a test for it. This commit adds one.
Reviewed-by: Andy Polyakov <appro@openssl.org>
On systems where we do not have BN_ULLONG (e.g. typically 64 bit systems)
then BN_mod_word() can return incorrect results if the supplied modulus is
too big.
RT#4501
Reviewed-by: Andy Polyakov <appro@openssl.org>
Make d2i_X509 a generic d2i/i2d manpage.
Pull common stuff out of other d2i/i2d docs.
Update find-doc-nits to know about "generic" manpages.
Cleanup some overlap.
Fix up a bunch of other references.
Reviewed-by: Matt Caswell <matt@openssl.org>
The asdf.pod filename must have asdf in its NAME section.
also check for names existing as a different filename (via Levitte)
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
The tlsext_status_type field in SSL is used by e.g. OpenResty to determine
if the client requested the certificate status, but SSL is now opaque.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
GH1180: Local variable sometimes unused
GH1181: Missing close paren.
Thanks to <wipedout@yandex.ru> for reporting these.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Also tweaks to find-doc-nits, including name/synopsis checking.
Ironically, it also reports on duplicated doc names :)
Reviewed-by: Richard Levitte <levitte@openssl.org>
If using threads and OpenSSL is loaded via dlopen(), and subsequently
closed again via dlclose() *before* the threads are destroyed, then
OpenSSL will not free up the per thread resources. We need to document
this restriction, and provide some guidance on what to do about it.
I did some testing and discovered/verified a few of things (at least
this is the behaviour on Linux):
- Using OpenSSL via dlopen in a mutli-threaded app does leak memory if
threads are destroyed after dlcose() is called.
- In a single threaded environment, or if threads are destroyed prior to
dlclose() being called, then no memory is leaked
- Using the RTLD_NODELETE flag to dlopen solves the above problem
- Interestingly the OpenSSL atexit() handler gets called when dlclose()
is called rather than at application exit (I was worred that it might crash
if there was an atexit() handler for a function that has been unloaded)
- RTLD_NODELETE is a non-standard flag - but it does seem to be fairly
widely supported. As far as I could determine (via google), at least Linux,
Solaris, OpenBSD, FreeBSD, HP-UX all seem to support it.
I also tested on Windows (using LoadLibrary instead of dlopen and
FreeLibrary instead of dlclose) and experienced similar behaviour, except
that (AFAIK) there is no equivalent of RTLD_NODELETE on Windows.
GitHub Issue #653
Reviewed-by: Richard Levitte <levitte@openssl.org>
If we're going to redirect STDERR and STDOUT, it's better to do it by
the book. This fix is a straight copy of examples in the perlfunc
manual.
Reviewed-by: Matt Caswell <matt@openssl.org>
The directories for the final products were never registered, it was
plain luck that intermediary files were in the same place and
registered the directory anyway.
Also, scripts are generated directly from source (binaries go through
intermadiary object files), so we need to explicitely make sure to
avoid registering the source directory unless it's an in source
build.
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
The flags RSA_FLAG_NO_CONSTTIME, DSA_FLAG_NO_EXP_CONSTTIME and
DH_FLAG_NO_EXP_CONSTTIME which previously provided the ability to switch
off the constant time implementation for RSA, DSA and DH have been made
no-ops and deprecated.
Reviewed-by: Richard Levitte <levitte@openssl.org>
The dsa_ossl.c file defined a couple of multi-line macros, but then only
used each one once. The macros just serve to complicate the code and make
it more difficult to understand what is really going on. Hence they are
removed.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Operations in the DSA signing algorithm should run in constant time in
order to avoid side channel attacks. A flaw in the OpenSSL DSA
implementation means that a non-constant time codepath is followed for
certain operations. This has been demonstrated through a cache-timing
attack to be sufficient for an attacker to recover the private DSA key.
CVE-2016-2178
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Some of the instructions used in latest additions are extension
ones. There is no real reason to limit ourselves to specific
processors, so [re-]adhere to base instruction set.
RT#4548
Reviewed-by: Rich Salz <rsalz@openssl.org>
In rare cases, the shell we run test programs in may have complaints.
Shut those up unless testing verbosely.
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
