5 ms·

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 b

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