Async TLS
journal.paul.querna.org
journal.paul.querna.org
Put differently: game-over flaws are routinely found in reimplementations of SSL/TLS, none of which built their own crypto primitives.
It's kind of unclear from this post what's being considered. Implementing the SSL record protocol is trivial, not dangerous, but also (so far as I can see) not at all useful to the problem at hand. I don't think you're considering a "parser"; you're thinking of implementing the protocol.
You'll fail at that.
And Yes.
But someone should write an async SSL stack.. at some point, right?
As an outsider to OpenSSL, it doesn't seem viable to do that kind of refactoring, so it seems the only viable place for it to live is a new, risky, terrible for security idea project.
I want to be careful not to say you're wrong about OpenSSL for Node.js. But OpenSSL itself pretty much works fine async.
It has all to do with the various Callbacks. If you want to do async things inside those callbacks, you can't with how OpenSSL is structured today. Twisted, for exmaple lets you set various options: http://twistedmatrix.com/documents/10.1.0/api/twisted.intern...
This makes it so the actual callbacks are just checking variables to make their decisions, but you can't implement a session cache backend for example in twisted, you are pretty much stuck with the built-in openssl one, for a single process.
However, have you ever looked at the OpenSSL code? It's insane. I presume it's ended up that way because people have the same fear of introducing a vulnerability.
At some point, someone needs to fix it.