Signal Server
Summary
ExpandSignal Server is a Java-based backend infrastructure project that powers the Signal messaging platform's server-side operations, organized across seven primary modules including API documentation, core service logic, Java templates, and integration tests. The service layer, rooted under `org/signal`, implements the cryptographic messaging protocols, account management, device registration, and message routing that underpin Signal's end-to-end encrypted communication model. The architecture reflects a modular design philosophy with clear separation between API surface definitions, core business logic, and test infrastructure, enabling independent evolution of each layer while maintaining a cohesive security boundary.
The codebase demonstrates a mature approach to security engineering consistent with Signal's reputation as a privacy-focused platform. Cryptographic operations are handled through well-established libraries, and the authentication layer employs JWT-based token mechanisms for service-to-service and client-to-server authorization flows. The project's integration test suite provides coverage of critical authentication and message-handling pathways, indicating an awareness of the importance of validating security-sensitive behavior under realistic conditions.
This audit identified one low-severity finding across the seven analyzed modules, reflecting a generally strong security posture for a project of this scope and sensitivity. The absence of high or low-severity vulnerabilities suggests that Signal's development practices — including their emphasis on cryptographic rigor and minimal attack surface — are effective at preventing the most dangerous classes of server-side flaws. The single finding identified, concerning JWT token generation without expiration claims (M-1), represents a meaningful but bounded improvement opportunity in the token lifecycle management layer rather than a systemic architectural weakness.
Findings
1 issue identified
JWT Tokens Generated Without Expiration Claims
JwtGenerator.java:28
View Details
Description
The JwtGenerator.generateJwt method creates JWT tokens with an issuedAt claim but no expiresAt claim. None of the callers (TusAttachmentGenerator, Cdn3BackupCredentialGenerator) add an expiration via the claimCustomizer. All CDN access tokens for attachment uploads and backup read/write operations have no expiration and remain valid indefinitely.
Impact
If a CDN access JWT is compromised through log exposure, client vulnerability, or network interception, it can be reused indefinitely. A leaked write token could allow overwriting backup data. A leaked read token could allow ongoing unauthorized access to encrypted backup content. Recovery requires rotating the underlying HMAC shared secret, invalidating all tokens for all users.
Recommendation
Add a default expiration claim (e.g., 1 hour) to JwtGenerator.generateJwt so all tokens expire automatically. The claimCustomizer can still override for specific use cases.
Fix
Adds a default 1-hour expiration to all generated JWT tokens. The claimCustomizer callback executes after the default is set, allowing callers to override the expiration if a different TTL is needed for specific use cases. This ensures tokens automatically become invalid after a bounded period, limiting the exposure window if a token is compromised.
service/src/main/java/org/whispersystems/textsecuregcm/auth/JwtGenerator.java
Conclusion
ExpandThe overall code quality of Signal Server reflects a disciplined engineering culture with a clear emphasis on security-by-design principles. The modular architecture facilitates auditability, and the consistent use of established cryptographic libraries rather than custom implementations demonstrates sound judgment in an area where bespoke solutions frequently introduce subtle vulnerabilities. The integration test infrastructure further reinforces confidence in the correctness of security-critical pathways, though the JWT expiration gap identified in M-1 suggests that token lifecycle policies should be reviewed holistically to ensure that all issued tokens carry appropriate temporal constraints, reducing the window of exposure should a token be compromised.
The low-severity finding concerning JWT tokens generated without expiration claims warrants prompt remediation, as tokens lacking expiration effectively remain valid indefinitely unless explicitly revoked through an out-of-band mechanism. In a messaging infrastructure where authentication tokens may traverse multiple services and be cached at various layers, the absence of expiration claims increases the potential impact of token theft or leakage. Introducing mandatory expiration claims with appropriately scoped lifetimes, paired with a token refresh mechanism where applicable, would materially reduce this risk and align the implementation with established JWT best practices outlined in RFC 7519.
Signal Server is well-positioned for continued production deployment, and the single finding identified in this audit does not represent a barrier to operation. The development team should prioritize the remediation of M-1 and verify through the existing integration test suite that the introduction of expiration claims does not disrupt downstream token consumers. Following remediation, a targeted follow-up review of the JWT issuance and validation pathways is recommended to confirm that fixes have been correctly applied and that token lifecycle management is consistently enforced across all service boundaries.
On-Chain Verification
Compare these values with the on-chain attestation
Verify: download the markdown and compare the hash
sha256sum signal-server.md
Legal Disclaimer: This report covers the code submitted for analysis. It does not account for infrastructure, deployment configuration, third-party dependencies, or changes made after the audit date. Automated analysis may produce false positives or miss context-dependent vulnerabilities. audited.xyz provides this report “as is” without warranty of any kind.