Basically we use EXFLAG_INVALID for all kinds of out of memory and
all kinds of parse errors in x509v3_cache_extensions.
[extended tests]
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10756)
OpenSSL 1.1.0 has extended option checking, and rejects passing a PKCS#11
engine URL to "-signkey" option. The actual code is ready to take it.
Change the option parsing to allow an engine URL to be passed and modify
the manpage accordingly.
CLA: trivial
(cherry picked from commit 16d560439d8b1be5082228a87576a8f79b3525ac)
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11173)
CAkeyform may be set to PEM, DER or ENGINE, but the current options
are not using the proper optionformat 'E' (OPT_FMT_PDE) for this.
Set the valtype for CAkeyform to 'E' and use OPT_FMT_PDE when extracting
the option value.
This amends bf4006a6f9 ("Fix regression on x509 keyform argument") which
did the same thing for keyform and changed the manpage synopsis entries
for both keyform and CAkeyform but did not change the option section.
Hence, change the option section.
CLA: trivial
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/11172)
It replaces apps/server.pem that used a sha1 signature with a copy of
test/certs/servercert.pem that is uses sha256.
This caused the dtlstest to start failing. It's testing connection
sbetween a dtls client and server. In particular it was checking that if
we drop a record that the handshake recovers and still completes
successfully. The test iterates a number of times. The first time
through it drops the first record. The second time it drops the second
one, and so on. In order to do this it has a hard-coded value for the
expected number of records it should see in a handshake. That's ok
because we completely control both sides of the handshake and know what
records we expect to see. Small changes in message size would be
tolerated because that is unlikely to have an impact on the number of
records. Larger changes in message size however could increase or
decrease the number of records and hence cause the test to fail.
This particular test uses a mem bio which doesn't have all the CTRLs
that the dgram BIO has. When we are using a dgram BIO we query that BIO
to determine the MTU size. The smaller the MTU the more fragmented
handshakes become. Since the mem BIO doesn't report an MTU we use a
rather small default value and get quite a lot of records in our
handshake. This has the tendency to increase the likelihood of the
number of records changing in the test if the message size changes.
It so happens that the new server certificate is smaller than the old
one. AFAICT this is probably because the DNs for the Subject and Issuer
are significantly shorter than previously. The result is that the number
of records used to transmit the Certificate message is one less than it
was before. This actually has a knock on impact for subsequent messages
and how we fragment them resulting in one less ServerKeyExchange record
too (the actual size of the ServerKeyExchange message hasn't changed,
but where in that message it gets fragmented has). In total the number
of records used in the handshake has decreased by 2 with the new
server.pem file.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
GH: #10784
(cherry picked from commit 5fd72d96a592c3c4ef28ff11c6ef334a856b0cd1)
When performing a pkeyutl -verifyrecover operation the input file is not
a hash - it is the signature itself. Therefore don't do the check to make
sure it looks like a hash.
Fixes#9658
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9731)
(cherry picked from commit 5ffc33244cd4d66e47dfa66ce89cb38d0f3074cc)
This came from f3fdfbf78c6b. run = 1 should be done in pkey_print_message
as well, otherwise other tests printed with pkey_print_message won't run.
Change-Id: I0ba0b05256ad6509ada4735b26d10f8a73fd89ec
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/10710)
(cherry picked from commit 6e49b514067a2b6a30d064d2ae1fdfd8050c184b)
The timer alarm sets run = 0, while the benchmark
does run = 1 in the initialization code. That is
a race condition, if the timer goes off too early
the benchmark runs forever.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10680)
(cherry picked from commit f3fdfbf78c6bfc97abf9c70b03859a28ebf6b66d)
In OpenSSL pre 1.1.0, 'openssl x509 -keyform engine' was possible
and supported. In 1.1.0, type of keyform argument is OPT_FMT_PEMDER
which doesn't support engine. This changes type of keyform argument
to OPT_FMT_PDE which means PEM, DER or engine and updates the manpage
including keyform and CAkeyform.
This restores the pre 1.1.0 behavior.
This issue is very similar than https://github.com/openssl/openssl/issues/4366
CLA: trivial
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10609)
(cherry picked from commit 0ab6fc79a9a63370be1a615729dc2a6ed0d6c89b)
Fixes#10261
CLA: trivial
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/10285)
(cherry picked from commit 1ac7e15375be39c8f03171c02658cf703f58217a)
CLA: trivial
Fixes#10273
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10578)
(cherry picked from commit 1aeec3dbc2d62f902698b1eba9ed31cbd436f9dc)
CLA: trivial
Reviewed-by: Paul Yang <kaishen.yy@antfin.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/10607)
(cherry picked from commit dd0139f416257ec5632414ed3ad8c61d07ba07ec)
It appears that 'sock_timeout' is defined at least with DJGPP, so we
rename our symbol and hope the new name isn't taken.
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10515)
(cherry picked from commit e9b95e42fbae668cb605287fa462a0d5f58b9caf)
... if the fixed-size buffer is too small.
Fixes#9732
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com>
(Merged from https://github.com/openssl/openssl/pull/10276)
(cherry picked from commit 7c2d95d47ccb3797f0da6bd4446747c6eee07b87)
Running s_server in WWW mode on Windows can allow a client to read files
outside the s_server directory by including backslashes in the name, e.g.
GET /..\myfile.txt HTTP/1.0
There exists a check for this for Unix paths but it is not sufficient
for Windows.
Since s_server is a test tool no CVE is assigned.
Thanks to Jobert Abma for reporting this.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10215)
(cherry picked from commit 0a4d6c67480a4d2fce514e08d3efe571f2ee99c9)
The hardcoded code points for TLSv1.3 cipher suites are used in the TLS
PSK server callback. However, they seem to have been refactored a while
ago to use tls13_aes128gcmsha256_id, so these defines are not necessary
within the s_server code anymore.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10243)
(cherry picked from commit aed8c47cbcc8a289bea433ead2effea035187260)
The output format now matches coreutils *dgst tools.
[ edited to remove trailing white space ]
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(cherry picked from commit f3448f5481)
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/10094)
Several EVP_PKEY_xxxx functions return 0 and a negative value for
indicating errors. Some places call these functions with a zero return
value check only, which misses the check for the negative scenarios.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10055)
(cherry picked from commit 7e3ae24832e0705583b1471febf3dc0eb1cc021f)
Those functions returns less than and equal to 0 to indicate an error
occured.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/10054)
(cherry picked from commit 94bd168a9e31d1ab4986e94056dfae71ec5f051f)
Make the include guards consistent by renaming them systematically according
to the naming conventions below
The public header files (in the 'include/openssl' directory) are not changed
in 1.1.1, because it is a stable release.
For the private header files files, the guard names try to match the path
specified in the include directives, with all letters converted to upper case
and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/9681)
Currently the pkcs12 app will only ever print the first value of a multi-value
attribute. This is OK for some attributes (e.g. friendlyName, localKeyId) but
may miss values for other attributes.
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9751)
(cherry picked from commit dbcc7b45670483cc89428afe1d3c363ef83d76df)
Fixes#9080
Signed-off-by: Billy Brawner <billy@wbrawner.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9710)
(cherry picked from commit 1e8e75d18be8856e753a57771754b9926c3f4264)
The input reading loop in 'openssl dgst' and 'openssl enc' doesn't
check for end of input, and because of the way BIO works, it thereby
won't detect that the end is reached before the read is an error.
With the FILE BIO, an error occurs when trying to read past EOF, which
is fairly much ok, except when the command is used interactively, at
least on Unix. The result in that case is that the user has to press
Ctrl-D twice for the command to terminate.
The issue is further complicated because both these commands use
filter BIOs on top of the FILE BIO, so a naïve attempt to check
BIO_eof() doesn't quite solve it, since that only checks the state of
the source/sink BIO, and the filter BIO may have some buffered data
that still needs to be read. Fortunately, there's BIO_pending() that
checks exactly that, if any filter BIO has pending data that needs to
be processed.
We end up having to check both BIO_pending() and BIO_eof().
Thanks to Zsigmond Lőrinczy for the initial effort and inspiration.
Fixes#9355
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from https://github.com/openssl/openssl/pull/9668)
(cherry picked from commit 8ed7bbb411)
CLA: trivial
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Shane Lontis <shane.lontis@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9295)
The HEADER_X509_H check is redundant, because <openssl/x509.h>
is already included.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/9365)
CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/9275)
e.g. openssl speed -evp id-aes256-wrap-pad
was crashing because the return code from EVP_CipherInit_ex
was ignored.
Not going to allow that cipher mode because wrap ciphers
produces more bytes output than the input length
and EVP_Update_loop is not really prepared for that.
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8739)
(cherry picked from commit 5d238a1032)
If the `openssl cms` command is called without specifying an
operation option, it replies with the following laconic error message:
cms: Use -help for summary.
This commit adds a helpful error message:
No operation option (-encrypt|-decrypt|-sign|-verify|...) specified.
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8861)
(cherry picked from commit 42151b8edb)
|str| was used for multiple conflicting purposes. When using
'-strictpem', it's used to uniquely hold a reference to the loaded
payload. However, when using '-strparse', |str| was re-used to hold
the position from where to start parsing.
So when '-strparse' and '-strictpem' are were together, |str| ended up
pointing into data pointed at by |at|, and was yet being freed, with
the result that the payload it held a reference to became a memory
leak, and there was a double free conflict when both |str| and |at|
were being freed.
The situation is resolved by always having |buf| hold the pointer to
the file data, and always and only use |str| to hold the position to
start parsing from. Now, we only need to free |buf| properly and not
|str|.
Fixes#8752
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/8753)
(cherry picked from commit 4f29f3a29b)
Fixes#8645
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8654)
(cherry picked from commit f997e456b9)
"warning: iv not use by this cipher" -> "warning: iv not used by this cipher"
CLA: trivial
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/8608)
(cherry picked from commit 9c119bc6b5)
So far, it only handled hash-and-algorithm pairs from TLS1.2,
now it also handles 'schemes' defined in TLS1.3 like 0x0807=ed25519 or
0x0809=rsa_pss_pss_sha256
Now it prints information in one of these formats:
... Algorithm scheme=ecdsa_secp256r1_sha256, security bits=128 ... TLS1.3
... Algorithm digest=SHA384, algorithm=DSA, security bits=192 ... TLS1.2
... Algorithm scheme=unknown(0x0e01), security bits=128 ... unhandled case
To implement this added three new lookup-tables: signature_tls13_scheme_list,
signature_tls12_alg_list, signature_tls12_hash_list.
Also minor changes in 'security_callback_debug', eg adding variable 'show_nm'
to indicate if we should show 'nm'.
Also coding-styles fixes from matcaswell
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8445)
(cherry picked from commit 861e45624f)
The ecdh_c array is allocated of the same size as ecdh_choices,
whose size depends on whether the support for binary curves is enabled
or not. (The same goes for ecdsa_c).
On systems without SIGALRM, ecdh_c is indexed by predefined constants
intended for representing the index of the ciphers in the ecdh_choices
array.
However, in case of NO_EC2M some of the #defined constants won't match
and would actually access the ecdh_c out-of-bounds.
Use enum instead of a macro to define the curve indexes so they're
within the bounds of the ecdh_c array.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8422)
(cherry picked from commit f5c9916742)
openssl speed doesn't take into account that the library could be
compiled without the support for the binary curves and happily uses
them, which results in EC_GROUP_new_by_curve_name() errors.
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8422)
(cherry picked from commit d61f489b5a)
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8175)
(cherry picked from commit 8e981051ce)
The "verify_return_error" option in s_client is documented as:
Return verification errors instead of continuing. This will typically
abort the handshake with a fatal error.
In practice this option was ignored unless also accompanied with the
"-verify" option. It's unclear what the original intention was. One fix
could have been to change the documentation to match the actual behaviour.
However it seems unecessarily complex and unexpected that you should need
to have both options. Instead the fix implemented here is make the option
match the documentation so that "-verify" is not also required.
Note that s_server has a similar option where "-verify" (or "-Verify") is
still required. This makes more sense because those options additionally
request a certificate from the client. Without a certificate there is no
possibility of a verification failing, and so "-verify_return_error" doing
nothing seems ok.
Fixes#8079
Reviewed-by: Nicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8080)
(cherry picked from commit 78021171db)
This allows the user to override our defaults if needed, and in a
consistent manner.
Partial fix for #7607
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/7624)
(cherry picked from commit ca811248d8)
Trim trailing whitespace. It doesn't match OpenSSL coding standards,
AFAICT, and it can cause problems with git tooling.
Trailing whitespace remains in test data and external source.
Backport-of: https://github.com/openssl/openssl/pull/8092
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/8134)
