3 ms·

the real advantage is that you can pass arround your encrypted connection as a file descriptor. so when you add encryption to some service, you do not have to m

by dfhgb 9y ago

the real advantage is that you can pass arround your encrypted connection as a file descriptor. so when you add encryption to some service, you do not have to manually replace all calls to read/write by libssl library functions but instead you can just continue to use read()/write() calls. pass tls connection as stdin/stdout to another process ect... this is how plan9 does tls and how it really should have been in the first place. adding tls support is one function call to wrap an existing file descriptor in tls and you get another file descriptor back.

deleted 9y ago
[deleted]
colanderman 9y ago
But you can accomplish that by simply having an external process or thread terminate the TLS connection, and connect to your process over Unix domain sockets. Of course that is inefficient. But that is what KTLS is at its core: an optimization.
- dfhgb 9y ago
  of course you can make a pipe and spawn a process that does the translation. why's nobody doing that? because linux is a cargo cult and nobody does the sane thing until it is provided by the infrastructure. because of fork not mixing well with multithreaded applications... now finally linux got its shit together so there is no more excuse why todo it in a covoluted way.