3 ms·

Async TLS

5 points by pquerna 16y ago

tptacek 16y ago
Yes, reimplementing the protocol logic for TLS and "just using OpenSSL for the crypto" is insane. Most of the last 5 year's worth of SSL flaws, with (I think) the sole exception of the RSA signature verification hole, were protocol logic screwups. See the recent session resumption debacle for an illustration of a flaw that has virtually nothing to do with crypto. 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.
- pquerna 16y ago
  Yes. 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.
  - tptacek 16y ago
    I don't understand Node's architecture enough to know what the problem with OpenSSL is for you, but OpenSSL works just fine async, as you've noted. I use it in my async ObjC web testing tool, EventMachine has it down to a single "start_tls" call, and presumably Twisted got it working too. I want to be careful not to say you're wrong about OpenSSL for Node.js. But OpenSSL itself pretty much works fine async.
    - pquerna 16y ago
      The problem is not with Async IO. 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.internet.ssl.CertificateOptions.html 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.
      - tptacek 16y ago
        I see. All I can tell you is, it sounds like you have a legitimate need, but the solution to that need is insanely risky, and probably not worth it to most Node apps.
- rlpb 16y ago
  I think you're absolutely right to be concerned about the reimplementation of any sort of crypto, for exactly the right reasons. 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.
sedachv 16y ago
This amuses me. After re-implementing all possible IO libraries on earth with epoll() and callbacks, I predict the NIO nerds will come to the inevitable conclusion that they need to put CPS-rewriters on top to actually do anything useful (you know, things other than re-implementing all possible IO libraries and blogging about how awesome node.js is), thus completing the great circle of life/green threads.

5 points by pquerna 16y ago

Yes, reimplementing the protocol logic for TLS and "just using OpenSSL for the crypto" is insane. Most of the last 5 year's worth of SSL flaws, with (I think) the sole exception of the RSA signature verification hole, were protocol logic screwups. See the recent session resumption debacle for an illustration of a flaw that has virtually nothing to do with crypto. 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.

pquerna 16y ago
Yes. 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.
- tptacek 16y ago
  I don't understand Node's architecture enough to know what the problem with OpenSSL is for you, but OpenSSL works just fine async, as you've noted. I use it in my async ObjC web testing tool, EventMachine has it down to a single "start_tls" call, and presumably Twisted got it working too. I want to be careful not to say you're wrong about OpenSSL for Node.js. But OpenSSL itself pretty much works fine async.
  - pquerna 16y ago
    The problem is not with Async IO. 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.internet.ssl.CertificateOptions.html 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.
    - tptacek 16y ago
      I see. All I can tell you is, it sounds like you have a legitimate need, but the solution to that need is insanely risky, and probably not worth it to most Node apps.
rlpb 16y ago
I think you're absolutely right to be concerned about the reimplementation of any sort of crypto, for exactly the right reasons. 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.

sedachv 16y ago

This amuses me. After re-implementing all possible IO libraries on earth with epoll() and callbacks, I predict the NIO nerds will come to the inevitable conclusion that they need to put CPS-rewriters on top to actually do anything useful (you know, things other than re-implementing all possible IO libraries and blogging about how awesome node.js is), thus completing the great circle of life/green threads.