Security Review of MeshClient Implementation

The MeshClient implementation introduces several new features, including plaintext peer compatibility, a WebSocket factory for proxy support, and a KNOCK pending queue. While these features are useful, they also introduce potential security risks. Below is a detailed analysis of the code with identified vulnerabilities, their severity, attack vectors, and recommended fixes.

🔴 1. Prompt Injection Defense Bypass

Issue: The plaintextPeers feature allows certain peers to bypass end-to-end encryption (E2EE) and communicate in plaintext. This creates a significant attack surface for malicious actors who can masquerade as a "plaintext peer" to intercept or inject malicious payloads.

Attack Vector:

• An attacker could spoof a peerId to match one in the plaintextPeers list, allowing them to send or receive unencrypted messages.
• The plaintextPeers feature undermines the security guarantees of E2EE, making the system vulnerable to man-in-the-middle (MITM) attacks.

Recommendation:

• Avoid plaintext communication entirely. If legacy support is necessary, ensure that plaintext peers are authenticated using a secure mechanism (e.g., cryptographic signatures or certificates).
• Log and monitor all plaintext communication for potential misuse.
• Add strict validation for peerId to ensure it cannot be spoofed.

🔴 2. Policy Engine Circumvention

Issue: The knockHandlers array allows dynamic registration of handlers to evaluate KNOCK requests. However, the logic for evaluating KNOCK requests (handleKnock) does not enforce a minimum number of approvals or a quorum. A single handler rejecting a request will deny it, but there is no guarantee that all handlers are executed securely.

Attack Vector:

• A malicious or misconfigured handler could approve unauthorized KNOCK requests, allowing unauthorized sessions to be established.
• An attacker could exploit this to bypass access control policies.

Recommendation:

• Enforce a quorum-based policy for KNOCK evaluation (e.g., require a majority or all handlers to approve).
• Log all KNOCK evaluations and their outcomes for auditing.
• Validate intent fields in KNOCK requests to ensure they conform to expected schemas.

🔴 3. Trust Chain Weaknesses

Issue: The wsFactory option allows users to provide a custom WebSocket implementation. While this is useful for proxy support, it introduces the risk of using an insecure WebSocket implementation that does not validate TLS certificates or is vulnerable to man-in-the-middle attacks.

Attack Vector:

• A malicious actor could provide a compromised wsFactory that disables TLS verification or introduces vulnerabilities, allowing them to intercept or manipulate WebSocket traffic.

Recommendation:

• Enforce strict validation of the wsFactory implementation to ensure it uses secure TLS connections.
• Provide a secure default implementation and warn users about the risks of using custom WebSocket factories.

🔴 4. Credential Exposure

Issue: The plaintextPeers feature uses base64 encoding for JSON payloads in plaintext communication. Base64 encoding is not encryption and does not provide any confidentiality. Sensitive data in plaintext messages could be exposed to eavesdroppers.

Attack Vector:

• An attacker intercepting plaintext messages could easily decode the base64-encoded payload and access sensitive information.

Recommendation:

• Do not use plaintext communication for sensitive data. If plaintext communication is unavoidable, ensure that sensitive data is encrypted at the application layer before transmission.

🟠 5. Sandbox Escape

Issue: The wsFactory option allows arbitrary code execution by accepting a user-provided function to create WebSocket connections. This could be exploited to execute malicious code within the application.

Attack Vector:

• An attacker with access to the wsFactory option could inject malicious code that compromises the host environment.

Recommendation:

• Validate the wsFactory function to ensure it adheres to a strict interface and does not execute arbitrary code.
• Consider restricting the use of wsFactory to trusted contexts or environments.

🟠 6. Deserialization Attacks

Issue: The handleMessage method deserializes JSON payloads from plaintext messages without validating their structure or content.

Attack Vector:

• An attacker could craft a malicious JSON payload that exploits vulnerabilities in the JSON parser or causes unexpected behavior in the application.

Recommendation:

• Validate and sanitize all deserialized JSON payloads against a strict schema before processing.
• Use a secure JSON parsing library that mitigates common deserialization vulnerabilities.

🟠 7. Race Conditions in KNOCK Handling

Issue: The knockPending map and its associated KnockResolver objects are vulnerable to race conditions. Multiple KNOCK requests from the same peer could overwrite each other's resolve functions, leading to inconsistent behavior.

Attack Vector:

• An attacker could send multiple KNOCK requests in rapid succession, potentially causing the knockPending map to behave unpredictably or drop valid requests.

Recommendation:

• Use a more robust mechanism for managing pending KNOCK requests, such as a queue or a more sophisticated state machine.
• Ensure that each KNOCK request is uniquely identified and handled independently.

🟡 8. Supply Chain Risks

Issue: The implementation relies on external dependencies (e.g., WebSocket, crypto, and potentially user-provided wsFactory implementations). If these dependencies are compromised, the security of the entire system could be at risk.

Attack Vector:

• An attacker could exploit vulnerabilities in third-party dependencies or introduce malicious code via dependency confusion or typosquatting.

Recommendation:

• Use dependency pinning to lock versions of third-party libraries.
• Regularly audit dependencies for known vulnerabilities using tools like npm audit or Snyk.
• Consider implementing runtime integrity checks for critical dependencies.

🟡 9. Lack of Logging for Security Events

Issue: The implementation lacks comprehensive logging for critical security events, such as KNOCK evaluations, session establishment, and plaintext message transmissions.

Attack Vector:

• Without proper logging, it would be difficult to detect or investigate security incidents, such as unauthorized access or data breaches.

Recommendation:

• Implement structured logging for all security-sensitive events, including KNOCK evaluations, session establishment, and plaintext message handling.
• Ensure logs are securely stored and monitored for suspicious activity.

Summary of Findings

General Recommendations

1. Security Review: Conduct a thorough security review of the plaintextPeers feature and its implications for the overall security model.
2. Testing: Implement unit and integration tests to validate the security of the MeshClient implementation, particularly around KNOCK handling and plaintext communication.
3. Documentation: Clearly document the risks associated with using plaintext peers and custom WebSocket factories, and provide guidance on secure usage.

This PR introduces critical security risks that must be addressed before merging.