3 ms·

> I'd far rather have the OS provide a verified safe socket layer There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which

> I'd far rather have the OS provide a verified safe socket layer There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in. [1] https://github.com/lxin/quic https://github.com/lxin/quic

eptcyka 2y ago
Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.
- XorNot 2y ago
  The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?" The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.
  - richardwhiuk 2y ago
    It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.
  - kelnos 2y ago
    Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself. Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/ https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways". Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.
- cyanmagenta 2y ago
  > but does the kernel then also do certificate validation for you No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.
- SahAssar 2y ago
  The kernel already does TLS, but the handshake happens in user-space.
LtWorf 2y ago
It will not.

eptcyka 2y ago

Yea, but does the kernel then also do certificate validation for you? Will you pin certs via setsockopt? I think QUIC and TLS are wide enough attack surfaces to warrant isolation from the kernel.

XorNot 2y ago
The problem is that the situation where everyone rolls their own certificate stack is lunacy in this day and age. We need crypto everywhere, and it should be a lot easier to configure how you want: the kernel is a great place to surface the common interface for say "what certificates am I trusting today?" The 10+ different ways you specify a custom CA is a problem I can't wait to see the back of.
- richardwhiuk 2y ago
  It's a good thing for a OS to provide, that doesn't mean it needs to be in the kernel.
- kelnos 2y ago
  Putting cert parsing in (monolithic) kernels seems like a bad idea; cert parsing has a long history of security vulnerabilities, and you don't want that kind of mistake to crash your kernel, let alone lead to privilege escalation or a takeover of the kernel itself. Regardless, your proposal suffers from the usual stuff about proliferating standards (https://xkcd.com/927/ https://xkcd.com/927/): a kernel interface will never get fully adopted by everyone, and then your "10+ ways" will become "11+ ways". Meanwhile, all the major OSes have their own trust store, and yet some apps choose to do things in a different way. Putting this into the kernel isn't going to change that.
cyanmagenta 2y ago
> but does the kernel then also do certificate validation for you No, the asymmetric cryptography is all done in userspace. Then, post-handshake, symmetric cryptography (e.g., AES) is done in-kernel. This is the same way it works with TCP if you’re using kTLS.
SahAssar 2y ago
The kernel already does TLS, but the handshake happens in user-space.

LtWorf 2y ago

It will not.