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
commit d3ab7c5a21 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
... 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#2004Closes#2005
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
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
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
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
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#1855Closes#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#1865Closes#1867
Reported-by: Gisle Vanem
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/1483972Closes#1846
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>
Let's add a compile time safe API to select an SSL backend. This
function needs to be called *before* curl_global_init(), and can be
called only once.
Side note: we do not explicitly test that it is called before
curl_global_init(), but we do verify that it is not called multiple times
(even implicitly).
If SSL is used before the function was called, it will use whatever the
CURL_SSL_BACKEND environment variable says (or default to the first
available SSL backend), and if a subsequent call to
curl_global_sslset() disagrees with the previous choice, it will fail
with CURLSSLSET_TOO_LATE.
The function also accepts an "avail" parameter to point to a (read-only)
NULL-terminated list of available backends. This comes in real handy if
an application wants to let the user choose between whatever SSL backends
the currently available libcurl has to offer: simply call
curl_global_sslset(-1, NULL, &avail);
which will return CURLSSLSET_UNKNOWN_BACKEND and populate the avail
variable to point to the relevant information to present to the user.
Just like with the HTTP/2 push functions, we have to add the function
declaration of curl_global_sslset() function to the header file
*multi.h* because VMS and OS/400 require a stable order of functions
declared in include/curl/*.h (where the header files are sorted
alphabetically). This looks a bit funny, but it cannot be helped.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is information about the compiled-in SSL backends that is really
no concern of any code other than the SSL backend itself, such as which
function (if any) implements SHA-256 summing.
And there is information that is really interesting to the user, such as
the name, or the curl_sslbackend value.
Let's factor out the latter into a publicly visible struct. This
information will be used in the upcoming API to set the SSL backend
globally.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When building software for the masses, it is sometimes not possible to
decide for all users which SSL backend is appropriate.
Git for Windows, for example, uses cURL to perform clones, fetches and
pushes via HTTPS, and some users strongly prefer OpenSSL, while other
users really need to use Secure Channel because it offers
enterprise-ready tools to manage credentials via Windows' Credential
Store.
The current Git for Windows versions use the ugly work-around of
building libcurl once with OpenSSL support and once with Secure Channel
support, and switching out the binaries in the installer depending on
the user's choice.
Needless to say, this is a super ugly workaround that actually only
works in some cases: Git for Windows also comes in a portable form, and
in a form intended for third-party applications requiring Git
functionality, in which cases this "swap out libcurl-4.dll" simply is
not an option.
Therefore, the Git for Windows project has a vested interest in teaching
cURL to make the SSL backend a *runtime* option.
This patch makes that possible.
By running ./configure with multiple --with-<backend> options, cURL will
be built with multiple backends.
For the moment, the backend can be configured using the environment
variable CURL_SSL_BACKEND (valid values are e.g. "openssl" and
"schannel").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
So far, all of the SSL backends' private data has been declared as
part of the ssl_connect_data struct, in one big #if .. #elif .. #endif
block.
This can only work as long as the SSL backend is a compile-time option,
something we want to change in the next commits.
Therefore, let's encapsulate the exact data needed by each SSL backend
into a private struct, and let's avoid bleeding any SSL backend-specific
information into urldata.h. This is also necessary to allow multiple SSL
backends to be compiled in at the same time, as e.g. OpenSSL's and
CyaSSL's headers cannot be included in the same .c file.
To avoid too many malloc() calls, we simply append the private structs
to the connectdata struct in allocate_conn().
This requires us to take extra care of alignment issues: struct fields
often need to be aligned on certain boundaries e.g. 32-bit values need to
be stored at addresses that divide evenly by 4 (= 32 bit / 8
bit-per-byte).
We do that by assuming that no SSL backend's private data contains any
fields that need to be aligned on boundaries larger than `long long`
(typically 64-bit) would need. Under this assumption, we simply add a
dummy field of type `long long` to the `struct connectdata` struct. This
field will never be accessed but acts as a placeholder for the four
instances of ssl_backend_data instead. the size of each ssl_backend_data
struct is stored in the SSL backend-specific metadata, to allow
allocate_conn() to know how much extra space to allocate, and how to
initialize the ssl[sockindex]->backend and proxy_ssl[sockindex]->backend
pointers.
This would appear to be a little complicated at first, but is really
necessary to encapsulate the private data of each SSL backend correctly.
And we need to encapsulate thusly if we ever want to allow selecting
CyaSSL and OpenSSL at runtime, as their headers cannot be included within
the same .c file (there are just too many conflicting definitions and
declarations for that).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
At the moment, cURL's SSL backend needs to be configured at build time.
As such, it is totally okay for them to hard-code their backend-specific
data in the ssl_connect_data struct.
In preparation for making the SSL backend a runtime option, let's make
the access of said private data a bit more abstract so that it can be
adjusted later in an easy manner.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the ongoing endeavor to abstract out all SSL backend-specific
functionality, this is the next step: Instead of hard-coding how the
different SSL backends access their internal data in getinfo.c, let's
implement backend-specific functions to do that task.
This will also allow for switching SSL backends as a runtime option.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
