Device Trust for the Web: The Hard Parts

At Teleport we solve a wide range of problems: letting our customers access their infrastructure remotely without passwords or shared secrets, replacing shared credentials in CI/CD workloads with mTLS, and eliminating the need for VPNs to enable Just-In-Time Access to web apps, cloud consoles, databases, and more.

Device trust was the last missing piece in replacing VPNs, as they offer a powerful feature letting customers pin access to specific networks.

In the Zero Trust world, there is no reliance on IPs or specific networks. Instead, device trust makes it so that only trusted devices (as in the devices owned and managed by your organization) may access sensitive resources.

Teleport 12 introduced support for device trust, but until Teleport 16 device trust was exclusive to our CLI client (tsh).

This post will tell you how we brought device trust to the Web, some of the difficulties behind it and what we've done to solve it.

First, a recap:

Recap on device trust

The heart of device trust is identifying a device. While specifics vary, the general solution applied by Teleport is to create a private key in a secure hardware (Secure Enclave on macOS, TPMv2 on other systems) and use the corresponding public key to identify the device.

Other important concepts in device trust are the device inventory (the list of known devices of an organization), device registration (adding a device to the inventory) and device enrollment (creating the device private key and registering its public counterpart on Teleport).

Device authentication is a ceremony in which a device proves possession of its private key by solving a challenge issued by Teleport.

Why is device trust for the Web hard?

The difficulty for Web support stems from the inherent isolation (and consequent security) provided by browsers. Teleport device trust relies on a private key stored in a secure hardware. Browser isolation dictates that the very hardware used to store the private keys can't be accessed.

In an ironic twist, the security the browsers aim to provide through this isolation stops us from adding a much wanted layer of security ourselves.

There are products, such as Chrome Enterprise device trust, that provide the additional security we are looking for, but those products aren't good enough for a general-purpose solution. We don't want our customers to have to subscribe to Chrome Enterprise to enjoy device trust, we want it to just work.

The path forward is clear: if a browser can't perform the device authentication ceremony, then another process (in its computing sense) has to do it on its behalf.

Web authentication, take #1

A first delegated authentication draft might look like this:

There are various ideas introduced by the design, so let's break down the interesting parts.

1. Authentication is done in two stages: it's initiated by the browser and performed by Teleport Connect, our native Teleport client app.
2. The browser receives a "device web token" (shortened to "webToken") during login. That token is sent to Connect and later exchanged for a device authentication attempt.
3. Connect is invoked indirectly via a custom "teleport://" URL. That is a nice, portable way to invoke a process from the browser.
4. Connect prompts the user before performing device authentication. This is to draw the user's attention (and give them a chance to reject!) if an unexpected process invokes Connect.
5. On a successful attempt the Teleport server blesses the browser's session with device trust. No sensitive material is shuffled back through the processes.

Teleport Connect is chosen as the delegated process for a few reasons: it's already well placed to handle "teleport://" URLs and, unlike a web browser, it can perform device authentication by itself.

So, is that it? Can you spot the problems in our design?

Attacking the process boundary

There are a few solid ideas in our draft, but it isn't perfect. The astute reader may have realized that it doesn't guarantee that the browser and Connect are in the same machine.

Let's consider the following scenario:

Eve steals Alice's credentials. Eve now wants to bypass device trust controls and thinks to trick the system. She devises a cunning plan: steal the webToken and trick Alice into running the delegated authentication in her trusted device.

Every exclamation mark marks a compromise:

• Eve logs in using Alice's credentials
• Eve launches Connect on Alice's computer (or tricks Alice to do it!)
• Alice accepts the authentication attempt
• Eve's session is wrongly blessed as if she had a trusted device

This conjunction of compromises is rather unlikely, but not impossible. In particular, the last item of the chain should not happen. We can do better.

Web authentication, take #2

It's clear that we need to take the source of the requests into account. Let's revisit our initial design with a few additions:

We expect the browser and Connect to be in the same machine, therefore when both talk to Teleport their IP must match.

This prevents Eve from remotely tricking Alice to authenticate on her behalf. Eve and Alice are at different locations, the IP check fails and, consequently, the device authentication attempt fails.

Defeating a remote attacker is valuable, but what happens if Eve and Alice are in the same network?

Attacking the process boundary, again

Verifying the source IP is a good start, but it doesn't guarantee co-location. After all, many different computers can appear to have the same IP.

If Eve can appear to use the same IP as Alice, how can we tell them apart?

The Token Move check

We've granted many (hypothetical) powers to Eve in our quest to find vulnerabilities, but we still have an unexplored avenue for defense: what if Connect talked back to the browser?

Connect is signed by Teleport. In certain operating systems, like macOS, this signature is a prerequisite to access the Secure Enclave (and, consequently, the device's private key). We can rely on Connect to be genuine: a maliciously modified version won't have access to the device key.

One additional hop thwarts all of Eve's attempts to move the webToken:

Having Connect open the browser lets us assert that both processes are in the same machine. The key changes in the design are:

1. Teleport records the originating session during its initial login attempt
2. When Connect authenticates the device the ceremony doesn't end, instead it gets a "device confirmation token" (shortened to "confirmToken")
3. The confirmation token must flow back to the browser that started it all, then all the way to Teleport, through the same web session.
4. Spending the confirmation token ends the ceremony, blessing the web session with device trust on success

Let's see what happens to Eve's hacking attempt:

Eve can't stop Connect from opening Alice's local browser. The token move is detected through the sudden web session change and the hacking attempt is defeated.

In truth our actual implementation adds many other verifications in order to make Eve's life even harder. Have you guessed what some of them are?

Closing words

Device trust for the web is a problem made hard by the constrained browser environment. Our solution of choice tackles delegated device authentication, facing the challenges inherent to proving that both the browser and Connect are, indeed, co-located.

If you are wondering how device authentication in the Web looks for the end-user, here's a quick demo (the green shield marks a session with a trusted device):

In an ideal world we would tap directly into browser or operating system capabilities and attest the device and processes involved in those ceremonies. This may yet come to be.

Learn more about Teleport's device trust feature in our documentation.