5 ms·

The big reason security is in userspace is because it requires policy decisions. How do we determine which remote users to trust? WoT, cert chains, trust on fir

• comex 10y ago
  Actually, policy decisions are a big part of why I think TLS should be "in the kernel". It doesn't have to literally be in the kernel - it could be a userspace daemon instead - but that's an implementation detail. What matters is that just like with TCP, there should be one high-level API, provided by the system, which all applications are expected to use. Scenario: You want to temporarily ignore an invalid certificate. (Yes, I know this is usually a bad idea, but sometimes it’s necessary.) Today: Every application needs its own flag, environment variable, configuration option, and/or UI element to disable validation. If you’re unlucky, there won’t be one. If you’re really unlucky, there won’t be any way to enable validation; even in 2017 there are still lots of poorly written applications like that. Centralized: There should be a standard environment variable that works with everything, and/or maybe a “security center” applet where you can add a temporary system-wide exemption per-host, or something like that. Scenario: You want to sniff a secure connection for debugging purposes. Today: You have to use a MITM proxy, which is gross and needs setup and breaks things, and requires trusting invalid certificates, which doesn’t always work; see above and below. Centralized: The kernel could just hand decrypted packets to packet sniffing programs, allowing for purely passive observation. Scenario: You want to ensure that you’re using high-quality ciphersuites. Today: Up to the application, usually not customizable, so browsers will do the right thing and other applications will have some list the developer copy+pasted that seemed to work. Welp. Centralized: The system should be able to specify policy for all applications, with the option for the user to override it. After all, it’s almost never actually desirable for a cipher suite to be supported by one application and not another - like, it’s okay if my mail client connects to Google insecurely, but not if my instant messaging client does. Scenario: You want to add a custom trusted CA, or generally you want different applications to be consistent in their policy decisions. Today: Different TLS libraries have their own trust store formats and trust rules. If you’re lucky, your TLS library of choice will have some way to use the system trust store, on Windows and macOS where such a thing exists, although who knows if it’ll properly replicate the various rules browsers like to impose, e.g. requiring certificate transparency. If you’re unlucky, you end up with things like Java having its own trust store, or wget on macOS refusing to download any https URLs until you go install some .crt file and point wget to the right path. In both cases, you end up with a separate list of trusted certificates, that requires a separate process if you want to add a custom one, or upgrade to remove newly distrusted roots, etc. Centralized: Well, there’s already some centralization with system trust stores, but ideally not would those be supported universally, the entire process of “should this TLS connection be established” could be defined and maintained in one place. Scenario: On a server, you want to run a program that accepts TLS connections. Today: Each program needs its own copy of the private key and its own TLS configuration, which often doesn’t expose the full range of settings it’s desirable to customize. Centralized: The system holds the keys (reducing both configuration burden and the danger of leaks); applications can just say “listen on port X using TLS”, and send/receive plaintext on the resulting sockets, and encryption will be handled automatically. ... I admit there are also some downsides of a centralized design. One of them is updates: these days, on most systems, users update their browsers a lot more than they update the OS, so the browser is likely to be up to date while the OS is not. But "at least the browser is secure, even if other apps are not" is not exactly an ideal outcome, and this too seems like an artifact of history... there's no reason that OS components can't auto-update like browsers do.
  • pvg 10y ago
    "at least the browser is secure, even if other apps are not" is not exactly an ideal outcome, That sounds like an ideal (if strictly unattainable) outcome. Your design seems like a sort of software-defined violation of the end-to-end principle. If it existed, most apps that have strong feelings about security simply wouldn't use it.
    • comex 10y ago
      It is ideal from the browser's perspective, but not for the user who is also using other applications in addition to the browser :) It only takes one confused app autoupdater (typically secured at least in part with TLS) to get pwned. If browsers want to be resilient to the possibility that the system stack is not secure, I don't mind terribly. After all, browser vendors have dedicated TLS security teams and certificate trust programs, so they can do their own thing and ensure it's secure. Custom TLS stacks get in the way of some of the goals I mentioned, such as user-customized trust settings and packet sniffing, but that's not the end of the world. What I do mind is if the system stack is actually not secure. If nothing else, that means that applications bundled with the system are likely to be at risk. Non-browser third party applications have to outsource their security policy to someone. They can choose to trust the OS, or to get a TLS stack from somewhere and ship that. In today's world, both approaches have ups and downs from a security perspective. The basic problem is that for maximum security, TLS stacks and their configurations should be updated regularly, mainly to update the trusted certificate list, but also to address vulnerabilities in protocols, ciphersuites, implementation, etc. But many users rarely update their OS. On the other hand, even if you ensure that users update your app (via an autoupdater), you're still responsible for ensuring you ship updates promptly. Even if you cease development because you lost interest or your startup got bought for a trillion dollars or went bankrupt or whatever. And this applies to every single program that wants to establish a secure connection, which these days is basically everything that connects to the Internet. Of course, on Linux distros, application updates tend to come with system updates, so you probably can't do any better than trusting the system, at least when it comes to updates... Today, I think many applications which would be happy to trust the system ship their own TLS stacks anyway, just because it's easier - because of fragmentation and the lack of good wrapper APIs in many environments. For example, the Rust ecosystem has thus far mostly depended on OpenSSL bindings for TLS, but there's a desire to move to the new "rust-native-tls" crate, which wraps SChannel on Windows, SecureTransport on Darwin, and OpenSSL elsewhere. Works for Rust; but if there's a C equivalent, I haven't heard of it...