Add the `sessionTimeout` integral value to the list of options
recognized by `tls.createServer`.
This option will be useful for applications which need frequently
establish short-lived TLS connections to the same endpoint. The TLS
tickets RFC is an ideal option to reduce the socket setup overhead
for such scenarios, but the default ticket timeout value (5
minutes) is too low to be useful.
Commit f53441a added crypto.getCiphers() as a function that returns the
names of SSL ciphers.
Commit 14a6c4e then added crypto.getHashes(), which returns the names of
digest algorithms, but that creates a subtle inconsistency: the return
values of crypto.getHashes() are valid arguments to crypto.createHash()
but that is not true for crypto.getCiphers() - the returned values are
only valid for SSL/TLS functions.
Rectify that by adding tls.getCiphers() and making crypto.getCiphers()
return proper cipher names.
This is not a great fix, and it's a bug that's very tricky to reproduce.
Occasionally, while downloading a file, especially on Linux for some
reason, the pause/resume timing will be just right such that the
CryptoStream is in a 'reading' state, but actually has no data, so it
ought to pull more in. Because there's no reads happening, it just sits
there, and the process will exit
This is, fundamentally, a factor of how the HTTP implementation sits
atop CryptoStreams and TCP Socket objects, which is utterly horrible,
and needs to be rewritten. However, in the meantime, npm downloads are
prematurely exiting, causing hard-to-debug "cb() never called!" errors.
1. Get rid of unnecessary 'finishing' flag
2. Dont check both ending and ended. Extraneous.
Also: Remove extraneous 'finishing' flag, and don't check both 'ending'
and 'ended', since checking just 'ending' is sufficient.
This makes it so that `stream.push(chunk)` is the only way to signal the
end of reading, removing the confusing disparity between the
callback-style _read method, and the fact that most real-world streams
do not have a 1:1 corollation between the "please give me data" event,
and the actual arrival of a chunk of data.
It is still possible, of course, to implement a `CallbackReadable` on
top of this. Simply provide a method like this as the callback:
function readCallback(er, chunk) {
if (er)
stream.emit('error', er);
else
stream.push(chunk);
}
However, *only* fs streams actually would behave in this way, so it
makes not a lot of sense to make TCP, TLS, HTTP, and all the rest have
to bend into this uncomfortable paradigm.
lib/http.js is using stream._handle.readStart/readStop to control
data-flow coming out from underlying stream. If this methods are not
present - data might be buffered regardless of whether it'll be read.
see #4657
This adds a proxy for bytesWritten to the tls.CryptoStream. This
change makes the connection object more similar between HTTP and
HTTPS requests in an effort to avoid confusion.
See issue #4650 for more background information.
Don't allow connections to stall indefinitely if the SSL/TLS handshake does
not complete.
Adds a new tls.Server and https.Server configuration option, handshakeTimeout.
Fixes #4355.
Listen for the 'clientError' event that is emitted when a renegotation attack
is detected and close the connection.
Fixes test/pummel/test-https-ci-reneg-attack.js
This commit changes the default value of the rejectUnauthorized option from
false to true.
What that means is that tls.connect(), https.get() and https.request() will
reject invalid server certificates from now on, including self-signed
certificates.
There is an escape hatch: if you set the NODE_TLS_REJECT_UNAUTHORIZED
environment variable to the literal string "0", node.js reverts to its
old behavior.
Fixes #3949.
Throw an exception in the tls.Server constructor when the options object
doesn't contain either a PFX or a key/certificate combo.
Said change exposed a bug in simple/test-tls-junk-closes-server. Addressed.
Fixes #3941.
Update the default cipher list from RC4-SHA:AES128-SHA:AES256-SHA
to ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
in order to mitigate BEAST attacks.
The documentation suggested AES256-SHA but unfortunately that's a CBC cipher
and therefore susceptible to attacks.
Fixes #3900.
Commit 4e5fe2d changed the way how process.nextTick() works:
process.nextTick(function foo() {
process.nextTick(function bar() {
// ...
});
});
Before said commit, foo() and bar() used to run on separate event loop ticks
but that is no longer the case.
However, that's exactly the behavior that the TLS renegotiation attack guard
relies on. It gets called by OpenSSL and needs to defer the 'error' event to a
later tick because the default action is to destroy the TLS context - the same
context that OpenSSL currently operates on.
When things change underneath your feet, bad things happen and OpenSSL is no
exception. Ergo, use setImmediate() instead of process.nextTick() to ensure
that the 'error' event is actually emitted at a later tick.
Fixes #3840.
Make CLIENT_RENEG_LIMIT inclusive instead of exclusive, i.e. a limit of 2
means the peer can renegotiate twice, not just once.
Update pummel/test-tls-ci-reneg-attack accordingly and make it less timing
sensitive (and run faster) while we're at it.
Instead of allocating a new 64KB buffer each time when checking if there is
something to transform, continue to use the same buffer. Once the buffer is
exhausted, allocate a new buffer. This solves the problem of huge allocations
when small fragments of data are processed, but will also continue to work
well with big pieces of data.
- fix crash calling ClientRequest::setKeepAlive if the underlying request is
HTTPS.
- fix discarding of callback parameter when calling ClientRequest::setTimeout on
HTTPS requests.
- fix discarding of noDelay parameter when calling ClientRequest::setNoDelay on
HTTPS requests.
The TLS protocol allows (and sometimes requires) clients to renegotiate the
session. However, renegotiation requires a disproportional amount of server-side
resources, particularly CPU time, which makes it a potential vector for
denial-of-service attacks.
To mitigate this issue, we keep track of and limit the number of renegotiation
requests over time, emitting an error if the threshold is exceeded.
Previous API used form:
tls.connect(443, "google.com", options, ...)
now it's replaced with:
tls.connect({port: 443, host: "google.com", ...}, ...)
It simplifies argument parsing in `tls.connect` and makes the API
consistent with other parts.
Fixes #1983.
This fixes a critical bug see in MJR's production. Very difficult to build a
test case. Sometimes HTTPS server gets sockets that are hanging in a
half-duplex state.
Previously the return value of write was dependent on if it was paused or
not which was causing a strange error demoed in the previous commit.
Fixes #892
Also, secureOptions flag was added (and passed through) and allows
the context to have all supported SSL_OP_* set via createCredentials.
All SSL_OP_ flags (outside of ALL) have been added to constants.
