Hi, thank you too for the detailed explanation. But the impact on the client certificates (and its correct validation etc) is not clear to me (so I ask inline in the second half of this mail).
* Kyle Hamilton wrote on Mon, Jan 11, 2010 at 14:28 -0800: > The most succinct answer is this: the server and client > cryptographically only verify the session that they renegotiate > within at the time of initial negotiation, and never verify > that they're the same two parties that the session was between > at the time of renegotiation. [...] > The worst thing about this attack is that it provides no means > for either the client or server to detect it. As I understood, TLS implementations are not responsible to authorize a peer, just to cryptographically ensure that the identification of it is authentic. This is the same question I asked in my other reply to David's mail: Is it by design impossible to make an application using (optionally a future version of) OpenSSL to verify that e.g. the `Subject' of the peer's certificate remains constant (and authorized for the requested service)? > The client will receive the server's correct certificate, the > same way it expects to. The server will receive either the > client's correct certificate or no certificate (as the client > decides) the same way it expects to. There is no way to > identify this attack at the TLS protocol level. But how can this be, wouldn't the TLS protocol level need to see and verify the client certificate? On renegiotation, no callbacks with the new subject are possible to check if this client certificate (authenticated by TLS implementation) is authorized? I thought this data injection attack fails when client certificates would be used correctly. Does it fail or is it possible? But then an attacker needs a valid client certificate, right? But then in turn, by definition, a user presenting a valid client certificate (and who is authorized) is not an attacker but a valid user, isn't she? (alternatively, when it relies on the server not requiring client certificates I think it would not be an TLS design flaw but a missuse: if the client is not authenticated it means the server talks to anyone. If the server talks to anyone, anyone can send [inject] data. In this case I think it would not be a TLS design flaw but a missuse, caused by lazyness and that Twitter registration sends a password by mail or some confirmation link or whatever, but not a generated client certificate [with key]). oki, Steffen -- --[end of message]------------------------------------------------->8======= About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,850 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
