The TLS backends convert the host name to SNI name and need to use that.
This involves cutting off any trailing dot and lowercasing.
Co-authored-by: Jay Satiro
Closes#8320
Commit b5a434f7f0 inhibits the warning
on implicit fallthrough cases, since the current coding of indicating
fallthrough with comments is falling out of fashion with new compilers.
This attempts to make the issue smaller by rewriting fallthroughs to no
longer fallthrough, via either breaking the cases or turning switch
statements into if statements.
lib/content_encoding.c: the fallthrough codepath is simply copied
into the case as it's a single line.
lib/http_ntlm.c: the fallthrough case skips a state in the state-
machine and fast-forwards to NTLMSTATE_LAST. Do this before the
switch statement instead to set up the states that we actually
want.
lib/http_proxy.c: the fallthrough is just falling into exiting the
switch statement which can be done easily enough in the case.
lib/mime.c: switch statement rewritten as if statement.
lib/pop3.c: the fallthrough case skips to the next state in the
statemachine, do this explicitly instead.
lib/urlapi.c: switch statement rewritten as if statement.
lib/vssh/wolfssh.c: the fallthrough cases fast-forwards the state
machine, do this by running another iteration of the switch
statement instead.
lib/vtls/gtls.c: switch statement rewritten as if statement.
lib/vtls/nss.c: the fallthrough codepath is simply copied into the
case as it's a single line. Also twiddle a comment to not be
inside a non-brace if statement.
Closes: #7322
See-also: #7295
Reviewed-by: Daniel Stenberg <daniel@haxx.se>
On connection shutdown, a new TLS session ticket may arrive after the
SSL session cache has already been destructed. In this case, the new
SSL session cannot be added to the SSL session cache.
The callers of Curl_ssl_addsessionid() need to know whether the SSL
session has been added to the cache. If it has not been added, the
reference counter of the SSL session must not be incremented, or memory
used by the SSL session must be freed. This is now possible with the new
output parameter "added" of Curl_ssl_addsessionid().
Fixes#7683Closes#7752
- the data needs to be "line-based" anyway since it's also passed to the
debug callback/application
- it makes infof() work like failf() and consistency is good
- there's an assert that triggers on newlines in the format string
- Also removes a few instances of "..."
- Removes the code that would append "..." to the end of the data *iff*
it was truncated in infof()
Closes#7357
This avoids a TCP reset (RST) if the server initiates a connection
shutdown by sending an SSL close notify alert and then closes the TCP
connection.
For SSL connections, usually the server announces that it will close the
connection with an SSL close notify alert. curl should read this alert.
If curl does not read this alert and just closes the connection, some
operating systems close the TCP connection with an RST flag.
See RFC 1122, section 4.2.2.13
If curl reads the close notify alert, the TCP connection is closed
normally with a FIN flag.
The new code is similar to existing code in the "SSL shutdown" function:
try to read an alert (non-blocking), and ignore any read errors.
Closes#7095
Previously, settting only the max allowed TLS version, leaving the
minimum one at default, didn't actually set it and left it to default
(TLS 1.3) too!
As a bonus, this change also removes the dead code handling of SSLv3
since that version can't be set anymore (since eff614fb02).
Reported-by: Daniel Carpenter
Fixes#6998Closes#7000
This abstracts across the two HTTP/2 backends: nghttp2 and Hyper.
Add our own define for the "h2" ALPN protocol, so TLS backends can use
it without depending on a specific HTTP backend.
Closes#6959
for GnuTLS, BearSSL, mbedTLS, NSS, SChannnel, Secure Transport and
wolfSSL...
Regression since 88dd1a8a11 (shipped in 7.76.0)
Reported-by: Kenneth Davidson
Reported-by: romamik om github
Fixes#6825Closes#6827
Rename it to 'httpwant' and make a cloned field in the state struct as
well for run-time updates.
Also: refuse non-supported HTTP versions. Verified with test 129.
Closes#6585
... in most cases instead of 'struct connectdata *' but in some cases in
addition to.
- We mostly operate on transfers and not connections.
- We need the transfer handle to log, store data and more. Everything in
libcurl is driven by a transfer (the CURL * in the public API).
- This work clarifies and separates the transfers from the connections
better.
- We should avoid "conn->data". Since individual connections can be used
by many transfers when multiplexing, making sure that conn->data
points to the current and correct transfer at all times is difficult
and has been notoriously error-prone over the years. The goal is to
ultimately remove the conn->data pointer for this reason.
Closes#6425
configure --enable-debug now enables -Wassign-enum with clang,
identifying several enum "abuses" also fixed.
Reported-by: Gisle Vanem
Bug: 879007f811 (commitcomment-42087553)Closes#5929
USE_TLS_SRP will be true if *any* selected TLS backend can use SRP
HAVE_OPENSSL_SRP is defined when OpenSSL can use it
HAVE_GNUTLS_SRP is defined when GnuTLS can use it
Clarify in the curl_verison_info docs that CURL_VERSION_TLSAUTH_SRP is
set if at least one of the supported backends offers SRP.
Reported-by: Stefan Strogin
Fixes#5865Closes#5870
`http_proxy`/`proxy_ssl`/`tunnel_proxy` will not be available in `conn`
if `CURL_DISABLE_PROXY` is enabled. Repair the build with that
configuration.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Closes#5645
GnuTLS 3.1.10 added new functions we want to use. That version was
released on Mar 22, 2013. Removing support for older versions also
greatly simplifies the code.
Ref: #5271Closes#5276
When SRP is requested in the priority string, GnuTLS will disable
support for TLS 1.3. Before this change, curl would always add +SRP to
the priority list, effectively always disabling TLS 1.3 support.
With this change, +SRP is only added to the priority list when SRP
authentication is also requested. This also allows updating the error
handling here to not have to retry without SRP. This is because SRP is
only added when requested and in that case a retry is not needed.
Closes#5223
TLS servers may request a certificate from the client. This request
includes a list of 0 or more acceptable issuer DNs. The client may use
this list to determine which certificate to send. GnuTLS's default
behavior is to not send a client certificate if there is no
match. However, OpenSSL's default behavior is to send the configured
certificate. The `GNUTLS_FORCE_CLIENT_CERT` flag mimics OpenSSL
behavior.
Authored-by: jethrogb on github
Fixes#1411Closes#4958
... as it can make it wait there for a long time for no good purpose.
Patched-by: Jay Satiro
Reported-by: Bylon2 on github
Adviced-by: Nikos Mavrogiannopoulos
Fixes#4487Closes#4541
They serve very little purpose and mostly just add noise. Most of them
have been around for a very long time. I read them all before removing
or rephrasing them.
Ref: #3876Closes#3883
As soon as a TLS backend gets ALPN conformation about the specific HTTP
version it can now set the multiplex situation for the "bundle" and
trigger moving potentially queued up transfers to the CONNECT state.
The function does not return the same value as snprintf() normally does,
so readers may be mislead into thinking the code works differently than
it actually does. A different function name makes this easier to detect.
Reported-by: Tomas Hoger
Assisted-by: Daniel Gustafsson
Fixes#3296Closes#3297
- Treat CURL_SSLVERSION_MAX_NONE the same as
CURL_SSLVERSION_MAX_DEFAULT. Prior to this change NONE would mean use
the minimum version also as the maximum.
This is a follow-up to 6015cef which changed the behavior of setting
the SSL version so that the requested version would only be the minimum
and not the maximum. It appears it was (mostly) implemented in OpenSSL
but not other backends. In other words CURL_SSLVERSION_TLSv1_0 used to
mean use just TLS v1.0 and now it means use TLS v1.0 *or later*.
- Fix CURL_SSLVERSION_MAX_DEFAULT for OpenSSL.
Prior to this change CURL_SSLVERSION_MAX_DEFAULT with OpenSSL was
erroneously treated as always TLS 1.3, and would cause an error if
OpenSSL was built without TLS 1.3 support.
Co-authored-by: Daniel Gustafsson
Fixes https://github.com/curl/curl/issues/2969
Closes https://github.com/curl/curl/pull/3012
... instead of previous separate struct fields, to make it easier to
extend and change individual backends without having to modify them all.
closes#2547
unit1309 and vtls/gtls: error: arithmetic on a null pointer treated as a
cast from integer to pointer is a GNU extension
Reported-by: Rikard Falkeborn
Fixes#2466Closes#2468
When targeting x64, MinGW-w64 complains about conversions between
32-bit long and 64-bit pointers. Fix this by reusing the
GNUTLS_POINTER_TO_SOCKET_CAST / GNUTLS_SOCKET_TO_POINTER_CAST logic
from gtls.c, moving it to warnless.h as CURLX_POINTER_TO_INTEGER_CAST /
CURLX_INTEGER_TO_POINTER_CAST.
Closes https://github.com/curl/curl/pull/2341
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>
These functions are all available via the Curl_ssl struct now, no need
to declare them separately anymore.
As the global declarations are removed, the corresponding function
definitions are marked as file-local. The only two exceptions here are
Curl_mbedtls_shutdown() and Curl_polarssl_shutdown(): only the
declarations were removed, there are no function definitions to mark
file-local.
Please note that Curl_nss_force_init() is *still* declared globally, as
the only SSL backend-specific function, because it was introduced
specifically for the use case where cURL was compiled with
`--without-ssl --with-nss`. For details, see f3b77e561 (http_ntlm: add
support for NSS, 2010-06-27).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The entire idea of introducing the Curl_ssl struct to describe SSL
backends is to prepare for choosing the SSL backend at runtime.
To that end, convert all the #ifdef have_curlssl_* style conditionals
to use bit flags instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The SHA-256 checksumming is also an SSL backend-specific function.
Let's include it in the struct declaring the functionality of SSL
backends.
In contrast to MD5, there is no fall-back code. To indicate this, the
respective entries are NULL for those backends that offer no support for
SHA-256 checksumming.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The MD5 summing is also an SSL backend-specific function. So let's
include it, offering the previous fall-back code as a separate function
now: Curl_none_md5sum(). To allow for that, the signature had to be
changed so that an error could be returned from the implementation
(Curl_none_md5sum() can run out of memory).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the first step to unify the SSL backend handling. Now all the
SSL backend-specific functionality is accessed via a global instance of
the Curl_ssl struct.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of introducing the Curl_ssl struct was to unify how the SSL
backends are declared and called. To this end, we now provide an
instance of the Curl_ssl struct for each and every SSL backend.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch makes the signature of the _cleanup() functions consistent
among the SSL backends, in preparation for unifying the way all SSL
backends are accessed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
- Change gnutls pointer/int macros to pointer/curl_socket_t.
Prior to this change they used long type as well.
The size of the `long` data type can be shorter than that of pointer
types. This is the case most notably on Windows.
If C99 were acceptable, we could simply use `intptr_t` here. But we
want to retain C89 compatibility.
Simply use the trick of performing pointer arithmetic with the NULL
pointer: to convert an integer `i` to a pointer, simply take the
address of the `i`th element of a hypothetical character array
starting at address NULL. To convert back, simply cast the pointer
difference.
Thanks to Jay Satiro for the initial modification to use curl_socket_t
instead of int/long.
Closes#1617
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit introduces the CURL_SSLVERSION_MAX_* constants as well as
the --tls-max option of the curl tool.
Closes https://github.com/curl/curl/pull/1166
Check for presence of gnutls_alpn_* and gnutls_ocsp_* functions during
configure instead of relying on the version number. GnuTLS has options
to turn these features off and we ca just work with with such builds
like we work with older versions.
Signed-off-by: Marcus Hoffmann <m.hoffmann@cartelsol.com>
Closes#1204
vtls/gtls.c: In function ‘Curl_gtls_data_pending’:
vtls/gtls.c:1429:3: error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
if(conn->proxy_ssl[connindex].session &&
^~
vtls/gtls.c:1433:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
return res;
* 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
