set tls.sessionIdContext property

[msimerson]

Fixes #1739

Changes proposed in this pull request:

• create a top level scoped secureContext (maybe store it in Redis eventually)
• consolidate 2x secureContext creations into _getSecureContext()
• set the context's sessionIdContext (this is the FIX)
• remove options.secureProtocol default 'SSLv23_method' (that's the node.js default since iojs)
• remove secureOptions | constants.SSL_OP_NO_SSLv2 | constants.SSL_OP_NO_SSLv3
  • SSL v2 and v3 were removed from node.js in since io.js
• remove crypto.createCredentials (deprecated)

Checklist:

• docs updated
• tests updated

[codecov-io]

Current coverage is 34.47% (diff: 12.50%)

Merging #1740 into master will increase coverage by 0.01%

@@             master      #1740   diff @@
==========================================
  Files            23         23          
  Lines          5919       5917     -2   
  Methods         761        762     +1   
  Messages          0          0          
  Branches       1503       1500     -3   
==========================================
  Hits           2040       2040          
+ Misses         3879       3877     -2   
  Partials          0          0          

Powered by Codecov. Last update febe3a7...e407e2f

[smfreegard]

Am I right in thinking that this will not fix #1739 if running with nodes=cpus because if the reconnection happens to a different child (which is likely), then the secureContext will be different?

[msimerson]

Am I right in thinking that this will not fix #1739 if running with nodes=cpus because if the reconnection happens to a different child (which is likely), then the secureContext will be different?

Close, but not quite. Ya see, the root of the problem is session id context uninitialized, which this PR fixes by setting the id property. Seriously. You have to provide an ID it to initialize it. The OpenSSL docs and the error message both say so. Update: it appears node does initialize the ID with a SHA1 hash.

You are very right to be thinking that the secureContext would best be shared among processes, but if not, or if a client presents a ticket that's not found in the secureContext, that's no big deal as the server will check the context and if missing, create a new ticket. It works almost exactly the same way if you set the sessionTimeout to something really low like 1 second. The TLS ticket ends up being expired after every connection.

[msimerson]

One of the best explanations is on the OpenSSL users list:

• session-id-context-uninitialized
• SSL_set_session_id_context man page

[msimerson]

Late at night, after all them Thunderbird users are gone to sleep, I snuck in and changed to nodes=4 (having 16 children is just kinda silly) and tested again, just to make sure. I sent a half dozen messages through unhindered. Previously (w/o patch) I could send the first and subsequent attempts (until restarting Thunderbird) would fail.