You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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.
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)
problem: session resumption and other mechanisms
solution: ??
references
The text was updated successfully, but these errors were encountered: