Skip to main content

11. Security Considerations

The security of the TLS protocol is based on the following assumptions:

11.1. Cryptographic Strength​

The security of TLS fundamentally relies on the strength of the cryptographic primitives used. Implementers should:

  • Use strong cipher suites
  • Avoid algorithms with known weaknesses (such as DES, RC4, MD5)
  • Regularly update cryptographic libraries to fix known vulnerabilities

11.2. Random Number Generation​

The security of the TLS protocol heavily depends on cryptographically strong random number generation. Implementations MUST:

  • Use cryptographically secure pseudo-random number generators (CSPRNG)
  • Ensure the random number generator has sufficient entropy sources
  • Regularly reseed the random number generator

11.3. Certificate Validation​

Proper certificate validation is critical for preventing man-in-the-middle attacks:

  • Verify the integrity of the certificate chain
  • Check certificate revocation status (CRL or OCSP)
  • Verify hostname matching
  • Check certificate validity period

11.4. Version Rollback Attacks​

Implementations MUST prevent version rollback attacks. TLS uses version numbers in ClientHello and ServerHello, as well as verify_data in the Finished message, to detect version rollback attempts.

11.5. Known Attacks​

Implementations should be aware of the following known attacks:

  • BEAST (Browser Exploit Against SSL/TLS): Attack against TLS 1.0 CBC mode. TLS 1.2 mitigates this with explicit IVs.
  • CRIME (Compression Ratio Info-leak Made Easy): Attack exploiting TLS compression. It is recommended to disable TLS compression.
  • Lucky 13: Timing attack against CBC mode padding. Implementations should use constant-time comparisons.
  • POODLE: Attack against SSL 3.0. SSL 3.0 should be disabled.
  • Bleichenbacher Attack: Attack against RSA PKCS#1 v1.5 padding. TLS 1.2 includes protections against this.

11.6. Renegotiation​

Renegotiation can introduce security risks. RFC 5246 defines the secure renegotiation extension to address these issues. Implementations should:

  • Implement RFC 5746 (TLS Renegotiation Indication Extension)
  • Carefully handle renegotiation requests
  • Consider refusing renegotiation during sensitive operations

11.7. Denial of Service​

TLS handshakes are relatively expensive (especially public key operations). Servers should:

  • Implement rate limiting
  • Consider using session resumption to reduce the number of full handshakes
  • Monitor and detect anomalous patterns

11.8. Implementation Security​

Beyond protocol-level security considerations, implementations should also:

  • Prevent buffer overflows
  • Securely clear sensitive data (keys, plaintext)
  • Use constant-time comparisons to prevent timing attacks
  • Properly handle error conditions

Note: For a complete security analysis, please refer to Section 11 and Appendix F of RFC 5246.

Last updated on