Insecure Transport: SSLv3/TLS Renegotiation Stream Injection

Use of unsafe renegotiation can enable an attacker to inject plaintext into the SSL/TLS protocol stream.

Maintaining the confidentiality and integrity of information in transit is a primary function of the SSL/TLS protocol. Vulnerabilities in the protocol implementation could however severely compromise these guarantees. Failure to establish a cryptographic binding of a handshake to the enclosing session causes the SSL/TLS renegotiation protocol to fall victim to man-in-the-middle attacks that could allow an attacker to inject plaintext into the protocol stream. Renegotiation was developed to support long running sessions where encryption keys will need to be changed to ensure cryptographic security. However, the real problem manifests within the application using SSLv3/TLS. Since HTTP requests cannot be processed until they are complete, web servers cache the request until it is finished. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted. This indeterminate buffer state is the manifestation of the problem. Unfortunately, servers vulnerable to this attack are SSLv3/TLS enabled web servers that do NOT flush the request buffers prior to the renegotiation of SSL Keys. Thus an attacker can leverage this oversight to inject data into the beginning of the conversation between unsuspecting clients and the web server.

A server configured to use the vulnerable protocol implementation exposes the hosted application to malicious data injection exploits. An application that lacks appropriate input filters to reject incoming malicious requests can enable an attacker to steal the authentication credentials of users, which can lead to further compromises by using the stolen privileges.