TLSCallbacks => TLSWrap, better TLS inception #840

indutny · 2015-02-13T22:59:50Z

Ohai @iojs/crypto @iojs/streams .

This is very important thing for both of you! Please take a look at it, even if you don't think that you should actually review it.

Since introduction of TLSWrap concept and _tls_wrap.js/_tls_legacy.js files, there was a big concept gap that needed to be filled. The TLSSocket itself is parasiting (consuming) the original TCP socket, making the reads from the raw TCP socket go directly into OpenSSL, thus improving the performance significantly.

However, there was a major drawbacks:

the original socket is unusable after creation of TLSSocket
the original socket is replaced by TLSSocket thing
no way to wrap non-TCP/non-Pipe stream with TLSSocket
and so no way to wrap TLSSocket in TLSSocket (see test/parallel/test-tls-inception.js)
no way to start TLSSocket on plain javascript stream (this is why I've cc'ed @iojs/streams )

This PR should solve first 4 issues, and a follow-up will solve the last one. The main idea of a fix is to separate concept of StreamWrap C++ class from the HandleWrap class. I.e. make C++ streams independent of internal libuv socket/pipe. Next step that it does is a TLSWrap C++ stream that consumes the input of the input stream and proxies writes to itself to the underlying TCP stream (performing encryption and TLS protocol on this way).

4th step will be fixed by introducing JSStreamWrap C++ class, which will emulate C++ input events from JS-land.

Please take a look and review!

Thank you.

indutny · 2015-02-13T23:00:01Z

cc @bnoordhuis @chrisdickinson @trevnorris

indutny · 2015-02-13T23:00:22Z

@bnoordhuis : would be cool to land ASAP, as it'll be impossible to rebase in case of major conflicts :)

indutny · 2015-02-13T23:02:29Z

The interesting question is what semver tag should it have. Technically, there are some differences regarding the this.ssl => this._handle move (though, it is undocumented and internal), and could be some possible behavior changes. But I think we could address it as a bugfixes.

What are your thoughts, semver-patch/semver-minor/semver-major?

indutny · 2015-02-13T23:03:51Z

One more thing! There are some C++ lint issues, but I think they are mostly a bugs of cpplint itself.

wraithan · 2015-02-13T23:05:10Z

I was using this.ssl when hunting the memory leak in 0.10 tls. But it wasn't for anything that I'd actually release just for debugging. I after reading through all of the tls code I don't imagine anyone else is using it and it makes this interface more consistent with others.

indutny · 2015-02-13T23:07:27Z

@wraithan I'm going to create a legacy property for this purpose right now. Thanks!

indutny · 2015-02-13T23:07:42Z

@wraithan - done

wraithan · 2015-02-13T23:11:09Z

lib/_tls_wrap.js

-    }
-    socket.once('connect', onHandle);
-  }
+  socket = new TLSSocket(options.socket, {


there a reason this isn't just var socket = instead of forward declaring it 2 lines above? Same for var result which could be collapsed

chrisdickinson · 2015-02-13T23:22:15Z

lib/_tls_wrap.js

@@ -437,49 +478,56 @@ TLSSocket.prototype._finishInit = function() {
 };

 TLSSocket.prototype._start = function() {


Is it possible that the once below could set multiple listeners for connect, causing _start to be called >1?

Start is called only once, otherwise assertion will happen in C++.

indutny · 2015-02-13T23:28:46Z

@trevnorris mind helping with benchmark it against current v1.x?

chrisdickinson · 2015-02-13T23:31:15Z

lib/net.js

+  // Update handle if it was wrapped
+  handle = self._handle;
+  // TODO(indutny): assert that the handle is actually an ancestor of old one
+  // assert(handle === self._handle, 'handle != self._handle');


Does the following diagram encapsulate the behavior after wrapping?

A B C Readable -> net.Socket -> TLSWrap -> TCPWrap TCPWrap -> TLSWrap -> net.Socket -> Writable D E F A: cleartext bytes B: cleartext bytes C: encrypted bytes D: encrypted bytes E: cleartext bytes F: cleartext bytes

I think the Readble/Writable should be swapped with this direction of arrows, but generally this is correct.

I'm using Readable as "userland readable stream" – so bytes written to the socket will always hit TLSWrap on egress.

rvagg · 2015-02-13T23:38:16Z

any numbers on performance for this?

chrisdickinson · 2015-02-13T23:39:38Z

src/stream_base.cc

+  // Determine storage size first
+  size_t storage_size = 0;
+  for (size_t i = 0; i < count; i++) {
+    Handle<Value> chunk = chunks->Get(i * 2);


Why use chunks->Length() >> 1 above but i * 2 here (instead of i << 1)?

This is a question for a separate issue, I was only migrating old code base here.

Cool, just wanted to make sure I wasn't missing something.

indutny · 2015-02-13T23:47:13Z

@rvagg: @trevnorris is much better at this than I am, hopefully he will help us :)

chrisdickinson · 2015-02-14T00:03:13Z

I read through it – it looks good to me, though I'd like to get a more experienced C++ reviewer's eyes on it. I confess I'm having a bit of a hard time conceptualizing the entire route from "write to TLSSocket in JS" to "write bytes to the network", and vice versa.

If this works like I think it does, would it be possible to, for example, make the zlib transform streams nested in a similar fashion (by doing the compressing/decompressing work in the uv threadpool)? Or for a perhaps sillier point, to pass a duplex stream representing a FIFO into TLSSocket from JS?

indutny · 2015-02-14T10:04:36Z

Yes, though, you won't be able to do zlib compress in the same uv_work_t call. It will be two separate thread pool requests.

indutny · 2015-02-14T11:03:07Z

@chrisdickinson thanks for taking a look!

indutny · 2015-02-14T21:54:22Z

@rvagg: benchmarks appears to be unaffected, which is great!

~/Code/indutny/node $ ./iojs benchmark/net/net-s2c.js
net/net-s2c.js len=102400 type=utf dur=5: 6.26616
net/net-s2c.js len=102400 type=asc dur=5: 10.68418
net/net-s2c.js len=102400 type=buf dur=5: 12.35287
net/net-s2c.js len=16777216 type=utf dur=5: 5.78789
net/net-s2c.js len=16777216 type=asc dur=5: 9.41214
net/net-s2c.js len=16777216 type=buf dur=5: 13.59318
~/Code/indutny/node $ iojs benchmark/net/net-s2c.js
net/net-s2c.js len=102400 type=utf dur=5: 6.33293
net/net-s2c.js len=102400 type=asc dur=5: 11.07404
net/net-s2c.js len=102400 type=buf dur=5: 12.34970
net/net-s2c.js len=16777216 type=utf dur=5: 5.66070
net/net-s2c.js len=16777216 type=asc dur=5: 9.64388
net/net-s2c.js len=16777216 type=buf dur=5: 13.89736

indutny · 2015-02-15T23:19:15Z

Another idea. What about exposing this API and adding a "standard" way to wrap stream?

trevnorris · 2015-02-16T22:40:25Z

lib/_tls_wrap.js

+    res[name] = function methodProxy() {
+      return handle[name].apply(handle, arguments);
+    };
+  });


Not in love with this solution, but too lazy right now to suggest a better one.

Can't say that I like it either. But the thing is that somehow HandleWrap, StreamWrap methods should be called. This definitely better be abstracted in JS.

Will this not leak arguments, making optimization impossible?

This usually applies to close and connect methods. Nothing performance critical.

indutny · 2015-02-21T00:16:03Z

@trevnorris thank you!

@bnoordhuis going to push it in a couple of days. I have already rebased it twice with merge conflicts :(

indutny · 2015-02-22T18:57:20Z

Guess it is time to land it :)

StreamBase is an improved way to write C++ streams. The class itself is for separting `StreamWrap` (with the methods like `.writeAsciiString`, `.writeBuffer`, `.writev`, etc) from the `HandleWrap` class, making possible to write abstract C++ streams that are not bound to any uv socket. The following methods are important part of the abstraction (which mimics libuv's stream API): * Events: * `OnAlloc(size_t size, uv_buf_t*)` * `OnRead(ssize_t nread, const uv_buf_t*, uv_handle_type pending)` * `OnAfterWrite(WriteWrap*)` * Wrappers: * `DoShutdown(ShutdownWrap*)` * `DoTryWrite(uv_buf_t** bufs, size_t* count)` * `DoWrite(WriteWrap*, uv_buf_t*, size_t count, uv_stream_t* handle)` * `Error()` * `ClearError()` The implementation should provide all of these methods, thus providing the access to the underlying resource (be it uv handle, TLS socket, or anything else). A C++ stream may consume the input of another stream by replacing the event callbacks and proxying the writes. This kind of API is actually used now for the TLSWrap implementation, making it possible to wrap TLS stream into another TLS stream. Thus legacy API calls are no longer required in `_tls_wrap.js`. PR-URL: #840 Reviewed-By: Trevor Norris <trev.norris@gmail.com> Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>

indutny · 2015-02-22T20:16:26Z

Landed in b968623, thank you everyone! @bnoordhuis if you have any comments - feel free to open issue for them, I'll fix everything or we'll figure out how to do it best.

@robertkowalski

Notable changes: * tls: A typo introduced in the TLSWrap changes in #840 only encountered as a bug on Windows was not caught by the io.js CI system due to problems with the Windows build script and the Windows CI slave configuration, see Fixed in #994 & #1004 (Fedor Indutny) * npm: Upgrade npm to 2.6.1. See https://github.com/npm/npm/blob/master/CHANGELOG.md#v260-2015-02-12 for details. * Add new collaborators: - Robert Kowalski (@robertkowalski) - Christian Vaagland Tellnes (@tellnes) - Brian White (@mscdex)

wraithan reviewed Feb 13, 2015
View reviewed changes

Fishrock123 added https Issues or PRs related to the https subsystem. stream Issues and PRs related to the stream subsystem. crypto Issues and PRs related to the crypto subsystem. labels Feb 13, 2015

chrisdickinson reviewed Feb 13, 2015
View reviewed changes

indutny force-pushed the feature/stream-resource branch from abf42e9 to 8eaf985 Compare February 16, 2015 11:44

trevnorris reviewed Feb 16, 2015
View reviewed changes

indutny added 15 commits February 20, 2015 23:12

tls_wrap: fix Receive

7b7bec6

tls_wrap: allow wrapping TLSWrap

0c9e1a2

tls_wrap: fix inception test

cac9cd7

test: fix multi-key test, _handle disappears

eadd63e

stream_base: last fixes, hopefuly

62c7c74

tls_wrap: return of this.ssl

a2f0e57

tls_wrap.js: result=>socket

bcbad15

stream_base: remove GetObject()

f8d5779

stream_base: fix lint errors

659d0cb

tls_wrap: support reading in parts

59cd1f2

stream_base: OnData => EmitData

ce0e7a4

net: remove commented code

259c236

stream_base: move SetBlocking to StreamWrap

9f409e5

node_crypto: fix

2231333

stream_base: remove TODO

07025b7

indutny force-pushed the feature/stream-resource branch from d064fb2 to 07025b7 Compare February 20, 2015 22:26

indutny closed this Feb 22, 2015

indutny deleted the feature/stream-resource branch February 22, 2015 20:16

This was referenced Feb 23, 2015

Release proposal: v1.4.0 #932

Closed

Release proposal: v1.3.0 #872

Closed

rvagg mentioned this pull request Feb 28, 2015

Release proposal: v1.4.2 #995

Closed

rvagg mentioned this pull request Mar 6, 2015

[PRIORITY] Persistent failures on Windows #1005

Closed

armanbilge mentioned this pull request Jul 26, 2022

How to use new tls.TLSSocket(...) to establish a secure connection? #43994

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TLSCallbacks => TLSWrap, better TLS inception #840

TLSCallbacks => TLSWrap, better TLS inception #840

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

wraithan commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

wraithan Feb 13, 2015

indutny Feb 13, 2015

chrisdickinson Feb 13, 2015

indutny Feb 13, 2015

indutny commented Feb 13, 2015

chrisdickinson Feb 13, 2015

indutny Feb 13, 2015

chrisdickinson Feb 13, 2015

rvagg commented Feb 13, 2015

chrisdickinson Feb 13, 2015

indutny Feb 13, 2015

chrisdickinson Feb 13, 2015

indutny commented Feb 13, 2015

chrisdickinson commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 15, 2015

trevnorris Feb 16, 2015

indutny Feb 16, 2015

kkoopa Feb 17, 2015

indutny Feb 17, 2015

indutny commented Feb 21, 2015

indutny commented Feb 22, 2015

indutny commented Feb 22, 2015

		@@ -437,49 +478,56 @@ TLSSocket.prototype._finishInit = function() {
		};

		TLSSocket.prototype._start = function() {

TLSCallbacks => TLSWrap, better TLS inception #840

TLSCallbacks => TLSWrap, better TLS inception #840

Conversation

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

wraithan commented Feb 13, 2015

indutny commented Feb 13, 2015

indutny commented Feb 13, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

indutny commented Feb 13, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rvagg commented Feb 13, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

indutny commented Feb 13, 2015

chrisdickinson commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 14, 2015

indutny commented Feb 15, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

indutny commented Feb 21, 2015

indutny commented Feb 22, 2015

indutny commented Feb 22, 2015