 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
| TLS WG members will want to check out this announcement of a new attack on the TLS renegotiation logic. See here: http://www.extendedsubset.com/ The high-level summary is that the attacker negotiates TLS with the server and then subsequently proxies the client's negotiation *over* that channel. This allows the attacker to inject arbitrary content of their choice in front of data sent from the TLS client to the TLS server. This data will be treated by the server as if it came from the client. Once the new handshake has finished, the attacker can't do anything else useful. The attacker doesn't get to directly see any of the client's plaintext messages but could potentially: - Issue commands which would then piggyback on subsequent authentications by the client, including certificate-based authentication. - Potentially get access to data sent by the client by issuing an earlier command which causes the application layer (e.g., HTTP) to send the client's traffic to the server. Marsh Ray, the initial discoverer, has been working with a bunch of people in the security community to deal with this issue and develop a fix. Tomorrow AM I'll be posting an initial draft that describes the obvious fix, which is to cryptographically bind negotiations to any enclosing connection (if any). I won't be in Hiroshima but I expect the WG will want to discuss this topic. -Ekr |