4 ms·

I’ve been pondering writing a kernel module that basically exposes the Golang TLS API (with hooks for things like CertPool and VerifyConnection) - so that rathe

I’ve been pondering writing a kernel module that basically exposes the Golang TLS API (with hooks for things like CertPool and VerifyConnection) - so that rather than opening TCP sockets, you can open a TLS socket directly. There’s a lot of complication involved here, but having the TLS state inaccessible from userspace has a lot of desirable attributes. Further on this line of thinking, it’s an entirely reasonable extension of the “secure bastion” on modern processors to allow for a temporary private key store - You load your private key into the bastion and get back a key handle, which can then be used to do TLS handshakes but only through the bastion. Once that’s done, recovery of the private key is impossible, only abuse of it by the kernel (by passing that handle to other processes)

simcop2387 6y ago
It would be better to build up a library for using the existing ktls support from golang instead. Shouldn't be too hard and then it'll be better supported by being in the mainline kernel. https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...
- GauntletWizard 6y ago
  I’m familiar with that infrastructure; However, that only takes over once a session-key has been negotiated, that is, after TLS handshake is completed and certs have been verified. That’s great - Everything should use that. What I’m proposing goes one further. When opening a socket, you should be able to specify your private key and certificate, pass it to the kernel, and be unable to further access that key from there. That way, your private key would be able to be entirely removed from userspace memory; Unrecoverable even if tried. Kernel TLS offloading as it exists is a performance enhancement that can potentially move the encryption computation into your NIC. What I’m proposing is a security barrier that reduces the amount of time that the private key is resident in (process mapped) memory.
  - simcop2387 6y ago
    Interesting, I didn't realize it only took over from that part of the communication. That would certainly be a nice to have thing then, maybe use the current kernel key management stuff so that it could even be done in a way that the process never actually gets to load the key itself but it's instead loaded by something else and given the id needed to tell the kernel that the socket should use it. I do wonder how this would play with SNI and such which might make it a non-starter for a lot of cases.

simcop2387 6y ago

It would be better to build up a library for using the existing ktls support from golang instead. Shouldn't be too hard and then it'll be better supported by being in the mainline kernel. https://www.kernel.org/doc/html/latest/networking/tls-offload.html https://www.kernel.org/doc/html/latest/networking/tls-offloa...

GauntletWizard 6y ago
I’m familiar with that infrastructure; However, that only takes over once a session-key has been negotiated, that is, after TLS handshake is completed and certs have been verified. That’s great - Everything should use that. What I’m proposing goes one further. When opening a socket, you should be able to specify your private key and certificate, pass it to the kernel, and be unable to further access that key from there. That way, your private key would be able to be entirely removed from userspace memory; Unrecoverable even if tried. Kernel TLS offloading as it exists is a performance enhancement that can potentially move the encryption computation into your NIC. What I’m proposing is a security barrier that reduces the amount of time that the private key is resident in (process mapped) memory.
- simcop2387 6y ago
  Interesting, I didn't realize it only took over from that part of the communication. That would certainly be a nice to have thing then, maybe use the current kernel key management stuff so that it could even be done in a way that the process never actually gets to load the key itself but it's instead loaded by something else and given the id needed to tell the kernel that the socket should use it. I do wonder how this would play with SNI and such which might make it a non-starter for a lot of cases.