Age | Commit message (Collapse) | Author |
|
If the NSS code was in the middle of a non-blocking handshake and it
was asked to finish the handshake in blocking mode, it unexpectedly
continued in the non-blocking mode, which caused a FTPS connection
over CONNECT to fail with "(81) Socket not ready for send/recv".
Bug: https://bugzilla.redhat.com/1420327
|
|
|
|
Regression introduced in commit f682156a4fc6c4
Reported-by: John Kohl
Bug: https://curl.haxx.se/mail/lib-2017-01/0055.html
|
|
... they're already frowned upon in our source code style guide, this
now enforces the rule harder.
|
|
In order to make the code style more uniform everywhere
|
|
|
|
|
|
|
|
|
|
* HTTPS proxies:
An HTTPS proxy receives all transactions over an SSL/TLS connection.
Once a secure connection with the proxy is established, the user agent
uses the proxy as usual, including sending CONNECT requests to instruct
the proxy to establish a [usually secure] TCP tunnel with an origin
server. HTTPS proxies protect nearly all aspects of user-proxy
communications as opposed to HTTP proxies that receive all requests
(including CONNECT requests) in vulnerable clear text.
With HTTPS proxies, it is possible to have two concurrent _nested_
SSL/TLS sessions: the "outer" one between the user agent and the proxy
and the "inner" one between the user agent and the origin server
(through the proxy). This change adds supports for such nested sessions
as well.
A secure connection with a proxy requires its own set of the usual SSL
options (their actual descriptions differ and need polishing, see TODO):
--proxy-cacert FILE CA certificate to verify peer against
--proxy-capath DIR CA directory to verify peer against
--proxy-cert CERT[:PASSWD] Client certificate file and password
--proxy-cert-type TYPE Certificate file type (DER/PEM/ENG)
--proxy-ciphers LIST SSL ciphers to use
--proxy-crlfile FILE Get a CRL list in PEM format from the file
--proxy-insecure Allow connections to proxies with bad certs
--proxy-key KEY Private key file name
--proxy-key-type TYPE Private key file type (DER/PEM/ENG)
--proxy-pass PASS Pass phrase for the private key
--proxy-ssl-allow-beast Allow security flaw to improve interop
--proxy-sslv2 Use SSLv2
--proxy-sslv3 Use SSLv3
--proxy-tlsv1 Use TLSv1
--proxy-tlsuser USER TLS username
--proxy-tlspassword STRING TLS password
--proxy-tlsauthtype STRING TLS authentication type (default SRP)
All --proxy-foo options are independent from their --foo counterparts,
except --proxy-crlfile which defaults to --crlfile and --proxy-capath
which defaults to --capath.
Curl now also supports %{proxy_ssl_verify_result} --write-out variable,
similar to the existing %{ssl_verify_result} variable.
Supported backends: OpenSSL, GnuTLS, and NSS.
* A SOCKS proxy + HTTP/HTTPS proxy combination:
If both --socks* and --proxy options are given, Curl first connects to
the SOCKS proxy and then connects (through SOCKS) to the HTTP or HTTPS
proxy.
TODO: Update documentation for the new APIs and --proxy-* options.
Look for "Added in 7.XXX" marks.
|
|
- Fix GnuTLS code for CURL_SSLVERSION_TLSv1_2 that broke when the
TLS 1.3 support was added in 6ad3add.
- Homogenize across code for all backends the error message when TLS 1.3
is not available to "<backend>: TLS 1.3 is not yet supported".
- Return an error when a user-specified ssl version is unrecognized.
---
Prior to this change our code for some of the backends used the
'default' label in the switch statement (ie ver unrecognized) for
ssl.version and treated it the same as CURL_SSLVERSION_DEFAULT.
Bug: https://curl.haxx.se/mail/lib-2016-11/0048.html
Reported-by: Kamil Dudka
|
|
... with nss-3.26.0 and newer
Reported-by: Daniel Stenberg
|
|
Fully implemented with the NSS backend only for now.
Reviewed-by: Ray Satiro
|
|
... but make sure we use at least TLSv1.0 according to libcurl API
Reported-by: Cure53
Reviewed-by: Ray Satiro
|
|
follow-up to 811a693b80
|
|
This is a followup to commit 811a693b
|
|
We had some confusions on when each function was used. We should not act
differently on different locales anyway.
|
|
... in case the handshake completes before entering
CURLM_STATE_PROTOCONNECT
Bug: https://bugzilla.redhat.com/1388162
|
|
|
|
|
|
As it seems to be a rarely used cipher suite (for securely established
but _unencrypted_ connections), I believe it is fine not to provide an
alias for the misspelled variant.
|
|
Serialise the call to PK11_FindSlotByName() to avoid spurious errors in
a multi-threaded environment. The underlying cause is a race condition
in nssSlot_IsTokenPresent().
Bug: https://bugzilla.mozilla.org/1297397
Closes #985
|
|
... when we are not asked to use a certificate from file
|
|
|
|
|
|
Only protocols that actually have a protocol registered for ALPN and NPN
should try to get that negotiated in the TLS handshake. That is only
HTTPS (well, http/1.1 and http/2) right now. Previously ALPN and NPN
would wrongly be used in all handshakes if libcurl was built with it
enabled.
Reported-by: Jay Satiro
Fixes #789
|
|
It is wasteful to search it backwards if we look for _any_ slash.
|
|
We only care if at least one cipher-suite is enabled, so it does
not make any sense to iterate till the end and count all enabled
cipher-suites.
|
|
|
|
... and stick to 1.1 for HTTP. This is in line with what browsers do and
should have very little risk.
|
|
Add a "pinnedpubkey" section to the "Server Certificate" verbose
Bug: https://github.com/bagder/curl/issues/410
Reported-by: W. Mark Kubacki
Closes #430
Closes #410
|
|
Without this workaround, NSS re-uses a session cache entry despite the
server name does not match. This causes SNI host name to differ from
the actual host name. Consequently, certain servers (e.g. github.com)
respond by 400 to such requests.
Bug: https://bugzilla.mozilla.org/1202264
|
|
|
|
It causes dynamic linking issues at run-time after an update of NSS.
Bug: https://lists.fedoraproject.org/pipermail/devel/2015-September/214117.html
|
|
|
|
Bug: http://curl.haxx.se/mail/lib-2015-04/0095.html
|
|
Bug: https://bugzilla.redhat.com/1195771
|
|
This header file must be included after all header files except
memdebug.h, as it does similar memory function redefinitions and can be
similarly affected by conflicting definitions in system or dependent
library headers.
|
|
|
|
|
|
... if disabled at libcurl level. Otherwise, we would allow to
negotiate NPN despite curl was invoked with the --no-npn option.
|
|
|
|
The function "free" is documented in the way that no action shall occur for
a passed null pointer. It is therefore not needed that a function caller
repeats a corresponding check.
http://stackoverflow.com/questions/18775608/free-a-null-pointer-anyway-or-check-first
This issue was fixed by using the software Coccinelle 1.0.0-rc24.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
|
|
Since they already exist and will make comparing easier
|
|
|
|
No need to use _MPRINTF_REPLACE internally.
|
|
In that case, we only skip writing the error message for failed NSS
initialization (while still returning the correct error code).
|
|
The vtls layer now checks the return value, so it is no longer necessary
to abort if a random number cannot be provided by NSS. This also fixes
the following Coverity report:
Error: FORWARD_NULL (CWE-476):
lib/vtls/nss.c:1918: var_compare_op: Comparing "data" to null implies that "data" might be null.
lib/vtls/nss.c:1923: var_deref_model: Passing null pointer "data" to "Curl_failf", which dereferences it.
lib/sendf.c:154:3: deref_parm: Directly dereferencing parameter "data".
|
|
Correctly check for memcmp() return value (it returns 0 if the strings match).
This is not really important, since curl is going to use http/1.1 anyway, but
it's still a bug I guess.
|
|
Carrying on from commit 037cd0d991, removed the following unimplemented
instances of curlssl_close_all():
Curl_axtls_close_all()
Curl_darwinssl_close_all()
Curl_cyassl_close_all()
Curl_gskit_close_all()
Curl_gtls_close_all()
Curl_nss_close_all()
Curl_polarssl_close_all()
|