On Fri, Nov 23, 2012 at 2:50 PM, Steve Freegard <s...@fsl.com> wrote: > Hi Ben, > > > On Friday, November 23, 2012 10:06:29 AM UTC, Ben Noordhuis wrote: >> >> >> I don't see why a change to the crypto/tls API is necessary. Haraka >> just needs to be a little more flexible here. >> >> By the way, the value of SSL_OP_ALL is 0x80000bff, not 0x80000000 >> (2147486719 vs 2147483648). That value in the commit log was just for >> demonstration purposes, it's the smallest value that shows the >> wraparound behavior. > > > Ok - looking at lib/tls.js with fresh eyes this morning; I can see I > misunderstood > how they are set. > > I've recompiled my node with your patch to node.h now; I can confirm that > SSL_OP_ALL still does not rectify this error. > > I posted to the OpenSSL mailing list last night and got the following reply > from > one of the devs: > > --SNIP-- > The function EVP_DecryptFinal_ex isn't often used in the TLS code and you > normally wouldn't come across this error so it may not be TLS related. You > might see it related to session tickets but that shouldn't be a fatal error: > try SSL_OP_NO_TICKET anyway though. > > I'd suggest you print out the whole error queue instead of just the top so > it > is clearer where the actual error is occurring. Alternatively a stack trace > under a debugger would be useful. > --SNIP-- > > I've tried SSL_OP_NO_TICKET and it does not rectify the problem; I also > can't > combine this with SSL_OP_ALL without getting another parameter error as > OR'ing both together yields: -2147463169 > > I added some more debug and I've got a full node stacktrace where the error > occurs: > > Error: 16565968:error:06065064:digital envelope > routines:EVP_DecryptFinal_ex:bad > decrypt:../deps/openssl/openssl/crypto/evp/evp_enc.c:467: > 16565968:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad > decrypt:../deps/openssl/openssl/crypto/evp/evp_enc.c:467: > > at CleartextStream._pusher (tls.js:656:24) > at SlabBuffer.use (tls.js:199:18) > at CleartextStream.CryptoStream._push (tls.js:483:33) > at SecurePair.cycle (tls.js:880:20) > at CleartextStream.CryptoStream.write (tls.js:267:13) > at pluggableStream.write > (/usr/lib/node_modules/Haraka/tls_socket.js:119:34) > at Connection.respond > (/usr/lib/node_modules/Haraka/connection.js:386:21) > at Connection.queue_ok_respond > (/usr/lib/node_modules/Haraka/connection.js:1386:10) > at plugins.run_next_hook.callback > (/usr/lib/node_modules/Haraka/plugins.js:280:39) > at Plugin.exports.hook_queue_ok (queue/discard:24:12) > > Is there any way I can grab the full error queue from OpenSSL as requested > by the OpenSSL developer?
Ah, you're running into a quirk of the language. `(SSL_OP_ALL | SSL_OP_NO_TICKET) >>> 0` would have given you the expected result, 0x80004000 instead of -0x7fffc000. That's not very intuitive though so I've landed a fix in [1]. Regarding the error queue, you've been looking at it. CleartextStream._pusher() calls into OpenSSL; if the operation fails, it calls ERR_print_errors(bio) and turns the BIO into an exception. Maybe Haraka truncates the exception message? [1] https://github.com/joyent/node/commit/335f208 -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
