3 ms·

Please correct me if I'm wrong, but I believe that the OpenSSL API allows one to implement the actual transport of the TLS protected data however one chooses, a

• spand 12y ago
  From the link: * tls_connect() connects a client context to the server named by host. The port may be numeric or a service name. If it is NULL then a host of the format "hostname:port" is permitted. * tls_connect_fds() connects a client context to a pair of existing file descriptors. * tls_connect_socket() connects a client context to an already established socket connection.
  • parley 12y ago
    I did read the linked page, but perhaps I'm misunderstanding something. To me, this looks like it still requires sockets or fds. I want to be able to grab the TLS-protected byte stream conveniently and transport it to the other endpoint however I see fit. This would make it possible to use this TLS implementation easier on top of I/O-frameworks that don't necessarily map immediately down to sockets/fds. Again, for improved composability and code reuse.
    • spand 12y ago
      I believe so too. It seems like a reasonable security tradeoff to limit the kinds of bugs that will be the result of such flexibility.
      • parley 12y ago
        > I believe so too. That sounds strange, as I believe we're in disagreement. I believe the flexibility should exist, and choosing the transport medium of already encrypted data should be an option for the developer. This is completely unrelated to the security critical configuration of the TLS protocol, i.e. certs, keys, ciphersuites, etc.
    • tankenmate 12y ago
      It is very much a kluge but you can use pipe(2); it will give you two fds both of which you control. Then you can read/write from the "local" end and serialise the traffic however you wish.
      • parley 12y ago
        Yes, it's possible to "communicate with self" in various ways to intercept, but it's really ugly. Also, performance may suffer.
    • adekok 12y ago
      > To me, this looks like it still requires sockets or fds. Yes. Which makes it useless for protocols that carry TLS. e.g. EAP. So I can't use it in my pet project: http://freeradius.org/ http://freeradius.org/ The new API is useful if you want to do TLS over sockets. It's completely unhelpful for everyone else.
    • acveilleux 12y ago
      Since they did not deprecate much (any?) previous APIs yet, you still have that possibility. They just added a new API that answers the most common use cases in a simple, straightforward, and internally consistent way.
      • parley 12y ago
        And I really like the new API. Kudos to the creators. I would really like to use this new API in a simple, straightforward and internally consistent way - and grab the byte stream after encryption to feed it into my existing I/O framework. Please forgive the sarcasm, but all my comments are derived from a will to see this new API succeed, which is why I don't want this use case to be overlooked while designing it. If I was happy staying with the original OpenSSL API I probably wouldn't have voiced my concern as fervently.
• adekok 12y ago
  > I believe that the OpenSSL API allows one to implement the actual transport of the TLS protected data however one choose. Yes. Through the terrible BIO_* API. It's imperfect, but it lets you treat TLS as a "black box" that you shove encrypted/cleartext data into, and get cleartext/encrypted data out. This API is good for socket communication. Nothing more. This API could be extended by adding "underlying" read and write functions. Off of the top of my head: typedef int (tls_underlying_io)(struct tls ctx, void u_ctx, const void in, size_t inlen, void out, size_t outlen); int tls_set_io(struct tls ctx, void u_ctx, tls_underlying_io u_read, tls_underlying_io u_write) Where "u_read" is used by libtls() instead of calling read(fd,...), and u_write() is called by libtls instead of write(fd, ..)
  • robert-wallis 12y ago
    The hostname also needs to be verified somewhere in there.