Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implementation pitfalls from rfc5246, d.4 #31

Closed
hannesm opened this Issue Mar 22, 2014 · 1 comment

Comments

1 participant
@hannesm
Copy link
Member

hannesm commented Mar 22, 2014

Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand, and have been a source of interoperability and security problems. Many of these areas have been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors.

TLS protocol issues:

  • Do you correctly handle handshake messages that are fragmented to multiple TLS records (see Section 6.2.1)? Including corner cases like a ClientHello that is split to several small fragments? Do you fragment handshake messages that exceed the maximum fragment size? In particular, the certificate and certificate request handshake messages can be large enough to require fragmentation.
  • Do you ignore the TLS record layer version number in all TLS records before ServerHello (see Appendix E.1)?
  • Do you handle TLS extensions in ClientHello correctly, including omitting the extensions field completely?
  • Do you support renegotiation, both client and server initiated? While renegotiation is an optional feature, supporting it is highly recommended.
  • When the server has requested a client certificate, but no suitable certificate is available, do you correctly send an empty Certificate message, instead of omitting the whole message (see Section 7.4.6)?

Cryptographic details:

  • In the RSA-encrypted Premaster Secret, do you correctly send and verify the version number? When an error is encountered, do you continue the handshake to avoid the Bleichenbacher attack (see Section 7.4.7.1)?
  • What countermeasures do you use to prevent timing attacks against RSA decryption and signing operations (see Section 7.4.7.1)?
  • When verifying RSA signatures, do you accept both NULL and missing parameters (see Section 4.7)? Do you verify that the RSA padding doesn't have additional data after the hash value? [FI06]
  • When using Diffie-Hellman key exchange, do you correctly strip leading zero bytes from the negotiated key (see Section 8.1.2)?
  • Does your TLS client check that the Diffie-Hellman parameters sent by the server are acceptable (see Section F.1.1.3)?
  • How do you generate unpredictable IVs for CBC mode ciphers (see Section 6.2.3.2)?
  • Do you accept long CBC mode padding (up to 255 bytes; see Section 6.2.3.2)?
  • How do you address CBC mode timing attacks (Section 6.2.3.2)?
  • Do you use a strong and, most importantly, properly seeded random number generator (see Appendix D.1) for generating the premaster secret (for RSA key exchange), Diffie-Hellman private values, the DSA "k" parameter, and other security-critical values?

@hannesm hannesm referenced this issue Jun 2, 2014

Closed

release TODO #94

13 of 19 tasks complete
@hannesm

This comment has been minimized.

Copy link
Member Author

hannesm commented Dec 4, 2015

closing (convinced myself that we're addressing the issues raised sufficiently (lucky13 is still an open issue #49 (maybe @jakemask has some input & test case at some point)))

@hannesm hannesm closed this Dec 4, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.