3 ms·

I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a

by simias 6y ago

I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.

skissane 6y ago
> I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
- tialaramex 6y ago
  People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
  - skissane 6y ago
    That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
    - tialaramex 6y ago
      Fair, although I think 99.9% of the value is in the trick Linux is doing here. The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) and the part you're most likely to want to customise (e.g. OCSP stapling is in the handshake, certificate compression is in the handshake, SNI handling is in the handshake, and so on) which means that's the part an application author is least likely to be satisfied with being done on their behalf. Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
      - skissane 6y ago
        > Fair, although I think 99.9% of the value is in the trick Linux is doing here For z/OS AT-TLS, the primary use case is that I can take a legacy app which knows nothing about TLS, and make it support TLS with zero code changes. You create policy rules in the OS configuration, they resemble firewall rules (they can match on source and destination address, port and process name), and if an application's socket call matches the rule, the plain socket gets transparently swapped with a TLS one. Linux kernel TLS is trying to address a completely different use case: I have an app which knows all about TLS and already has the code (most likely via some shared library such as OpenSSL) to do it all by itself, but I'm going to modify it to move some of the processing to kernel space for improved performance. What @simias was asking for, "I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest" isn't exactly either use case, but it is closer to z/OS AT-TLS use case than Linux kTLS use case. Indeed, AT-TLS supports a mode of operation in which, rather than configuring TLS to be automatically applied by rules, it is manually requested by the app calling an ioctl on the socket - but, all the TLS configuration like which certificates to trust is pulled from the OS configuration - that seems like almost exactly what @simias was requesting. > The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) I don't have a lot of insight into how AT-TLS is implemented internally, but I know some parts of it run in user space (inside a daemon called "pagent"). Having TLS implemented in the operating system doesn't necessarily mean it has to be implemented in the kernel. Some operating systems (e.g. Windows NT) say that the system call interface is private and the public interface is a library call. If an OS goes with that model, then the OS-supplied TLS implementation could be in a shared library not inside the kernel. Of course, that isn't the model Linux went with, it made system calls a public interface and so even if you put an AT-TLS-style transparent TLS implementation in the C library, some apps would bypass it by using system calls directly. That isn't necessarily problematic. Actually, z/OS AT-TLS gets bypassed by some apps too. z/OS, being an operating system with decades of legacy, actually has multiple sockets APIs, and AT-TLS doesn't hook them all (whether due to technical limitations or simply IBM didn't decide it was worthwhile spending resources on.) In particular, the so-called "Pascal sockets API" (I believe it is called that because originally it was written in Pascal, and designed for use by Pascal code, but programs written in other languages such as C or COBOL or assembler can call it) doesn't go through AT-TLS. Likewise, apps that use the UNIX SystemV STREAMS API don't work with AT-TLS either. However, only a minority of z/OS apps use either of those legacy sockets APIs, and using those APIs is discouraged for new code. So, somewhat like z/OS does, if someone wanted to add this feature to Linux, they could always put it in the C library, and if an app bypassed that, well "sorry you don't get the transparent TLS feature". Another option would be to do something like FUSE – have a daemon in user-space which does the TLS handshake. Inside the connect() or accept() system calls, the kernel could send the socket to that daemon, get it to do the TLS handshake, and then return the syscall when the daemon says it is done. All doable, the only real questions are (1) is anyone sufficiently motivated to add this feature to Linux (quite possibly not); (2) if they implement it, will the Linux kernel devs accept it (don't know about that either)

by simias 6y ago

skissane 6y ago

> I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...

tialaramex 6y ago
People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
- skissane 6y ago
  That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
  - tialaramex 6y ago
    Fair, although I think 99.9% of the value is in the trick Linux is doing here. The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) and the part you're most likely to want to customise (e.g. OCSP stapling is in the handshake, certificate compression is in the handshake, SNI handling is in the handshake, and so on) which means that's the part an application author is least likely to be satisfied with being done on their behalf. Notice that in Linux because sockets "are" file descriptors you actually can put all connection and handshake work into a separate processes altogether, and just pass the socket (now TLS encrypted) to a process that pumps data back and forth, without it needing to be aware of TLS at all.
    - skissane 6y ago
      > Fair, although I think 99.9% of the value is in the trick Linux is doing here For z/OS AT-TLS, the primary use case is that I can take a legacy app which knows nothing about TLS, and make it support TLS with zero code changes. You create policy rules in the OS configuration, they resemble firewall rules (they can match on source and destination address, port and process name), and if an application's socket call matches the rule, the plain socket gets transparently swapped with a TLS one. Linux kernel TLS is trying to address a completely different use case: I have an app which knows all about TLS and already has the code (most likely via some shared library such as OpenSSL) to do it all by itself, but I'm going to modify it to move some of the processing to kernel space for improved performance. What @simias was asking for, "I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest" isn't exactly either use case, but it is closer to z/OS AT-TLS use case than Linux kTLS use case. Indeed, AT-TLS supports a mode of operation in which, rather than configuring TLS to be automatically applied by rules, it is manually requested by the app calling an ioctl on the socket - but, all the TLS configuration like which certificates to trust is pulled from the OS configuration - that seems like almost exactly what @simias was requesting. > The handshake is at once the most complicated part (which means you don't really want it in Ring Zero) I don't have a lot of insight into how AT-TLS is implemented internally, but I know some parts of it run in user space (inside a daemon called "pagent"). Having TLS implemented in the operating system doesn't necessarily mean it has to be implemented in the kernel. Some operating systems (e.g. Windows NT) say that the system call interface is private and the public interface is a library call. If an OS goes with that model, then the OS-supplied TLS implementation could be in a shared library not inside the kernel. Of course, that isn't the model Linux went with, it made system calls a public interface and so even if you put an AT-TLS-style transparent TLS implementation in the C library, some apps would bypass it by using system calls directly. That isn't necessarily problematic. Actually, z/OS AT-TLS gets bypassed by some apps too. z/OS, being an operating system with decades of legacy, actually has multiple sockets APIs, and AT-TLS doesn't hook them all (whether due to technical limitations or simply IBM didn't decide it was worthwhile spending resources on.) In particular, the so-called "Pascal sockets API" (I believe it is called that because originally it was written in Pascal, and designed for use by Pascal code, but programs written in other languages such as C or COBOL or assembler can call it) doesn't go through AT-TLS. Likewise, apps that use the UNIX SystemV STREAMS API don't work with AT-TLS either. However, only a minority of z/OS apps use either of those legacy sockets APIs, and using those APIs is discouraged for new code. So, somewhat like z/OS does, if someone wanted to add this feature to Linux, they could always put it in the C library, and if an app bypassed that, well "sorry you don't get the transparent TLS feature". Another option would be to do something like FUSE – have a daemon in user-space which does the TLS handshake. Inside the connect() or accept() system calls, the kernel could send the socket to that daemon, get it to do the TLS handshake, and then return the syscall when the daemon says it is done. All doable, the only real questions are (1) is anyone sufficiently motivated to add this feature to Linux (quite possibly not); (2) if they implement it, will the Linux kernel devs accept it (don't know about that either)