Secure Socket API: POSIX socket API as a vehicle for a simplified TLS API | Hacker News Reader

Secure Socket API: POSIX socket API as a vehicle for a simplified TLS API

owntrust.org

42 pointsfanf212 comments

OpenBSD libtls is a really simplified TLS API with sane defaults and convenient handling of extensions like SNI and ALPN. Nice and somewhat long overview can be found in https://github.com/bob-beck/libtls/blob/master/TUTORIAL.md . There is also a nice presentation https://www.openbsd.org/papers/linuxconfau2017-libtls/

It's in C but this also means there it is easy to make bindings in other languages like Rust: https://docs.rs/libtls/0.0.1/libtls/

It seems there are some implications.

1. This is a Linux-only kernel module, so I'm guessing writing applications using this would limit you to Linux.

2. You now put more trust in the kernel. It's not like you don't already trust the kernel, but this certainly makes life easier on a kernel to spy on encrypted traffic.

3. It's ported to Go. Which is handy, but Go already has what seems to be an extremely solid TLS implementation of it's own (and at worst, it's not OpenSSL, at least.) That certainly makes the "easy to use" angle less interesting...

So far I really only think this would be particularly interesting if it outperformed existing TLS implementations significantly.

I would much rather have the kernel handle all encryption than userland.

Userland is much more susceptible to attacks.

The concern is that TLS is a complex protocol and if there is a bug in the code then the attacker gets access to the kernel instead of only a user process.

There is also the problem of conservative distributions using very old kernels. If you want your application to work on those distributions then you will need to have two versions of your program, one using a TLS library for those distributions and another using the kernel implementation. And this will persist even when current kernels make it into those distributions, because then they'll support TLS 1.3 but by then there may be a newer version of TLS the current kernels don't support and you'll still need to use a TLS library on those distributions if you want to use the updated protocol version.

The kernel driver forwards the heavy lifting to a user-space daemon that manages the TCP socket (using standard API) and implements TLS.

Then why not move the user-space code into the original user process as part of the standard library?

Read section 8.2 of the paper.

They make two main points:

> By implementing the SSA with a kernel module, developers who wish to use it do not have to link with any additional userspace libraries.

It's not clear why this is a major problem to begin with, but socket() and friends are part of libc, which would be the natural place for something using this type of interface and would then already be linked.

> Adding TLS to the Linux kernel as an Internet protocol allows the SSA to leverage the existing separation of the system call boundary.

The main benefit of this (as they mention) is to separate access to the private key(s). But that could be done for only the private key (signing operation) instead of the entire TLS protocol and would then be generically useful, e.g. for non-TLS protocols that require signing, would provide a standard interface in case you have a HSM, and could be used by a libc implementation or any other TLS implementation.

I'm not sure how I feel about sticking so much complexity into the kernel, but one thing I would really enjoy is being able to use standard tools like `strace` on TLS-speaking processes. With user-space implementations, you only get to see the encrypted content (you can use other tools like ltrace to get around this, but I've found that tools for observing the kernel-userspace boundary are easier to use).

How is this different from the TLS feature the kernel already has?

https://www.kernel.org/doc/Documentation/networking/tls.txt

I think what happened is that feature landed concurrently with the paper - a very early version is mentioned as reference [7].

Netflix also published several papers on their version for openbsd, which I didn't see mentioned.

The feature you linked only handles the symmetric crypto.

TLS and other protocols in this space do very little public key crypto, during a "handshake" phase when they also check everybody is agreed about how the protocol will work and set other parameters, they pick symmetric keys (often two each, it could just one each, and it might be more) and then most of the actual content is handled with just symmetric encryption.

The handshake phase is complicated, whereas the symmetric crypto is very simple. There's also a bunch more policy decisions in the handshake phase, and the Linux kernel tries not to do policy. For example, when your browser connects to a site and there's a problem it often has an "override" feature you can use to connect anyway, if the policy deciding whether to allow connections was in the kernel... too bad?

However this "SSA" does almost everything on the kernel side, at least from the point of view of the application.

It also, and I can't tell how serious they were about this, says it offers the just published TLS 1.3 including 0RTT.

In a way TLS 1.3 is simpler than previous versions, so that makes sense, but it does also add some brand new twists, and more cautious implementations (e.g. in Chrome) don't do 0RTT while they wait to decide how to approach it since it has exciting security properties.

This paper takes those exciting properties a bit more casually than I'm comfortable with. What's _supposed_ to happen here is that protocols on top of TLS (e.g. HTTPS) figure out whether 0RTT is something they'll handle and if so how best to do so. What's definitely NOT safe is to just go "Eh, who cares?" and do 0RTT but treat it the same as the non-0RTT case silently.

Reply on news.ycombinator.com