3 ms·

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 t

by 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.

by spand 12y ago

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.