Skip to content

TLSCallbacks => TLSWrap, better TLS inception

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.

Merge request reports

Loading