Hacker News Reader

Comment by JoshTriplett | Hacker News Reader

There's actually a notable security advantage to this. A userspace process can do key negotiation, hand the symmetric keys to the kernel, and then have an ordinary file descriptor, with the kernel handling encryption. Which means you could then pass that file descriptor to a separate process, let it read and write data, and not give it access to key material at all.

View on HN

Can't you already do all of that with a userspace implementation?

That's pretty much what stunnel does.

Somewhat, if you pass a pipe around, but that also requires you to keep a separate process around, and shuttle data through two address spaces. With this, you can have a process do the negotiation, arrange a KTLS file descriptor, and then exec the new process.

Couldn't you open a TCP connection, do the handshake, then pass just the session key to the new process, along with the handler to the TCP connection?

You could, but you lose out on a nice interface. Kernel implementation allows you to not care that you're actually using SSL. It's a normal socket and polling / waiting / data transmission works exactly the same as without SSL. Handing over a session key means you still have to include an SSL lib.

This is likely to end up being supported in systemd soon (I'm guessing) to get an SSL socket activation.

Not really - if a control frame is received the KTLS file descriptor will report an error and disassociate itself from the TCP file descriptor, at which point you're supposed to transition back to using the userspace TLS library. You'll also need the userspace TLS library to do a clean shutdown.

In what scenario is it an advantage to be able to encrypt/decrypt data with a certain key, but not know the key directly?

Any scenario where the key is not ephemeral and you're handling client's input (can expect exploitation). If you have a good enough separation/sandboxing, any exploit wouldn't be able to steal the encryption key, or other private data, even if the exploit worked.

For handling encrypted secrets, this is popular as a HSM idea. You authenticate to a black box which does the crypto for you, but the key can't be extracted. Sometimes HSMs even have a physical tampering / self destruction protection.

So a scenario where the key is long-lived, but the process communicating is transient? I suppose that makes sense, although I struggle to imagine the use case.

SSL, certificate signing, configuration decryption, anything Amazon SSE is used for, ...

Reply on news.ycombinator.com