TLS Secured Browser Extension ↔ Desktop App Websockets Connection

Idea name:
Secure Desktop App ↔ Browser Extension Pairing with Encrypted Handshake


Description:
Implement a secure handshake mechanism between a desktop application and a browser extension, where each generates a secret (Desktop Secret / Browser Secret) and displays them on a non-copyable canvas. A user manually enters the secrets into each application to bootstrap trust. The desktop app and browser extension then use derived AES keys to encrypt and exchange secrets, verifying each other’s identity and establishing a secure WebSocket channel with TLS. This ensures mutual authentication and end-to-end encryption for subsequent communications.


Use case:
As a user, I want to securely pair my desktop application with my browser extension so that I can ensure only legitimate parties connect to each other and securely exchange data.


Target user:

  • Individuals or organisations requiring a level of security and privacy when interacting between a local desktop client and a browser extension.

Why this is important:

  • Security: Prevents unauthorised extensions or apps from connecting, avoiding man-in-the-middle attacks.
  • User Confidence: Manual secret entry ensures human-in-the-loop verification.
  • Data Integrity & Privacy: AES encryption and TLS add multiple layers of protection.
  • Compliance: Assists in meeting security standards requiring strong authentication and encryption.

Any other comments:

  • This approach leverages well-understood cryptographic primitives (TLS, AES) while incorporating user interaction to defend against phishing or automated attacks.
  • The non-copyable canvas display mitigates clipboard-based leaks.

High-Level Steps

1. Browser Extension Creates BS

  1. Browser Extension generates BS (Browser Secret).
  2. Browser Extension immediately derives bK = AESKey(BS).
  3. Browser Extension displays BS on a non-copyable canvas (so the user cannot just copy/paste).

2. User Inputs BS into Desktop App

  1. User enters BS into the Desktop App.
    • The Desktop App acquires BS, which it needs to incorporate into its TLS certificate.

3. Desktop App Generates DS and TLS Certificate

  1. Desktop App generates DS (Desktop Secret).
  2. Desktop App immediately derives dK = AESKey(DS).
  3. The Desktop App then computes a salted hash for the certificate, example: hashedBS = SHA256(BS | DS | randomSalt)
    • randomSalt is newly generated cryptographically.
    • The Desktop App stores hashedBS and randomSalt locally.
  4. Desktop App embeds hashedBS and randomSalt in a custom certificate extension.
  5. Desktop App finalises and signs the TLS certificate containing hashedBS + randomSalt.
    • This certificate is now unique to the combination of BS + DS + salt.
  6. Desktop App displays DS on a non-copyable canvas.

4. User Inputs DS into Browser Extension

  1. User enters DS into the Browser Extension.
    • Now the Browser Extension has both BS (its own secret) and DS (from the user).
    • It can also compute dK = AESKey(DS).

5. Browser Extension Verifies TLS Certificate

  1. Browser Extension retrieves the Desktop App’s TLS certificate.
  2. Browser Extension extracts hashedBS and randomSalt from the certificate extension.
  3. Browser Extension recalculates hashedBS_ext = SHA256(BS || DS || randomSalt).
  4. Browser Extension compares hashedBS_ext to the hashedBS from the certificate:
    • If mismatch, the certificate is not for this pairing; reject the connection.
    • If match, the Browser Extension confirms the Desktop App’s certificate is specifically for BS + DS.

6. Standard Encrypted Handshake

  1. Browser Extension encrypts BS with dKPairing Payload Request.
    • dK = AESKey(DS) was derived at step 11.
  2. Browser Extension sends the Pairing Payload Request via the TLS-secured WebSocket to the Desktop App.
  3. Desktop App (already has dK) decrypts the Pairing Payload Request → recovers BS.
    • Compares it with the user-entered BS (step 4).
    • If mismatch, terminate.
  4. Desktop App generates a challenge token (CT).
  5. Desktop App (knowing BS) derives bK = AESKey(BS).
  6. Desktop App encrypts (DS + CT) with bKPairing Payload Response.
  7. Desktop App sends the Pairing Payload Response to the Browser Extension over TLS.
  8. Browser Extension (already has bK) decrypts (DS + CT).
    • Verifies DS matches the DS from step 11.
    • If mismatch, terminate.
  9. Browser Extension encrypts CT with dK and sends it back to the Desktop App.
  10. Desktop App verifies the returned CT, confirming the Browser Extension’s identity.
  11. Secure communication proceeds with mutual authentication over TLS.

Mermaid Sequence Diagram

sequenceDiagram
    autonumber
    
    participant User
    participant DesktopApp as Desktop App
    participant BrowserExt as Browser Extension

    Note over BrowserExt: (1) Generate BS
    BrowserExt->>BrowserExt: (2) bK = AESKey(BS)
    BrowserExt->>BrowserExt: (3) Display BS (non-copyable)
    
    User->>DesktopApp: (4) Enter BS
    DesktopApp->>DesktopApp: Acquire BS

    DesktopApp->>DesktopApp: (5) Generate DS
    DesktopApp->>DesktopApp: (6) dK = AESKey(DS)
    DesktopApp->>DesktopApp: (7) hashedBS = SHA256(BS || DS || salt)
    DesktopApp->>DesktopApp: (8) Embed hashedBS + salt in TLS cert
    DesktopApp->>DesktopApp: (9) Sign final TLS certificate
    DesktopApp->>DesktopApp: (10) Display DS (non-copyable)
    
    User->>BrowserExt: (11) Enter DS
    BrowserExt->>BrowserExt: dK = AESKey(DS)
    
    BrowserExt->>DesktopApp: (12) Retrieve TLS certificate
    BrowserExt->>BrowserExt: (13) Extract hashedBS + salt from cert
    BrowserExt->>BrowserExt: (14) hashedBS_ext = SHA256(BS || DS || salt)
    BrowserExt->>BrowserExt: (15) Compare hashedBS_ext with cert hashedBS
    alt Certificate mismatch
        BrowserExt->>BrowserExt: Reject/terminate
    else
        BrowserExt->>BrowserExt: Certificate is verified for BS + DS
    end

    BrowserExt->>BrowserExt: (16) Encrypt BS with dK -> Pairing Payload Request
    BrowserExt->>DesktopApp: (17) Send Pairing Payload Request over TLS

    DesktopApp->>DesktopApp: (18) Decrypt BS with dK
    DesktopApp->>DesktopApp: Compare BS with user-entered BS
    alt BS mismatch
        DesktopApp->>DesktopApp: Terminate session
    else
        DesktopApp->>DesktopApp: BS verified
    end

    DesktopApp->>DesktopApp: (19) Generate challenge token (CT)
    DesktopApp->>DesktopApp: (20) bK = AESKey(BS)
    DesktopApp->>DesktopApp: (21) Encrypt (DS + CT) with bK -> Pairing Payload Response
    DesktopApp->>BrowserExt: (22) Send Pairing Payload Response

    BrowserExt->>BrowserExt: (23) Decrypt DS + CT with bK
    BrowserExt->>BrowserExt: Compare DS to user-entered DS
    alt DS mismatch
        BrowserExt->>BrowserExt: Terminate session
    else
        BrowserExt->>BrowserExt: Desktop App authenticated
    end

    BrowserExt->>BrowserExt: (24) Encrypt CT with dK
    BrowserExt->>DesktopApp: (25) Send encrypted CT back

    Note over DesktopApp,BrowserExt: (26) Desktop App verifies CT; mutual authentication complete
    Note over DesktopApp,BrowserExt: Secure session established

Security Considerations

Salting & Hashing:

  • Prevents revealing BS in the certificate.
  • Forces the Browser Extension to use both BS + DS to verify hashedBS, ensuring the extension cannot do certificate verification until it knows DS.

Certificate Authenticity:

  • The Desktop App’s certificate is signed (e.g., self-signed or signed by a local CA).
  • The Browser Extension verifies the signature and the custom field containing hashedBS.

Mutual Authentication:

  • After verifying the certificate, the Browser Extension still sends the Pairing Payload Request (BS encrypted by dK).
  • The Desktop App responds with (DS + CT) encrypted by bK.
  • A final challenge token seals the handshake, confirming each side’s identity.

Security Caveats:

  • Must ensure robust random generation of BS, DS, salt, and ephemeral keys.
  • The Browser Extension must parse the certificate carefully and strictly verify the signature.
  • No partial logging of secrets or hashed values in plaintext that could aid offline attacks.

With these measures, you achieve a highly secure handshake that binds the Desktop App’s certificate to the specific BS + DS pairing, preventing rogue certificates and ensuring both sides confirm each other’s identities before establishing a secure connection.

Potential Security Risks

Thinking about how I would break this process

User Interaction & Possible Errors

Multiple Steps & Possible Confusion:

  • The user must perform two manual entries: BS into the Desktop App, then DS into the Browser Extension. Additional complexity arises from verifying that they enter the correct secret into the correct application in the correct order.
  • A hurried or less technical user might mix up the secrets or skip steps if the UI doesn’t provide clear guidance.
  • Existing mitigation:
    • This is accounted for by making DS generation contingent on first receiving BS.

Shoulder Surfing or Camera Capture:

  • Even though the secrets are displayed on non-copyable canvases, a bystander or hidden camera could record the user typing or visually reveal the secrets.
  • Best mitigated by an environment free from surveillance or by encouraging the user to keep the secrets hidden.

TypoTpyographical Mistakes:

  • Manual entry of a possibly long, random secret invites typing errors. Repeated failures could frustrate the user, or repeated attempts might leak partial information to a local keylogger or malicious software.

TLS Certificate Handling

Self-Signed Certificates & Trust:

  • By embedding hashedBS (salted with DS) in the certificate, the system proves that the cert is bound to these specific secrets. However, as the certificate is self-signed the Browser Extension must correctly verify the signature.
  • If the extension doesn’t enforce strict certificate validation (e.g., checking the signature, verifying the signing CA, or pinning the fingerprint), a man-in-the-middle could present a forged certificate with the same hashedBS.

Certificate Reuse:

  • If the Desktop App reuses the same certificate across multiple pairings or sessions, an attacker who obtains that certificate could replay it in another context.
  • Ideally, each new pairing triggers a new certificate generation, with a fresh salt, to prevent replay or cross-session confusion.

Salt & Hashed Secrets Visibility:

  • The certificate reveals hashedBS (and the salt) to anyone who can inspect it. While the raw BS is hidden (since it’s hashed), a brute-force approach might be feasible if BS is not sufficiently long/robust or if an attacker can guess plausible BS values.
  • Mitigation involves using a large random :grimacing: BS and DS, a sufficiently strong hash (e.g., SHA-256 or above), and possibly additional secrets or robust key derivation functions.

Cryptography & Key Management

AES Key Derivation:

  • dK = AESKey(DS) and bK = AESKey(BS) must be derived via a secure function (e.g. a properly salted KDF, not just a simple hash). If it’s too simplistic (e.g., MD5 or a single SHA-256 pass on DS), an attacker with partial knowledge might attempt cracking.
  • Proper random generation for BS and DS is crucial. If the random generator is weak or predictable, an attacker could guess or brute-force the secrets.

Replay Attacks:

  • The handshake includes a challenge token (CT) to prove freshness and avoid straightforward replay. However, if the CT is not random or is reused, or if the session does not strictly validate the token, replay attacks are possible.

Storage & Memory Safety:

  • The Desktop App and Browser Extension each temporarily hold BS, DS, hashedBS, and the derived keys. If these values are logged in plaintext or remain unprotected in memory/disk, a malware infection could harvest them.
  • Best practice is to keep secrets only in memory while needed, clear them afterwards, and use OS-level encryption for any persistent storage.

Environment-Based Threats

Compromised Desktop App Environment:

  • If the desktop is already infected (e.g., with a keylogger or rootkit), the attacker can observe DS and BS as they’re typed or displayed. They might also tamper with the certificate generation process to embed a rogue hashedBS.
  • Proper endpoint security and OS hygiene are essential.

Compromised Browser / Browser Extension:

  • A malicious extension or compromised browser environment could intercept or alter the handshake. It might feed the user a bogus DS or fail to verify the certificate properly.
  • The user must trust that their browser and extension environment is not tampered with.

Network-Level Man-in-the-Middle:

  • TLS ordinarily protects against MITM, but only if the Browser Extension enforces robust certificate checks (signature, hashedBS match, etc.). If the extension simply “accepts any certificate,” the entire scheme collapses.

Usability & Lifecycle

Key Rotation & Revocation:

  • If BS or DS is compromised, or the user needs to revoke access, how is that done? The handshake is typically a one-time process.
  • Without a built-in re-pairing or key-rotation workflow, the user might remain vulnerable if an attacker has stolen the secrets.

Session Persistence:

  • Once the Desktop App and Browser Extension establish trust, do they maintain it across application restarts? If the certificate must be regenerated each time, the user might need to repeat the entire manual procedure. Alternatively, if the certificate is stored and reused, older secrets might remain valid longer than intended.

Overall Thoughts

Despite these potential pitfalls, the outlined process is quite strong in terms of mutual authentication because:

  • It involves a human-in-the-loop who types in secrets manually, reducing purely automated attacks.
  • It binds the TLS certificate to both secrets (BS and DS) via a salted hash, which the Browser Extension can only verify after it knows DS.
  • The final exchange of encrypted secrets and challenge tokens ensures each side is certain the other holds the correct secrets.

However, in practice :face_with_peeking_eye:, its robustness depends on:

  • Implementation details: strong cryptography, safe memory handling.
  • Careful UX design: clear instructions, minimal risk of error.
  • Secure device environments: malware-free, verified extensions.
  • Proper TLS certificate validation in the Browser Extension: rejecting invalid or mismatched certificates.

If all these elements are done correctly, the flow offers a secure solution for pairing the Status Desktop App with the Status Browser Extension. But if any part is neglected, weak random generation, sloppy certificate checks, insecure storage, or a compromised machine, the entire system could be undermined. :slightly_smiling_face:

User Interface Thoughts

Overview

Purpose

  • To guide UX designers and developers on how to present, collect, and validate two passphrases (BS and DS) during a Desktop App ↔ Browser Extension secure pairing process.

Key Steps in the Flow

  1. Extension Code (BS): Browser Extension generates passphrase → user enters it into Desktop App.
  2. Desktop Code (DS): Desktop App generates passphrase → user enters it into Browser Extension.
  3. Verification & Handshake: Certificate checks, key derivations, and final handshake confirmation.

Why Two Codes?

  • Each side proves it holds its own secret, preventing impersonation.
  • The Desktop App can embed BS and DS into its TLS certificate. The Browser Extension can confirm that certificate is specifically for its BS and DS.

Passphrase Format

Both Browser Secret (BS) and Desktop Secret (DS) use the same 64-bit format:
Verb-Adverb-Adjective-Noun

<Verb>-<Adverb>-<Adjective>-<Noun>-<hex nibble>

Where:

  • <Verb>: selected from a 4096-word verb dictionary (12 bits).
  • <Adverb>: selected from a 4096-word adverb dictionary (12 bits).
  • <Adjective>: selected from a 4096-word adjective dictionary (12 bits).
  • <Noun>: selected from a 4096-word noun dictionary (12 bits).
  • <hex nibble>: 4 digit 0–F (16 bits).

Total Entropy: (12*4 = 48) + 16 = 64 bits.

Example:

compute-securely-hidden-server-B42D

Each code is displayed on a non-copyable canvas (if desired), valid for 5 minutes after generation, then expires.


Detailed Flow & UI States

Below is a step-by-step overview of both passphrase entries—BS and DS—with notes on UI elements, validation, and error handling.

1. Browser Extension Generates BS

  1. Action:

    • The Browser Extension randomly picks <number>, <word1..4>, and <hex char>.
    • Immediately derives bK = AESKey(BS) for internal use, but this part is hidden from the user.
  2. UI: Extension Code Screen

    • Title: “Your Extension Code” or “Pairing Code (Extension)”.
    • Passphrase Display (large, bold, non-copyable):
      compute-securely-hidden-server-B42D
      
    • Expiration Timer: “Expires in 04:59…”
    • Instruction: “Type this code into the Desktop App within 5 minutes.”
    • [Regenerate Button] (optional): discards old code, makes a new one.
  3. User sees BS and goes to the Desktop App.

2. User Enters BS into Desktop App

  1. Desktop App: “Enter the Browser Extension Code”

    • Input Field:
      • Single line or segmented.
      • Example placeholder: e.g. compute-securely-hidden-server-B42D
    • 5-Minute Reminder: “This code will expire shortly. Re-generate if needed.”
    • Validation:
      • Check format on the fly (1…4096, dictionary words, final hex nibble).
      • If a segment is invalid, highlight and show an error:
        “Word ‘bridgg’ is not recognised. Please check spelling.”
  2. User clicks [Submit].

    • Desktop App verifies:
      • Time is within 5 minutes of BS generation (if the extension’s timestamp is known via local storage or side channel).
      • Format/dictionary correctness.
  3. Desktop App: If valid, proceeds to:

    • Embed BS in the TLS certificate (or finalise the cert) so that the certificate will reflect the Browser Extension’s secret.
    • Displays success: “Extension Code Accepted.”
  4. Failure Cases:

    • Expired: “This code has expired. Please regenerate a new code in your browser extension.”
    • Invalid: “Code not recognised. Check for typos.”

3. Desktop App Generates DS

  1. Action:

    • The Desktop App now generates its own random 64-bit passphrase in the same format.
    • Immediately derives dK = AESKey(DS) for internal use.
  2. UI: Desktop Code Screen

    • Title: “Your Desktop App Code” or “Pairing Code (Desktop)”.
    • Passphrase Display:
      generate-stealthily-encrypted-token-3B4F
      
    • Expiration Timer: Another 5-minute countdown.
    • Instruction: “Enter this code into the Browser Extension to confirm the Desktop App’s identity.”
    • [Regenerate Button] (optional).

4. User Enters DS into Browser Extension

  1. Browser Extension: “Enter the Desktop App Code”

    • Input Field with placeholder: e.g. generate-stealthily-encrypted-token-3B4F
    • 5-Minute Reminder.
  2. Validation:

    • Check format/dictionary.
    • If out-of-time or incorrectly typed, show a relevant error.
  3. Browser Extension on [Submit]:

    • Confirms DS is valid within 5 minutes.
    • Derives or confirms dK = AESKey(DS).
    • Verifies the Desktop App’s TLS certificate:
      • Ensures the certificate includes the correct hashed BS.
      • Validates signature, checks pinned details if needed.
  4. Success: “Desktop App Code Accepted. Pairing in progress…”

5. Final Certificate Check and Connection

  1. Desktop App and Browser Extension now both have:

    • The other party’s secret (BS or DS).
    • Corresponding AES keys (bK, dK).
    • A validated TLS certificate that ties BS into its extension field.
  2. Browser Extension:

    • Uses the final “Pairing Payload Request” → encrypted with dK.
    • Desktop App decrypts with dK, sees BS, responds with “Pairing Payload Response” → encrypted with bK, containing DS + challenge token.
  3. Browser Extension:

    • Decrypts with bK and verifies DS.
    • If all matches, handshake completes.
  4. UI on both sides: “Connection Established” or “Pairing Complete.”


Full Interaction Summary

Below is the entire user-facing summary:

  1. Browser ExtensionGenerate BS

    • Screen: “Your Extension Code”
    • Shows passphrase: compute-securely-hidden-server-B42D
    • Timer: 5 minutes.
  2. UserDesktop App:

    • “Enter Extension Code.”
    • Types compute-securely-hidden-server-B42D.
    • Desktop App validates code, finalises TLS cert with embedded BS.
  3. Desktop AppGenerate DS

    • Screen: “Your Desktop App Code.”
    • Shows passphrase: generate-stealthily-encrypted-token-3B4F
    • Timer: 5 minutes.
  4. UserBrowser Extension:

    • “Enter Desktop Code.”
    • Types generate-stealthily-encrypted-token-3B4F.
    • Extension verifies code, checks Desktop’s TLS certificate, final handshake.
  5. Both: “Pairing/Connection Successful!”


Example Screen References

1. Browser Extension: Generate & Display BS

 ---------------------------------------------------------
|         Extension Secret (BS)                           |
|                                                         |
|   compute-securely-hidden-server-B42D                   |
|                                                         |
|   Expires in 04:56                                      |
|   Enter into your Desktop App now.                      |
|                                                         |
|  [ Regenerate ]                                         |
|  [ Close ]                                              |
 ---------------------------------------------------------

2. Desktop App: Enter Extension Code

 ---------------------------------------------------------------------------------
|        Enter Browser Extension Code (BS)                                        |
|                                                                                 |
|   Please type the code from your browser extension.                             |
|   (It expires in 5 minutes.)                                                    |
|                                                                                 |
|   Code: [ compute ] - [ securely ] - [ hidden ] - [ server ] - [ B42D  ]        |
|                                                                                 |
|  [ Submit ]                                                                     |
|                                                                                 |
 ---------------------------------------------------------------------------------
  • Validation: If user types “runwyy,” show “Check spelling for ‘runwyy’.”

3. Desktop App: Generate & Display DS

Once BS is accepted:

 ---------------------------------------------------------
|         Desktop App Code (DS)                           |
|                                                         |
|   generate-stealthily-encrypted-token-3B4F              |
|                                                         |
|   Expires in 04:58                                      |
|   Enter this into your Browser Extension.               |
|                                                         |
|  [ Regenerate ]                                         |
|  [ Done ]                                               |
 ---------------------------------------------------------

4. Browser Extension: Enter Desktop Code

 ---------------------------------------------------------------------------------
|        Enter Desktop App Code (DS)                                              |
|                                                                                 |
|   Please type the code displayed by the Desktop App.                            |
|   (Valid for 5 minutes.)                                                        |
|                                                                                 |
|   Code: [ generate ] - [ stealthily ] - [ encrypted ] - [ token ] - [ 3B4F ]    |
|                                                                                 |
|  [ Submit ]                                                                     |
|                                                                                 |
 ---------------------------------------------------------------------------------

5. Connection Status

After DS is accepted, the extension does final certificate checks and handshake.

  • Success: “Pairing Successful! Connection established.”
  • Error:
    • “Expired code. Please regenerate on the Desktop App.”
    • “Certificate mismatch. Unable to confirm Desktop identity.”

Styling & Accessibility

  • Readable Fonts and High Contrast for passphrases.
  • Non-Copyable Canvas if security requires it, though user convenience might prefer normal text.
  • Provide tooltips or inline instructions to reduce user confusion.
  • For segmented input fields, label each part clearly and validate in real time.

Technical Implementation Highlights

  1. 5-Minute Expiration:

    • Each passphrase (BS or DS) has its own generation timestamp.
    • If currentTime - generationTime > 5 minutes, the passphrase is invalid.
  2. Dictionary Storage:

    • The four 4096-word lists are embedded in both apps for validation.
    • On passphrase entry, each word is matched to an index.
  3. TLS Certificate:

    • The Desktop App includes a salted hash of BS in a custom field.
    • The Browser Extension checks that the Desktop certificate indeed corresponds to the BS it generated.
  4. Final Handshake:

    • The extension encrypts BS with dK; the desktop encrypts DS + challenge with bK.
    • Mutual checks confirm identity.

Wrap Up

This UI reference shows how to collect and validate two separate passphrases, one from the Browser Extension (BS) and one from the Desktop App (DS), in a clear, step-by-step approach. By:

  • Using 64-bit passphrases,
  • Displaying them with non-confusing hyphenation,
  • Expiring them after 5 minutes,
  • Enforcing real-time validation,

we ensure a secure, user-friendly pairing flow where both sides confirm each other’s identities under a TLS-secured handshake.

What Risks Are We Mitigating?

Man-in-the-Middle Attacks (MITM)

  • Without TLS encryption, any attacker with access to the local or network traffic (e.g., on a shared Wi-Fi network, ISP monitoring, corporate network monitoring, or malware) can intercept, modify, or inject blockchain transactions before they are signed.
  • Example Attack:
    • The user sends a legitimate transaction (e.g., sending 1 ETH to Alice).
    • An attacker intercepts and modifies the transaction before it reaches the desktop app.
    • The modified transaction now sends 10 ETH to the attacker’s wallet instead.

Transaction Tampering & Signature Injection

  • Since WebSockets without TLS send unencrypted data, an attacker could inject or replace transaction requests:
    • Fake transaction request: The attacker sends a signature request on behalf of the browser extension (tricking the desktop app into signing an attacker-controlled transaction).
    • Replay attacks: An attacker captures a previously sent transaction request and replays it later or immediately after, potentially tricking the user into signing an old (or slightly modified) transaction.

Credentials & Private Key Exposure

  • If the usage of the browser extension expands in the future it may need to send authentication credentials, API keys, or session tokens via WebSocket messages.
  • Without TLS, these can be read in transit, allowing an attacker to steal these private credentials.

No Endpoint Validation (Risk of Connecting to a Fake Desktop App)

  • With TLS, the desktop app presents a certificate that the browser extension can verify.
  • Without TLS, the browser has no way of knowing whether it’s talking to the real desktop app or an attacker-controlled process on the network.
  • Example Attack:
    • A malicious local app binds to the expected WebSocket port.
    • The browser connects to the fake app, which steals transaction requests and forwards them to an attacker’s wallet.

Lack of Secure Connection Confirmation (No Encryption Indicator)

  • Users expect deserve TLS encryption.
  • Without TLS, there’s no built-in way for the browser extension to confirm that the connection to the desktop app is secure.
  • This makes it easier for malware or MITM attackers to silently intercept blockchain transaction requests.

TLS Solves All of These Problems

Using WebSockets over TLS (wss://) mitigates these issues:

  1. Prevents MITM Attacks: All transaction requests are encrypted, preventing network eavesdropping.
  2. Prevents Transaction Tampering: Data sent between the browser and desktop app cannot be modified in transit.
  3. Verifies the Desktop App’s Identity: The browser extension can validate the TLS certificate before sending blockchain transactions.
  4. Protects User Credentials: Any authentication tokens or private data are encrypted, making them unreadable to an attacker.

TLDR

Using WebSockets without TLS for sending blockchain transactions exposes users to high-risk attacks, including MITM, transaction manipulation, impersonation, and data leaks. WebSockets over TLS is a minimum security requirement to ensure safe, trusted blockchain transaction signing between the browser extension and desktop application.

Also, we should never have shipped this feature without TLS.

An epic has been created [Epic][BC] Secure pairing · Issue #17204 · status-im/status-desktop · GitHub

I am assuming the certificate you would use for the secure websocket connection is self-signed?
In this case, I believe you would need the user to install the certificate manually.
Note that the browser does not prompt for self-signed certificate errors/exception for wss. It’s only done for https.

Also note that wss requirements are usually not needed when hitting localhost.

In summary, I strongly recommend starting with a PoC first to verify the assumptions around wss and tls.