Responses inline. :) On Tue, Jan 12, 2010 at 3:12 AM, Steffen DETTMER <steffen.dett...@ingenico.com> wrote:
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 correct. The problem is that there is an MITM capability that the protocol allows for, which it should not have, and the reason is that the prior cryptographic session is not cryptographically authenticated by the new credentials.
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)?
No, for a couple reasons. 1) The IETF has issued a Last Call for the renegotiation-indication proposed standard. 2) It is possible to register a callback function in the SSL or SSL_CTX object, which will iterate every certificate that is presented during a renegotiation. #1 means that the next version of OpenSSL will almost certainly fix the prefix-injection attack scenario. #2 means that you can see *all* of the certificates that the peer presents, and the return value of the function tells the library what to do now that you've seen it -- continue the connection, or abort it.
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?
The problem is this: The attacker makes a connection to a TLS-enabled server, sending no certificate. It sends a command that, for whatever reason, needs additional privilege (in Apache's case, Directory and Location clauses can require additional security above what the default VirtualHost configuration negotiates). Then, it just starts proxying packets between the client and the server. When the server receives the request for a higher-authentication-required resource, it sends a ServerHello to initiate a renegotiation. The packets, as they are proxied as-is to the client, are not modified by the attacker in any way. This means that the ServerHello renegotiation is going to negotiate for a client certificate, and the client can't going to know that there's any problem in doing so. One way to deal with this would be to enforce that all access to resources on the same webserver require the same "security cloak" -- that is, have the server demand a certificate during the initial negotiation, so that *all* data that comes in is authenticated as being from that identity.
I thought this data injection attack fails when client certificates would be used correctly.
It does, in the event that the server configuration does not allow for non-client-certificated connections in any manner, in any way, for any purpose. THAT is "when client certificates are used correctly".
Does it fail or is it possible?
This attack fails in the presence of client certificates if and only if there is no means to make a connection with no authentication, submit data, and then have the server request additional authentication.
But then an attacker needs a valid client certificate, right?
If the server requires a valid client certificate on initial negotiation, and the attacker has a valid client certificate, then the attacker is limited to the privileges authorized to that identity and would have the same access privileges as a legitimate user. This attack is used and is useful in the event that different resources on the same server require different levels of authentication, *including no authentication*. If you get rid of the 'allow non-authenticated SSL clients' part of the policy on that server, you do away with the problem.
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?
Correct. In fact, if this certificate is presented during the initial negotiation, it is impossible to perform this MITM attack.
(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]).
In Twitter's case, they don't require certificate authentication. This means that they will never be able to prevent this attack without disabling renegotiation until the Secure Renegotiation Indicator draft standard is implemented on both the servers and the clients. And yes: the problem is caused by TLS misuse, but the reason for the misuse isn't on the server side. PKCS#11 tokens all have their own key generation routines and have to provide a C API for the architecture they're being used on, and I've yet to figure out how to add a PKCS#11 device to Windows (I want to try to add NSS's crypto container to it, but...). Even Microsoft has a specific manner in which it submits signing requests to CAs, and I'm not sure the documentation on it even exists. Firefox makes it insanely difficult to figure out how to generate a key or even look at the list of certificates that you have to encrypt to. Opera I haven't used, but if it doesn't use the platform keystore it's only adding to the problem. Of all the things that I've seen thus far, only Apple's Keychain Manager seems to have put any thought at all into the problem, and that's only to move from generation 0 interfaces to an interface that can at best be called interface generation 0.2. The point I wanted to make in that last paragraph is: the users can't figure out how to generate keys, much less submit requests to CAs. This reduces the provisioning of client certificates, and thus reduces the market. What's needed is a useful mechanism and interface for managing these things, and nobody's created that yet. I hope I've helped you understand a bit more clearly. If you have more questions, don't hesitate to ask. :) -Kyle H
smime.p7s
Description: S/MIME Cryptographic Signature
