Dan Fandrich [Fri, 29 Sep 2017 23:20:56 +0000 (01:20 +0200)]
Set and use more necessary options when some protocols are disabled
When curl and libcurl are built with some protocols disabled, they stop
setting and receiving some options that don't make sense with those
protocols. In particular, when HTTP is disabled many options aren't set
that are used only by HTTP. However, some options that appear to be
HTTP-only are actually used by other protocols as well (some despite
having HTTP in the name) and should be set, but weren't. This change now
causes some of these options to be set and used for more (or for all)
protocols. In particular, this fixes tests 646 through 649 in an
HTTP-disabled build, which use the MIME API in the mail protocols.
Michael Kaufmann [Sun, 24 Sep 2017 13:02:12 +0000 (15:02 +0200)]
reuse_conn: don't copy flags that are known to be equal
A connection can only be reused if the flags "conn_to_host" and
"conn_to_port" match. Therefore it is not necessary to copy these flags
in reuse_conn().
Viktor Szakats [Tue, 12 Sep 2017 18:14:00 +0000 (18:14 +0000)]
metalink: fix NSS issue in MultiSSL builds
In MultiSSL mode (i.e. when more than one SSL backend is compiled
in), we cannot use the compile time flag `USE_NSS` as indicator that
the NSS backend is in use. As far as Metalink is concerned, the SSL
backend is only used for MD5, SHA-1 and SHA-256 calculations,
therefore one of the available SSL backends is selected at compile
time, in a strict order of preference.
Let's introduce a new `HAVE_NSS_CONTEXT` constant that can be used
to determine whether the SSL backend used for Metalink is the NSS
backend, and use that to guard the code that wants to de-initialize
the NSS-specific data structure.
Viktor Szakats [Wed, 30 Aug 2017 21:10:38 +0000 (21:10 +0000)]
ntlm: use strict order for SSL backend #if branches
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.
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
Max Dymond [Mon, 11 Sep 2017 19:51:58 +0000 (20:51 +0100)]
ossfuzz: changes before merging the generated corpora
Before merging in the oss-fuzz corpora from Google, there are some changes
to the fuzzer.
- Add a read corpus script, to display corpus files nicely.
- Change the behaviour of the fuzzer so that TLV parse failures all now
go down the same execution paths, which should reduce the size of the
corpora.
- Make unknown TLVs a failure to parse, which should decrease the size
of the corpora as well.
Daniel Stenberg [Sun, 17 Sep 2017 22:55:07 +0000 (00:55 +0200)]
cookies: reject oversized cookies
... instead of truncating them.
There's no fixed limit for acceptable cookie names in RFC 6265, but the
entire cookie is said to be less than 4096 bytes (section 6.1). This is
also what browsers seem to implement.
We now allow max 5000 bytes cookie header. Max 4095 bytes length per
cookie name and value. Name + value together may not exceed 4096 bytes.
Added test 1151 to verify
Bug: https://curl.haxx.se/mail/lib-2017-09/0062.html Reported-by: Kevin Smith
Closes #1894
Jay Satiro [Mon, 18 Sep 2017 07:07:57 +0000 (03:07 -0400)]
socks: fix incorrect port number in SOCKS4 error message
Prior to this change it appears the SOCKS5 port parsing was erroneously
used for the SOCKS4 error message, and as a result an incorrect port
would be shown in the error message.
Marc Aldorasi [Fri, 15 Sep 2017 17:00:05 +0000 (13:00 -0400)]
schannel: Support partial send for when data is too large
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.
David Benjamin [Fri, 15 Sep 2017 22:36:40 +0000 (18:36 -0400)]
openssl: add missing includes
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.
Now that the form API is deprecated and not used anymore in curl tool,
a lot of its features left untested. Test 650 attempts to check all these
features not tested elsewhere.
Jay Satiro [Wed, 6 Sep 2017 22:04:16 +0000 (18:04 -0400)]
configure: fix curl_off_t check's include order
- Prepend srcdir include path instead of append.
Prior to this change it was possible that during the check for the size
of curl_off_t the include path of a user's already installed curl could
come before the include path of the to-be-built curl, resulting in the
system.h of the former being incorrectly included for that check.
OpenSSL: fix yet another mistake while encapsulating SSL backend data
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>
Jay Satiro [Wed, 6 Sep 2017 21:39:21 +0000 (23:39 +0200)]
vtls: fix memory corruption
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>
- The part kind MIMEKIND_FILE and associated code are suppressed.
- Seek data origin offset not used anymore: suppressed.
- MIMEKIND_NAMEDFILE renamed MIMEKIND_FILE; associated fields/functions
renamed accordingly.
- Curl_getformdata() processes stdin via a callback.
Daniel Stenberg [Mon, 4 Sep 2017 10:24:41 +0000 (12:24 +0200)]
configure: remove --enable-soname-bump and SONAME_BUMP
Back in 2008, (and commit 3f3d6ebe665f3) we changed the logic in how we
determine the native type for `curl_off_t`. To really make sure we
didn't break ABI without bumping SONAME, we introduced logic that
attempted to detect that it would use a different size and thus not be
compatible. We also provided a manual switch that allowed users to tell
configure to bump SONAME by force.
Today, we know of no one who ever got a SONAME bump auto-detected and we
don't know of anyone who's using the manual bump feature. The auto-
detection is also no longer working since we introduced defining
curl_off_t in system.h (7.55.0).
Finally, this bumping logic is not present in the cmake build.
Jay Satiro [Tue, 5 Sep 2017 19:27:22 +0000 (15:27 -0400)]
openssl: Integrate Peter Wu's SSLKEYLOGFILE implementation
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
curl_mime_encoder() is operational and documented.
curl tool -F option is extended with ";encoder=".
curl tool --libcurl option generates calls to curl_mime_encoder().
New encoder tests 648 & 649.
Test 1404 extended with an encoder specification.
Kamil Dudka [Wed, 30 Aug 2017 12:12:10 +0000 (14:12 +0200)]
openssl: use OpenSSL's default ciphers by default
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