This reverts commit 878cc3e532.
Reverted for breaking the x86_64 Linux build:
In file included from ../deps/openssl/openssl/include/openssl/bn.h:1:0,
from ../deps/openssl/openssl/crypto/bn/asm/../bn_lcl.h:115,
from ../deps/openssl/openssl/crypto/bn/asm/x86_64-gcc.c:1:
../deps/openssl/openssl/include/openssl/../../crypto/bn/bn.h:813:20: note: previous declaration of 'bn_add_words' was here
BN_ULONG bn_add_words(BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int num);
^
../deps/openssl/openssl/crypto/bn/asm/x86_64-gcc.c:210:15: error: conflicting types for 'bn_sub_words'
BN_ULONG bn_sub_words (BN_ULONG *rp, const BN_ULONG *ap, const BN_ULONG *bp,int n)
On Windows (and potentially other LP64 platforms), a long integer is
always 32-bits, even when the target architecture uses 64-bit pointers.
Signed-off-by: Bert Belder <bertbelder@gmail.com>
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.
Ben Noordhuis
Bert Belder
Fedor Indutny
Fedor Indutny
Alexis Campailla
Andrei Sedoi
Scott Blomquist