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

Triple Handshakes Considered Harmful Breaking and Fixing Authentication over TLS #9

Closed
hannesm opened this issue Mar 3, 2014 · 3 comments

Comments

@hannesm
Copy link
Member

hannesm commented Mar 3, 2014

problem: session resumption and other mechanisms

solution: ??

references

@hannesm
Copy link
Member Author

hannesm commented Mar 23, 2014

a proposed solution is:

  • As a short-term fix to our renegotiation attack, we propose that TLS clients should ensure that all certificates received over a connection are valid for the current server endpoint, and abort the handshake if they are not. In some usages, it may be simplest to refuse any change of certificates during renegotiation. This is our recommendation to all HTTPS libraries and web browsers.
  • Furthermore, we do not implement session resumption. This has an impact on performance, but better safe than sorry.
  • (from the website, detailing point 1 here): We originally believed that C would refuse this certificate change, but we were surprised to find that a number of TLS client applications, including popular web browsers, silently allow the server certificate to change without providing any warning to their users. The design rationale for this is presumably to allow the server to renegotiate a different ciphersuite (e.g. ECDSA after RSA) or to allow a server to replace its expired certificate in a long-running TLS session, or to simply replace a generic (weak) certificate with a specific (strong) one. In more privacy-conscious scenarios, clients may want to allow the server to negotiate an initial handshake with anonymous credentials and then provide the real server certificate during renegotiation. Still, in the majority of cases, and especially in web scenarios, we believe TLS clients should refuse any server certificate changes during renegotiation.

@hannesm
Copy link
Member Author

hannesm commented Jul 2, 2015

during renegotiation we check the certificate to be valid for the given peer name. we also implement session_hash extension in #287, and require it to resume sessions (resumption is in #283)

@hannesm
Copy link
Member Author

hannesm commented Dec 4, 2015

closing: resumption being allowed only if renegotiation is disabled OR extended master secret is used #306 and dac9e39

@hannesm hannesm closed this as completed Dec 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant