Age | Commit message (Collapse) | Author |
|
Here is a version that should work with all versions of openssl 0.9.7
through 1.1.0.
Links to the docs:
https://www.openssl.org/docs/man1.0.2/crypto/EVP_DigestInit.html
https://www.openssl.org/docs/man1.1.0/crypto/EVP_DigestInit.html
At the very bottom of the 1.1.0 documentation there is a history section
that states, " stack allocated EVP_MD_CTXs are no longer supported."
If EVP_MD_CTX_create and EVP_MD_CTX_destroy are not defined, then a
simple mapping can be used as described here:
https://wiki.openssl.org/index.php/Talk:OpenSSL_1.1.0_Changes
Closes #2258
|
|
|
|
Closes #1429
|
|
Coverity CID 1427646.
|
|
Follow-up to 84fcaa2e7. libressl does not have the API even if it says it is
late OpenSSL version...
Fixes #2246
Closes #2247
Reported-by: jungle-boogie on github
|
|
Fixes #2210
Closes #2236
|
|
.. because limits.h presence isn't optional, it's required by C89.
Ref: http://port70.net/~nsz/c/c89/c89-draft.html#2.2.4.2
Closes https://github.com/curl/curl/pull/2215
|
|
- Free the copy of SSLKEYLOGFILE env returned by curl_getenv during ossl
initialization.
Caught by ASAN.
|
|
Fixed undefined symbol of getenv() which does not exist when compiling
for Windows 10 App (CURL_WINDOWS_APP). Replaced getenv() with
curl_getenv() which is aware of getenv() absence when CURL_WINDOWS_APP
is defined.
Closes #2171
|
|
Prior to this change SSLKEYLOGFILE used line buffering on WIN32 just
like it does for other platforms. However, the Windows CRT does not
actually support line buffering (_IOLBF) and will use full buffering
(_IOFBF) instead. We can't use full buffering because multiple processes
may be writing to the file and that could lead to corruption, and since
full buffering is the only buffering available this commit disables
buffering for Windows SSLKEYLOGFILE entirely (_IONBF).
Ref: https://github.com/curl/curl/pull/1346#issuecomment-350530901
|
|
- Allow proxy_ssl to be checked for pending data even when connssl does
not yet have an SSL handle.
This change is for posterity. Currently there doesn't seem to be a code
path that will cause a pending data check when proxyssl could have
pending data and the connssl handle doesn't yet exist [1].
[1]: Recall that an https proxy connection starts out in connssl but if
the destination is also https then the proxy SSL backend data is moved
from connssl to proxyssl, which means connssl handle is temporarily
empty until an SSL handle for the destination can be created.
Ref: https://github.com/curl/curl/commit/f4a6238#commitcomment-24396542
Closes https://github.com/curl/curl/pull/1916
|
|
Removes another #ifdef for BoringSSL
Pointed-out-by: David Benjamin
Closes #2134
|
|
commit d3ab7c5a21e broke the boringssl build since it doesn't have
RSA_flags(), so we disable that code block for boringssl builds.
Reported-by: W. Mark Kubacki
Fixes #2117
|
|
|
|
Fixes #2079
Closes #2081
|
|
... since the 'tv' stood for timeval and this function does not return a
timeval struct anymore.
Also, cleaned up the Curl_timediff*() functions to avoid typecasts and
clean up the descriptive comments.
Closes #2011
|
|
... to cater for systems with unsigned time_t variables.
- Renamed the functions to curlx_timediff and Curl_timediff_us.
- Added overflow protection for both of them in either direction for
both 32 bit and 64 bit time_ts
- Reprefixed the curlx_time functions to use Curl_*
Reported-by: Peter Piekarski
Fixes #2004
Closes #2005
|
|
On OS/400, `close' is an ASCII system macro that corrupts the code if
not used in a context not targetting the close() system API.
|
|
Those were temporary things we'd add and remove for our own convenience
long ago. The last few stayed around for too long as an oversight but
have since been removed. These days we have a running
BORINGSSL_API_VERSION counter which is bumped when we find it
convenient, but 2015-11-19 was quite some time ago, so just check
OPENSSL_IS_BORINGSSL.
Closes #1979
|
|
Enable PKCS12 for all non-boringssl builds without relying on configure
or cmake checks.
Bug: https://curl.haxx.se/mail/lib-2017-10/0007.html
Reported-by: Christian Schmitz
Closes #1948
|
|
When CURL_DISABLE_CRYPTO_AUTH is defined, Curl_none_md5sum's parameters
are not used.
|
|
Reported-by: Javier Sixto
Fixes #1955
Closes #1956
|
|
Reported-by: Wyatt O'Day
Fixes #1945
Closes #1947
|
|
Closes https://github.com/curl/curl/pull/1794
|
|
Compare these settings in Curl_ssl_config_matches():
- verifystatus (CURLOPT_SSL_VERIFYSTATUS)
- random_file (CURLOPT_RANDOM_FILE)
- egdsocket (CURLOPT_EGDSOCKET)
Also copy the setting "verifystatus" in Curl_clone_primary_ssl_config(),
and copy the setting "sessionid" unconditionally.
This means that reusing connections that are secured with a client
certificate is now possible, and the statement "TLS session resumption
is disabled when a client certificate is used" in the old advisory at
https://curl.haxx.se/docs/adv_20170419.html is obsolete.
Reviewed-by: Daniel Stenberg
Closes #1917
|
|
.. and include the core NTLM header in all NTLM-related source files.
Follow up to 6f86022. Since then http_ntlm checks NTLM_NEEDS_NSS_INIT
but did not include vtls.h where it was defined.
Closes https://github.com/curl/curl/pull/1911
|
|
With the recently introduced MultiSSL support multiple SSL backends
can be compiled into cURL That means that now the order of the SSL
One option would be to use the same SSL backend as was configured
via `curl_global_sslset()`, however, NTLMv2 support would appear
to be available only with some SSL backends. For example, when
eb88d778e (ntlm: Use Windows Crypt API, 2014-12-02) introduced
support for NTLMv1 using Windows' Crypt API, it specifically did
*not* introduce NTLMv2 support using Crypt API at the same time.
So let's select one specific SSL backend for NTLM support when
compiled with multiple SSL backends, using a priority order such
that we support NTLMv2 even if only one compiled-in SSL backend can
be used for that.
Ref: https://github.com/curl/curl/pull/1848
|
|
... it just returns error:
Bug: https://github.com/curl/curl/commit/1328f69d53f2f2e937696ea954c480412b018451#commitcomment-24470367
Reported-by: Marcel Raad
Closes #1906
|
|
In some cases the RSA key does not support verifying it because it's
located on a smart card, an engine wants to hide it, ...
Check the flags on the key before trying to verify it.
OpenSSL does the same thing internally; see ssl/ssl_rsa.c
Closes #1904
|
|
Schannel can only encrypt a certain amount of data at once. Instead of
failing when too much data is to be sent at once, send as much data as
we can and let the caller send the remaining data by calling send again.
Bug: https://curl.haxx.se/mail/lib-2014-07/0033.html
Closes https://github.com/curl/curl/pull/1890
|
|
lib/vtls/openssl.c uses OpenSSL APIs from BUF_MEM and BIO APIs. Include
their headers directly rather than relying on other OpenSSL headers
including things.
Closes https://github.com/curl/curl/pull/1891
|
|
|
|
|
|
|
|
CA path processing was implemented when mbedtls.c was added to libcurl
in fe7590f, but it was never enabled.
Bug: https://github.com/curl/curl/issues/1877
Reported-by: SBKarr@users.noreply.github.com
|
|
Another mistake in my manual fixups of the largely mechanical
search-and-replace ("connssl->" -> "BACKEND->"), just like the previous
commit concerning HTTPS proxies (and hence not caught during my
earlier testing).
Fixes #1855
Closes #1871
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
In d65e6cc4f (vtls: prepare the SSL backends for encapsulated private
data, 2017-06-21), this developer prepared for a separation of the
private data of the SSL backends from the general connection data.
This conversion was partially automated (search-and-replace) and
partially manual (e.g. proxy_ssl's backend data).
Sadly, there was a crucial error in the manual part, where the wrong
handle was used: rather than connecting ssl[sockindex]' BIO to the
proxy_ssl[sockindex]', we reconnected proxy_ssl[sockindex]. The reason
was an incorrect location to paste "BACKEND->"... d'oh.
Reported by Jay Satiro in https://github.com/curl/curl/issues/1855.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
Ever since 70f1db321 (vtls: encapsulate SSL backend-specific data,
2017-07-28), the code handling HTTPS proxies was broken because the
pointer to the SSL backend data was not swapped between
conn->ssl[sockindex] and conn->proxy_ssl[sockindex] as intended, but
instead set to NULL (causing segmentation faults).
[jes: provided the commit message, tested and verified the patch]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
... instead of the prefix-less version since WolfSSL 3.12 now uses an
enum with that name that causes build failures for us.
Fixes #1865
Closes #1867
Reported-by: Gisle Vanem
|
|
|
|
- Do a case-insensitive comparison of CURL_SSL_BACKEND env as well.
- Change Curl_strcasecompare calls to strcasecompare
(maps to the former but shorter).
Follow-up to c290b8f.
Bug: https://github.com/curl/curl/commit/c290b8f#commitcomment-24094313
Co-authored-by: Jay Satiro
|
|
This is an adaptation of 2 of Peter Wu's SSLKEYLOGFILE implementations.
The first one, written for old OpenSSL versions:
https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/sslkeylog.c
The second one, written for BoringSSL and new OpenSSL versions:
https://github.com/curl/curl/pull/1346
Note the first one is GPL licensed but the author gave permission to
waive that license for libcurl.
As of right now this feature is disabled by default, and does not have
a configure option to enable it. To enable this feature define
ENABLE_SSLKEYLOGFILE when building libcurl and set environment
variable SSLKEYLOGFILE to a pathname that will receive the keys.
And in Wireshark change your preferences to point to that key file:
Edit > Preferences > Protocols > SSL > Master-Secret
Co-authored-by: Peter Wu
Ref: https://github.com/curl/curl/pull/1030
Ref: https://github.com/curl/curl/pull/1346
Closes https://github.com/curl/curl/pull/1866
|
|
Up2date versions of OpenSSL maintain the default reasonably secure
without breaking compatibility, so it is better not to override the
default by curl. Suggested at https://bugzilla.redhat.com/1483972
Closes #1846
|
|
... not *CACERT_BADFILE as it isn't really because of a bad file.
Bug: https://curl.haxx.se/mail/lib-2017-09/0002.html
Closes #1858
|
|
Closes #1849
|
|
- Fix handling certificate subjects that are already UTF-8 encoded.
Follow-up to b3b75d1 from two days ago. Since then a copy would be
skipped if the subject was already UTF-8, possibly resulting in a NULL
deref later on.
Ref: https://github.com/curl/curl/issues/1823
Ref: https://github.com/curl/curl/pull/1831
Closes https://github.com/curl/curl/pull/1836
|
|
... instead of cyassl, as this is the current name for it.
Closes #1844
|
|
Reported-by: Dan Fandrich
Bug: https://curl.haxx.se/mail/lib-2017-08/0121.html
Closes #1843
|
|
Previously, we used as default SSL backend whatever was first in the
`available_backends` array.
However, some users may want to override that default without patching
the source code.
Now they can: with the --with-default-ssl-backend=<backend> option of
the ./configure script.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
|
When only one SSL backend is configured, it is totally unnecessary to
let multissl_init() configure the backend at runtime, we can select the
correct backend at build time already.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|