After much investigation it turns out that the affected servers are
buggy. user-service.condenastdigital.com:443 in particular seems to
reject large TLS handshake records. Cutting down the number of
advertised ciphers or disabling SNI fixes the issue.
Similarly, passing { secureOptions: constants.SSL_OP_NO_TLSv1_2 }
seems to fix most connection issues with IIS servers.
Having to work around buggy servers is annoying for our users but not
a reason to downgrade OpenSSL. Therefore, revert it.
This reverts commit 4fdb8acdae.
This commit undoes the downgrade from OpenSSL v1.0.1e to v1.0.0f,
effectively upgrading OpenSSL to v1.0.1e again. The reason for the
downgrade was to work around compatibility issues with certain TLS
servers in the stable branch. See the commit log of 4fdb8ac and the
linked issue for details. We're going to revisit that in the master
branch.
This reverts commit 4fdb8acdae.
Several people have reported issues with IIS and Resin servers (or maybe
SSL terminators sitting in front of those servers) that are fixed by
downgrading OpenSSL. The AESNI performance improvements were nice but
stability is more important. Downgrade OpenSSL from 1.0.1e to 1.0.0f.
Fixes#5360 (and others).
Microsoft's IIS doesn't support it, and is not replying with ServerHello
after receiving ClientHello which contains it.
The good way might be allowing to opt-out this at runtime from
javascript-land, but unfortunately OpenSSL doesn't support it right now.
see #5119
Commit 8632af3 ("tools: update gyp to r1601") broke the Windows build.
Older versions of GYP link to kernel32.lib, user32.lib, etc. but that
was changed in r1584. See https://codereview.chromium.org/12256017
Fix the build by explicitly linking to the required libraries.
There are no unsafe structured exception handlers in object files
generated from hand-crafted assembly - because they contain no exception
handlers at all.
There are no unsafe structured exception handlers in object files
generated from hand-crafted assembly - because they contain no exception
handlers at all.
ASN1_STRING_to_UTF8() passes an ASN1_STRING to ASN1_STRING_set() but forgot to
initialize the `length` field.
Fixes the following valgrind error:
$ valgrind -q --track-origins=yes --num-callers=19 \
out/Debug/node test/simple/test-tls-client-abort.js
==2690== Conditional jump or move depends on uninitialised value(s)
==2690== at 0x784B69: ASN1_STRING_set (asn1_lib.c:382)
==2690== by 0x809564: ASN1_mbstring_ncopy (a_mbstr.c:204)
==2690== by 0x8090F0: ASN1_mbstring_copy (a_mbstr.c:86)
==2690== by 0x782F1F: ASN1_STRING_to_UTF8 (a_strex.c:570)
==2690== by 0x78F090: asn1_string_canon (x_name.c:409)
==2690== by 0x78EF17: x509_name_canon (x_name.c:354)
==2690== by 0x78EA7D: x509_name_ex_d2i (x_name.c:210)
==2690== by 0x788058: ASN1_item_ex_d2i (tasn_dec.c:239)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x787C93: ASN1_item_d2i (tasn_dec.c:136)
==2690== by 0x78F5E4: d2i_X509 (x_x509.c:141)
==2690== by 0x7C9B91: PEM_ASN1_read_bio (pem_oth.c:81)
==2690== by 0x7CA506: PEM_read_bio_X509 (pem_x509.c:67)
==2690== by 0x703C9A: node::crypto::SecureContext::AddRootCerts(v8::Arguments const&) (node_crypto.cc:497)
==2690== Uninitialised value was created by a stack allocation
==2690== at 0x782E89: ASN1_STRING_to_UTF8 (a_strex.c:560)
When perlasm generates MASM code it sets the assembler target to 468.
In this mode MASM refuses to assemble a couple of instructions. Bumping
the target to 686 solves this problem.
When perlasm generates MASM code it sets the assembler target to 468.
In this mode MASM refuses to assemble a couple of instructions. Bumping
the target to 686 solves this problem.
This patch brings the openssl library that is built with gyp closer
to what the standard build system produces.
All opensslconf.h versions are now merged into a single file, which
makes it easier for compiled addons to locate this file.
This reverts commit 1c88c3b3b5.
It breaks the "read a password from stdin" functionality that OpenSSL provides.
Fixes#4059, #4143.
Conflicts:
deps/openssl/openssl.gyp
When perlasm generates MASM code it sets the assembler target to 468.
In this mode MASM refuses to assemble the CPUID instruction. Bumping
the target to 586 solves this problem.
These patches were provided by Android and Chromium. In this form they
are not useful. The ones that we need are landed as separate commits.
As of openssl 1.0.1c, three of them made it upstream:
* npn.patch (Next Protocol Negotiation support)
* tls_exporter.patch (RFC 5705 Keying Material Exporters for TLS)
* openssl_no_dtls1.patch (minor bugfix)
Use a empty implementation for function OPENSSL_cpuid_setup to resolve link
error. We should figure out how to geenrate platform specific implementation
of OPENSSL_cpuid_setup by leveraging crypto/*cpuid.pl.
This patch is taken from Chromium.
ASN1_STRING_to_UTF8() passes an ASN1_STRING to ASN1_STRING_set() but
forgot to initialize the `length` field.
Fixes the following valgrind error:
$ valgrind -q --track-origins=yes --num-callers=19 \
out/Debug/node test/simple/test-tls-client-abort.js
==2690== Conditional jump or move depends on uninitialised value(s)
==2690== at 0x784B69: ASN1_STRING_set (asn1_lib.c:382)
==2690== by 0x809564: ASN1_mbstring_ncopy (a_mbstr.c:204)
==2690== by 0x8090F0: ASN1_mbstring_copy (a_mbstr.c:86)
==2690== by 0x782F1F: ASN1_STRING_to_UTF8 (a_strex.c:570)
==2690== by 0x78F090: asn1_string_canon (x_name.c:409)
==2690== by 0x78EF17: x509_name_canon (x_name.c:354)
==2690== by 0x78EA7D: x509_name_ex_d2i (x_name.c:210)
==2690== by 0x788058: ASN1_item_ex_d2i (tasn_dec.c:239)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x787C93: ASN1_item_d2i (tasn_dec.c:136)
==2690== by 0x78F5E4: d2i_X509 (x_x509.c:141)
==2690== by 0x7C9B91: PEM_ASN1_read_bio (pem_oth.c:81)
==2690== by 0x7CA506: PEM_read_bio_X509 (pem_x509.c:67)
==2690== by 0x703C9A: node::crypto::SecureContext::AddRootCerts(v8::Arguments const&) (node_crypto.cc:497)
==2690== Uninitialised value was created by a stack allocation
==2690== at 0x782E89: ASN1_STRING_to_UTF8 (a_strex.c:560)
There are many symbolic links under /etc/ssl/certs created by using hash of
the pem certificates in order for OpenSSL to find those certificate.
Openssl has a tool to help you create hash symbolic links. (See tools/c_rehash)
However the new openssl changed the hash algorithm, Unless you compile/install
the latest openssl library and re-create all related symbolic links, the new
openssl can not find some certificates because the links of those certificates
were created by using old hash algorithm, which causes some tests failed.
This patch gives a way to find a certificate according to its hash by using both
new algorithm and old algorithm.
crbug.com/111045 is used to track this issue.
This patch is taken from the Chromium project.
Enables SSL3+ clients to send application data immediately following the
Finished message even when negotiating full-handshakes. With this patch,
clients can negotiate SSL connections in 1-RTT even when performing
full-handshakes.
This patch is taken from the Android Open Source Project.
Fedor Indutny
Andrei Sedoi
Ben Noordhuis
Bert Belder
Scott Blomquist
isaacs
Shigeki Ohtsu