Weak Cryptographic Key and Signature Algorithm in SSL/TLS Certificate

Risk: medium

Description

SSL/TLS certificates with weak cryptographic keys or signature algorithms pose significant security risks, leaving systems vulnerable to cryptographic attacks.

Key points about weak cryptographic keys and signature algorithms:

1. Weak Cryptographic Keys:
2. RSA Keys: RSA keys shorter than 2048 bits are considered weak. The current recommendation is to use at least 2048 bits, with 3072 bits or higher for long-term security.
3. DSA Keys: Similar to RSA, DSA keys shorter than 2048 bits are considered weak and should be avoided.
4. Computational Advances: As computational power increases, shorter key lengths become increasingly vulnerable to attacks.

5. Industry Standards: Many industry standards and compliance requirements mandate minimum key lengths for SSL/TLS certificates.

6. Weak Signature Algorithms:

7. Obsolete Algorithms: MD5 and SHA1 are considered cryptographically broken and should not be used.
8. Collision Attacks: Weak algorithms are vulnerable to collision attacks, where an attacker can create a fraudulent certificate with the same signature as a legitimate one.
9. Industry Standards: Many industry standards and compliance requirements prohibit the use of weak signature algorithms.
10. Backwards Compatibility: Some systems may still use weak algorithms for backwards compatibility, but this practice is strongly discouraged.

Real-World Implications: A website using a certificate with a 1024-bit RSA key or signed with SHA1 could be targeted by attackers with significant computational resources. They could decrypt intercepted traffic or create forged certificates, enabling man-in-the-middle attacks and compromising the security of communications. As such, adherence to industry standards requiring strong keys and algorithms is essential to maintaining SSL/TLS security.

Recommendation

To address weak key vulnerabilities:

1. Use Adequate Key Lengths:
2. For RSA and DSA, use a minimum key length of 2048 bits.

3. Consider using 3072 bits or higher for long-term security.

4. Consider Elliptic Curve Cryptography (ECC):

5. ECC provides equivalent security with shorter key lengths, offering better performance.

6. Use curves like P-256 or P-384 for strong security.

7. Regular Key Rotation:

8. Implement a policy to regularly rotate keys, especially when upgrading to stronger key lengths.

9. Audit Existing Certificates:

10. Regularly audit your SSL/TLS certificates to identify and replace any with weak keys.

11. Use Modern Certificate Authorities:

12. Choose CAs that enforce strong key requirements and follow industry best practices.

13. Implement Strong Key Generation Practices:

14. Use cryptographically secure random number generators when generating keys.
15. Consider using hardware security modules (HSMs) for key generation and storage.

Detect this with Ostorlab

Ostorlab checks web applications, APIs and networks for this issue.

Create an account

Links

• NIST Recommendation for Key Management
• Baseline Requirements for TLS Server Certificates
• SSL Labs Best Practices

Standards

• SOC2_CONTROLS:
  • CC_6_7
  • CC_7_1
• CCPA:
  • CCPA_1798_150
• HIPAA_CONTROLS:
  • SECURITY252
  • SECURITY212
  • SECURITY213
  • SECURITY255
• GDPR:
  • ART_32
• PCI_STANDARDS:
  • REQ_4_1
  • REQ_6_2
• OWASP_TOP_10:
  • A02_2021