2

As far as I understand after reading this beautifully explained answer, MiTM data injection attacks via client-initiated renegotiation can only happens if the attacker is already in a connection with the server which did not check his credential. He then issues a command, and escalates his privilege by triggering a renegotiation and splicing in an authentic client's handshake, and the server will then mistake the command for one coming from an authentic client.

Similarly, according to this post, the DoS attack works by an attacker first establishing a connection to a server (during which his credential is not checked), and then repeatedly trigger renegotiation on the same connection.

My question is: if I'm operating in an environment where the client's certificate is checked upon first connection, I should not be affected by this, is it correct?

A related question: if the connection is started after StartTLS, since StartTLS checks for client's certificate, are client-initiated renegotiation attacks also not applicable?

1

I don't think client certificates will solve the problem of computational DoS. Consider the sequence of messages in SSL / TLS:

[Source](http://www.garykessler.net/library/images/crypto_ssl.gif)

The client certificate is sent to the server after the ServerKeyExchange message. In the case of [EC]DHE_RSA the ServerKeyExchange message involves the server signing the DH parameters with it's long term public key. So the server has already performed a computationally intensive operation (RSA signature) before the client even sent it it's certificate.

A better approach would be to require a client puzzle to be solved in between the ClientHello and ServerHello messages.

  • I agree that client certificate will not solve the problem of computational DoS, in general; but I'm wondering if you can stop exploits using client-initiated renegotiation in particular, by checking client credential (if available, and I know that's rarely the case). – nullgraph Sep 25 '15 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.