
Secure Socket API: POSIX socket API as a vehicle for a simplified TLS API - fanf2
https://owntrust.org/ssa
======
ognyankulev
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](https://github.com/bob-
beck/libtls/blob/master/TUTORIAL.md) . There is also a nice presentation
[https://www.openbsd.org/papers/linuxconfau2017-libtls/](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/](https://docs.rs/libtls/0.0.1/libtls/)

------
jchw
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.

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

Userland is much more susceptible to attacks.

~~~
zrm
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.

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

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

~~~
mayoff
Read section 8.2 of the paper.

~~~
zrm
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.

------
peff
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).

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

[https://www.kernel.org/doc/Documentation/networking/tls.txt](https://www.kernel.org/doc/Documentation/networking/tls.txt)

~~~
tialaramex
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.

