Age | Commit message (Collapse) | Author |
|
axTLS:
This will make the axTLS backend perform the RFC2818 checks, honoring
the VERIFYHOST setting similar to the OpenSSL backend.
Generic for OpenSSL and axTLS:
Move the hostcheck and cert_hostcheck functions from the lib/ssluse.c
files to make them genericly available for both the OpenSSL, axTLS and
other SSL backends. They are now in the new lib/hostcheck.c file.
CyaSSL:
CyaSSL now also has the RFC2818 checks enabled by default. There is a
limitation that the verifyhost can not be enabled exclusively on the
Subject CN field comparison. This SSL backend will thus behave like the
NSS and the GnuTLS (meaning: RFC2818 ok, or bust). In other words:
setting verifyhost to 0 or 1 will disable the Subject Alt Names checks
too.
Schannel:
Updated the schannel information messages: Split the IP address usage
message from the verifyhost setting and changed the message about
disabling SNI (Server Name Indication, used in HTTP virtual hosting)
into a message stating that the Subject Alternative Names checks are
being disabled when verifyhost is set to 0 or 1. As a side effect of
switching off the RFC2818 related servername checks with
SCH_CRED_NO_SERVERNAME_CHECK
(http://msdn.microsoft.com/en-us/library/aa923430.aspx) the SNI feature
is being disabled. This effect is not documented in MSDN, but Wireshark
output clearly shows the effect (details on the libcurl maillist).
PolarSSL:
Fix the prototype change in PolarSSL of ssl_set_session() and the move
of the peer_cert from the ssl_context to the ssl_session. Found this
change in the PolarSSL SVN between r1316 and r1317 where the
POLARSSL_VERSION_NUMBER was at 0x01010100. But to accommodate the Ubuntu
PolarSSL version 1.1.4 the check is to discriminate between lower then
PolarSSL version 1.2.0 and 1.2.0 and higher. Note: The PolarSSL SVN
trunk jumped from version 1.1.1 to 1.2.0.
Generic:
All the SSL backends are fixed and checked to work with the
ssl.verifyhost as a boolean, which is an internal API change.
|
|
Bug: http://curl.haxx.se/bug/view.cgi?id=3579286
|
|
After a research team wrote a document[1] that found several live source
codes out there in the wild that misused the CURLOPT_SSL_VERIFYHOST
option thinking it was a boolean, this change now bans 1 as a value and
will make libcurl return error for it.
1 was never a sensible value to use in production but was introduced
back in the days to help debugging. It was always documented clearly
this way.
1 was never supported by all SSL backends in libcurl, so this cleanup
makes the treatment of it unified.
The report's list of mistakes for this option were all PHP code and
while there's a binding layer between libcurl and PHP, the PHP team has
decided that they have an as thin layer as possible on top of libcurl so
they will not alter or specifically filter a 'TRUE' value for this
particular option. I sympathize with that position.
[1] = http://daniel.haxx.se/blog/2012/10/25/libcurl-claimed-to-be-dangerous/
|
|
|
|
Reported by Tatsuhiro Tsujikawa
http://curl.haxx.se/mail/lib-2012-06/0371.html
|
|
Before commit 2dded8fedba (dec 2010) there was logic that used
RAND_screen() at times and now I remove the leftover #ifdef check for
it.
The seeding code that uses Curl_FormBoundary() in ossl_seed() is dubious
to keep since it hardly increases randomness but I fear I'll break
something if I remove it now...
|
|
curl_ntlm_msgs.c would previously use an #ifdef maze and direct
SSL-library calls instead of using the SSL layer we have for this
purpose.
|
|
Calls to failf() are not supposed to provide trailing newline.
Calls to infof() must provide trailing newline.
Fixed 30 or so strings.
|
|
Previously it would use a 256 byte buffer and thus cut off very long
subject names. The limit is now upped to the receive buffer size, 16K.
Bug: http://curl.haxx.se/bug/view.cgi?id=3533045
Reported by: Anthony G. Basile
|
|
curl needs to be more chatty regarding certificate verification failure
during SSL handshake
|
|
This change replaces RFC 2818 based hostname check in OpenSSL build with
RFC 6125 [1] based one.
The hostname check in RFC 2818 is ambiguous and each project implements
it in the their own way and they are slightly different. I check curl,
gnutls, Firefox and Chrome and they are all different.
I don't think there is a bug in current implementation of hostname
check. But it is not as strict as the modern browsers do. Currently,
curl allows multiple wildcard character '*' and it matches '.'. (as
described in the comment in ssluse.c).
Firefox implementation is also based on RFC 2818 but it only allows at
most one wildcard character and it must be in the left-most label in the
pattern and the wildcard must not be followed by any character in the
label.[2] Chromium implementation is based on RFC 6125 as my patch does.
Firefox and Chromium both require wildcard in the left-most label in the
presented identifier.
This patch is more strict than the current implementation, so there may
be some cases where old curl works but new one does not. But at the same
time I think it is good practice to follow the modern browsers do and
follow the newer RFC.
[1] http://tools.ietf.org/html/rfc6125#section-6.4.3
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=159483
|
|
|
|
|
|
Allow an appliction to set libcurl specific SSL options. The first and
only options supported right now is CURLSSLOPT_ALLOW_BEAST.
It will make libcurl to disable any work-arounds the underlying SSL
library may have to address a known security flaw in the SSL3 and TLS1.0
protocol versions.
This is a reaction to us unconditionally removing that behavior after
this security advisory:
http://curl.haxx.se/docs/adv_20120124B.html
... it did however cause a lot of programs to fail because of old
servers not liking this work-around. Now programs can opt to decrease
the security in order to interoperate with old servers better.
|
|
OpenSSL added a work-around for a SSL 3.0/TLS 1.0 CBC vulnerability
(http://www.openssl.org/~bodo/tls-cbc.txt). In 0.9.6e they added a bit
to SSL_OP_ALL that _disables_ that work-around despite the fact that
SSL_OP_ALL is documented to do "rather harmless" workarounds.
The libcurl code uses the SSL_OP_ALL define and thus logically always
disables the OpenSSL fix.
In order to keep the secure work-around workding, the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS bit must not be set and this change
makes sure of this.
Reported by: product-security at Apple
|
|
avoid checking preprocessor definition official value
|
|
Leak triggered when CURLOPT_SSLCERTTYPE and CURLOPT_SSLKEYTYPE set to P12
and both CURLOPT_SSLCERT and CURLOPT_SSLKEY point to the same PKCS#12 file.
|
|
SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG option enabling allowed successfull
interoperability with web server Netscape Enterprise Server 2.0.1 released
back in 1996 more than 15 years ago.
Due to CVE-2010-4180, option SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG has
become ineffective as of OpenSSL 0.9.8q and 1.0.0c. In order to mitigate
CVE-2010-4180 when using previous OpenSSL versions we no longer enable
this option regardless of OpenSSL version and SSL_OP_ALL definition.
|
|
With this change, curl compiles with the new OPENSSL_NO_SSL_INTERN
cflag. This flag might become the default in some distant future.
|
|
If no SSLv2 was detected in OpenSSL by configure, then we enforce the
OPENSSL_NO_SSL2 define as it seems some people report it not being
defined properly in the OpenSSL headers.
|
|
Move calling of ERR_remove_state(0) a.k.a ERR_remove_thread_state(NULL)
from Curl_ossl_close_all() to Curl_ossl_cleanup().
In this way ERR_remove_state(0) is now only called in libcurl by
curl_global_cleanup(). Previously it would get called by functions
curl_easy_cleanup(), curl_multi_cleanup and potentially each time a
connection was removed from a connection cache leading to premature
destruction of OpenSSL's thread local state hash.
Multi-threaded apps using OpenSSL enabled libcurl should still call
function ERR_remove_state(0) or ERR_remove_thread_state(NULL) at the
very end end of threads that do not call curl_global_cleanup().
|
|
|
|
|
|
|
|
|
|
See also :
http://www.openssl.org/docs/ssl/SSL_CTX_set_mode.html
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
Signed-off-by: Cristian RodrÃguez <crrodriguez@opensuse.org>
|
|
|
|
It was mostly typecasted to int all over the code so switching to long
instead all over should be a net gain.
|
|
|
|
Fix compiler warning: enumerated type mixed with another type
|
|
By the use of a the new lib/checksrc.pl script that checks that our
basic source style rules are followed.
|
|
Found with codespell.
|
|
Massively reduce #ifdefs all over (23 #ifdef lines less so far)
Moved conversion-specific code to non-ascii.c
|
|
|
|
Allow openSSL without SSL2 to be used. This fix is inspired by the fix
provided by Cristian Rodríguez.
Reported by: Cristian Rodríguez
|
|
If a new enough OpenSSL version is used, configure detects the TLS-SRP
support and enables it.
|
|
The latter isn't available in older OpenSSL versions, and is
less useful since it returns the most recent error instead of
the first one encountered.
|
|
"SSL: couldn't create a context" really isn't that helpful, now it'll
also extract an explanation from OpenSSL and append to the right.
|
|
|
|
As the function doesn't really use the connectdata struct but only the
SessionHanadle struct I modified what argument it wants.
|
|
512 bytes turned out too short for some data, so now we allocate a
larger buffer instead
Bug: http://curl.haxx.se/mail/archive-2011-01/0002.html
|
|
The loop condition was wrong so keys larger than 340 bits would overflow
the local stack-based buffer.
|
|
RAND_screen() is slow, not thread-safe and not needed anymore since OpenSSL
uses the thread-safe win32 CryptoAPI nowadays.
|
|
ossl_connect_common() now checks whether or not 'struct
connectdata->state' is equal 'ssl_connection_complete' and if so, will
return CURLE_OK with 'done' set to 'TRUE'. This check prevents
ossl_connect_common() from creating a new ssl connection on an existing
ssl session which causes openssl to fail when it tries to parse an
encrypted TLS packet since the cipher data was effectively thrown away
when the new ssl connection was created.
Bug: http://curl.haxx.se/mail/lib-2010-11/0169.html
|
|
|
|
This reverts commit b0fd03f5b8d4520dd232a9d13567d16bd0ad8951,
4b2fbe1e97891f, afecd1aa13b4f, 68cde058f66b3
|
|
If you use a custom Host: name in a request to a SSL server, libcurl
will now use that given name when it verifies the server certificate to
be correct rather than using the host name used in the actual URL.
|
|
The redirect check is already done at the position where the customhost
field is assigned so there's no point in doing that a second time.
|
|
When given a custom host name in a Host: header, we can use it for
several different purposes other than just cookies, so we rename it and
use it for SSL SNI etc.
|
|
OpenSSL SNI host name should be set to the custom Host header, if the
user provided one.
|