Conversation
|
|
Great job! No new security vulnerabilities introduced in this pull request |
| Commands: | ||
| connect Connect to a remote device (default) | ||
| listen Listen for incoming connections | ||
| cache Manage session cache |
There was a problem hiding this comment.
I don't think we should document the CLI interface here. It's too fast moving and hard to keep up to date.
| | **User Client** | Trusted device (e.g., laptop with Bitwarden vault). Listens for incoming connections, approves requests, and serves credentials. | | ||
| | **Remote Client** | Untrusted device requesting credentials. Initiates connections and sends credential requests. | | ||
| | **Proxy Server** | WebSocket relay. Authenticates clients, facilitates peer discovery (rendezvous), and routes encrypted messages. Cannot decrypt payloads. | | ||
|
|
There was a problem hiding this comment.
I don't really like the term "device", but struggle with coming up with another name.
And I'm not sure I like the Trusted/Untrusted monicker.
We're really trying to represent:
User Client -- attached to a vault/password manager and is reponsible for answering requests (Approval etc) and can access passwords.
Remote Client - Does not have access to the vault/password manager, except through sending requests to the UserClient.
Maybe "User Client" should be "Vault Client"... or "ContentClient" etc etc?
Naming is hard, but let's start with removing the terms device and trusted/untrusted.
Note: We can keep "device" for the "Multi-device" references later in this doc.
| ## 1. Overview | ||
|
|
||
| The Bitwarden Remote Access Protocol enables secure peer-to-peer credential sharing between a **User Client** (trusted device holding credentials) and a **Remote Client** (untrusted device requesting credentials). Communication is relayed through a **Proxy Server** that operates with zero knowledge of message contents. | ||
|
|
There was a problem hiding this comment.
see comment about device/trusted device, try to apply it. Although the references makes more sense here.
| } | ||
| ``` | ||
|
|
||
| - **Format**: 6 alphanumeric characters with hyphen separator (e.g., `"ABC-DEF"`) |
There was a problem hiding this comment.
Rendevouz tokens are now 9 chars + 2 hypens.
| } | ||
| ``` | ||
|
|
||
| **Server cleanup**: Background task runs every 60 seconds, removing expired entries. |
There was a problem hiding this comment.
I don't think we need to document how the server cleans up in the protocol def.
|
|
||
| bw-proxy (WebSocket relay server binary) | ||
| └── bw-proxy-protocol | ||
| ``` |
There was a problem hiding this comment.
note: we will tweak crates names to remove the bw-prefix.
| - Signature verification fails → drop connection | ||
| - Timeout (>5s) → drop connection | ||
|
|
||
| ### 5.3 Phase 2: Rendezvous (Optional) |
There was a problem hiding this comment.
I think Phase 2 is discovery + handshake?
And we need to clarify that there are two methods, Rendevouz + PSK.
And it's not really optional, but you can pick which mode you prefer.
| **Send-side** (time-triggered): | ||
| - Every `rekey_interval` seconds (default: 86,400 = 24 hours) | ||
| - New key derived: `new_key = XChaCha20-Poly1305_Encrypt(old_key, nonce=0xFF×24, plaintext=0x00×32)` | ||
| - `send_rekey_counter` incremented |
There was a problem hiding this comment.
Are we sure about this? Let's verify
2 participants
No description provided.