Tools like this to me reinforce the broken state of TLS in the modern OS stack.
This looks great, but it's insane we need to do this: TLS really needs to be a kernel level, global feature. Take it out of the hands of applications, and let's add a pluggable system which extends the socket interface directly since that's theoretically what "transport layer security" is.
It's already hard enough to use web from Windows 2000 and other old operating systems. Making TLS kernel level feature will likely halt any TLS progress.
Google is moving TCP to user level (QUIC) for a reason.
Making TLS a kernel subsystem which dispatches to a common userspace provider though would not. The issue is that every application has to link and use TLS libraries on their own - they don't just ask the kernel for "a secure socket".
So we wind up in this space where a transport level protocol is for some reason being handled by the application stack, in a million different places and only somewhat common by convention (which we've gone and broken with containerizing userspace).
In production it can be better to bind-mount the host's CA store, instead of relying on each container to have a correct and current CA database. This is especially needed if an enterprise CA is in use.
In general I think the unidirectional "layered" container image model is a stepping stone. It ought to be easy to replace the "runtime" layer for a container without rebuilding the higher layer holding the application code. I can replace the host's kernel without modifying the code; why can't I upgrade the container's glibc or Python?
10 comments
[ 4.3 ms ] story [ 39.4 ms ] threadThis looks great, but it's insane we need to do this: TLS really needs to be a kernel level, global feature. Take it out of the hands of applications, and let's add a pluggable system which extends the socket interface directly since that's theoretically what "transport layer security" is.
Google is moving TCP to user level (QUIC) for a reason.
So we wind up in this space where a transport level protocol is for some reason being handled by the application stack, in a million different places and only somewhat common by convention (which we've gone and broken with containerizing userspace).
In general I think the unidirectional "layered" container image model is a stepping stone. It ought to be easy to replace the "runtime" layer for a container without rebuilding the higher layer holding the application code. I can replace the host's kernel without modifying the code; why can't I upgrade the container's glibc or Python?