Implement 2021 Control Protocol #3488
Labels
Comments
|
#2261 was the initial chunk of code for this, with more to follow. |
danderson
added a commit
that referenced
this issue
Dec 3, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Dec 3, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Dec 3, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Dec 3, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Dec 3, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Dec 4, 2021
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
|
How does this relate to https://tailscale.com/blog/tailscale-key-management/ Is there a white paper or design document? |
|
It's a revised version of what's described in that post. Uses a different base layer transport, and lays the groundwork for some nice security features (but that aren't going to materialize immediately, this bug is about getting the basics online). The design's not public yet, but will be once this is something the clients actually use. |
danderson
added a commit
that referenced
this issue
Jan 12, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 12, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 13, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
With this change, the client can obtain the initial handshake message separately from the rest of the handshake, for embedding into another protocol. This enables things like RTT reduction by stuffing the handshake initiation message into an HTTP header. Similarly, the server API optionally accepts a pre-read Noise initiation message, in addition to reading the message directly off a net.Conn. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
With this change, the client can obtain the initial handshake message separately from the rest of the handshake, for embedding into another protocol. This enables things like RTT reduction by stuffing the handshake initiation message into an HTTP header. Similarly, the server API optionally accepts a pre-read Noise initiation message, in addition to reading the message directly off a net.Conn. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Jan 17, 2022
Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Feb 26, 2022
When I deployed server-side changes, I put the upgrade handler at /ts2021 instead of /switch. We could move the server to /switch, but ts2021 seems more specific and better, but I don't feel strongly. Updates #3488 Change-Id: Ifbf8ea60a815fd2fa1bfbe1b7af1ac2a27218354 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Feb 26, 2022
When I deployed server-side changes, I put the upgrade handler at /ts2021 instead of /switch. We could move the server to /switch, but ts2021 seems more specific and better, but I don't feel strongly. Updates #3488 Change-Id: Ifbf8ea60a815fd2fa1bfbe1b7af1ac2a27218354 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Mar 6, 2022
Updates #3488 Change-Id: I8729cb3fb7f6dda1a874f8ae2d9570311ed158db Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Mar 6, 2022
Updates #3488 Change-Id: I8729cb3fb7f6dda1a874f8ae2d9570311ed158db Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Mar 6, 2022
Updates #3488 Change-Id: I8729cb3fb7f6dda1a874f8ae2d9570311ed158db Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Mar 6, 2022
Updates #3488 Change-Id: I8729cb3fb7f6dda1a874f8ae2d9570311ed158db Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Mar 6, 2022
Updates #3488 Change-Id: I8729cb3fb7f6dda1a874f8ae2d9570311ed158db Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 7, 2022
This is so that we can plumb our client capability version through the protocol as the Noise version. The capability version increments more frequently than strictly required (the Noise version only needs to change when cryptographically-significant changes are made to the protocol, whereas the capability version also indicates changes in non-cryptographically-significant parts of the protocol), but this gives us a safe pre-auth way to determine if the client supports future protocol features, while still relying on Noise's strong assurance that the client and server have agreed on the same version. Currently, the server executes the same protocol regardless of the version number, and just presents the version to the caller so they can do capability-based things in the upper RPC protocol. In future, we may add a ratchet to disallow obsolete protocols, or vary the Noise handshake behavior based on requested version. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 7, 2022
This is so that we can plumb our client capability version through the protocol as the Noise version. The capability version increments more frequently than strictly required (the Noise version only needs to change when cryptographically-significant changes are made to the protocol, whereas the capability version also indicates changes in non-cryptographically-significant parts of the protocol), but this gives us a safe pre-auth way to determine if the client supports future protocol features, while still relying on Noise's strong assurance that the client and server have agreed on the same version. Currently, the server executes the same protocol regardless of the version number, and just presents the version to the caller so they can do capability-based things in the upper RPC protocol. In future, we may add a ratchet to disallow obsolete protocols, or vary the Noise handshake behavior based on requested version. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 7, 2022
This is so that we can plumb our client capability version through the protocol as the Noise version. The capability version increments more frequently than strictly required (the Noise version only needs to change when cryptographically-significant changes are made to the protocol, whereas the capability version also indicates changes in non-cryptographically-significant parts of the protocol), but this gives us a safe pre-auth way to determine if the client supports future protocol features, while still relying on Noise's strong assurance that the client and server have agreed on the same version. Currently, the server executes the same protocol regardless of the version number, and just presents the version to the caller so they can do capability-based things in the upper RPC protocol. In future, we may add a ratchet to disallow obsolete protocols, or vary the Noise handshake behavior based on requested version. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 7, 2022
This is so that we can plumb our client capability version through the protocol as the Noise version. The capability version increments more frequently than strictly required (the Noise version only needs to change when cryptographically-significant changes are made to the protocol, whereas the capability version also indicates changes in non-cryptographically-significant parts of the protocol), but this gives us a safe pre-auth way to determine if the client supports future protocol features, while still relying on Noise's strong assurance that the client and server have agreed on the same version. Currently, the server executes the same protocol regardless of the version number, and just presents the version to the caller so they can do capability-based things in the upper RPC protocol. In future, we may add a ratchet to disallow obsolete protocols, or vary the Noise handshake behavior based on requested version. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 7, 2022
This is so that we can plumb our client capability version through the protocol as the Noise version. The capability version increments more frequently than strictly required (the Noise version only needs to change when cryptographically-significant changes are made to the protocol, whereas the capability version also indicates changes in non-cryptographically-significant parts of the protocol), but this gives us a safe pre-auth way to determine if the client supports future protocol features, while still relying on Noise's strong assurance that the client and server have agreed on the same version. Currently, the server executes the same protocol regardless of the version number, and just presents the version to the caller so they can do capability-based things in the upper RPC protocol. In future, we may add a ratchet to disallow obsolete protocols, or vary the Noise handshake behavior based on requested version. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 8, 2022
…e time. Doing so makes development unpleasant, because we have to first break the client by bumping to a version the control server rejects, then upgrade the control server to make it accept the new version. This strict rejection at handshake time is only necessary if we want to blocklist some vulnerable protocol versions in the future. So, switch to a default-permissive stance: until we have such a version that we have to eagerly block early, we'll accept whatever version the client presents, and leave it to the user of controlbase.Conn to make decisions based on that version. Noise still enforces that the client and server *agree* on what protocol version is being used, and the control server still has the option to finish the handshake and then hang up with an in-noise error, rather than abort at the handshake level. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
danderson
added a commit
that referenced
this issue
Apr 8, 2022
…e time. Doing so makes development unpleasant, because we have to first break the client by bumping to a version the control server rejects, then upgrade the control server to make it accept the new version. This strict rejection at handshake time is only necessary if we want to blocklist some vulnerable protocol versions in the future. So, switch to a default-permissive stance: until we have such a version that we have to eagerly block early, we'll accept whatever version the client presents, and leave it to the user of controlbase.Conn to make decisions based on that version. Noise still enforces that the client and server *agree* on what protocol version is being used, and the control server still has the option to finish the handshake and then hang up with an in-noise error, rather than abort at the handshake level. Updates #3488 Signed-off-by: David Anderson <danderson@tailscale.com>
maisem
pushed a commit
that referenced
this issue
Apr 27, 2022
maisem
pushed a commit
that referenced
this issue
Apr 27, 2022
|
The ts2021 control protocol design shipped with client version 1.24.0 and is in use by a majority of the device fleet. I'm going to mark the issue as fixed. We've mostly been using it as a reference for PRs relating to the feature, and we can continue to do so for further work even after it is closed. |
Since it has shipped does this mean a white paper or design document is available? 😃 |
bradfitz
added a commit
that referenced
this issue
Jun 8, 2022
Updates #3488 Change-Id: I9272e68f66c4cf36fb98dd1248a74d3817447690 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Jun 8, 2022
Updates #3488 Change-Id: I9272e68f66c4cf36fb98dd1248a74d3817447690 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Jun 8, 2022
Updates #3488 Change-Id: I9272e68f66c4cf36fb98dd1248a74d3817447690 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
bradfitz
added a commit
that referenced
this issue
Jun 8, 2022
Updates #3488 Change-Id: I9272e68f66c4cf36fb98dd1248a74d3817447690 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Soypete
pushed a commit
that referenced
this issue
Jun 14, 2022
Updates #3488 Change-Id: I9272e68f66c4cf36fb98dd1248a74d3817447690 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
|
I also landed here looking for some material on the new control protocol. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a design for a new control protocol that uses Noise and other nice things. This is the tracking bug to wire it up and transition the client over to it incrementally.
The text was updated successfully, but these errors were encountered: