Hacker News Reader

Comment by parley | Hacker News Reader

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.

View on HN

> 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/

The new API is useful if you want to do TLS over sockets. It's completely unhelpful for everyone else.

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.

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.

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.

Yes, it's possible to "communicate with self" in various ways to intercept, but it's really ugly. Also, performance may suffer.

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.

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

Reply on news.ycombinator.com