I am working on an application (using Spring Security) that has two possible user authentication mechanisms:

  • either X.509 certificate (using mutual SSL handshake)
  • or user + password

For user+password, I added a brute-force prevention mechanism based on IP blocking (simple POC tutorial), when there are lots of consecutive failed user+password login attempts from the same IP address (the app is internal, so should not be exposed to ISP proxies hiding users).

But is it possible to do (somehow) brute-force attacks with X.509 certificates?

EDIT: I am checking if the certificates are emitted by approved CAs (using a JKS trust-store).


The X509 just authenticates the identity the user is claiming to be, so in theory yes. But an attacker is not going to brute force guessing the correct keys for a X509 certificate because there are so many possibly keys.

| improve this answer | |

Certificates embeds an asymmetric public key for some cryptographic scheme (e.g. RSA).

If you were to try to brute force certificate authentication, you would need to get your hand on the public certificate (easy), then derive the private key from the public key.

This would in fact be solving the problem of breaking the underlying cryptographic scheme, for which we do not currently have an efficient method to do so. Brute forcing isn't a realistic attack in this case.

The realistic attack on client certificate would be to acquire the private key from the client computer and acquire the password protecting it (if there's one). This can be done by conventional means, like using trojan, social engineering techniques and so on. The password method is already vulnerable to the same attack anyway.

| improve this answer | |
  • Well said, it's why client's RSA key should be protected with all means. I'm working embedded devices, and this keys is always encrypted. Also we employ TEE, and in plain form it never leaves TEE, all private operations are there. It's petty sad to see how PC are retarded. – VovCA Jun 1 '17 at 17:56

Given that you've expressed that the cert alone is a sufficient identifier, I'll assume that you're asking "given that someone has seen a certificate go over the wire, can they brute force their way in as that user later?". (Vs "can someone wardial getting into account X by using all the certs they exfiltrated from some computers?" - which is an easy "yup")

The answer is: Of course. But anyone who would try to do so is foolish.

Given a certificate what a brute forcer is trying to do is determine the private key that goes with the public key embedded in the certificate. Doing a TLS brute force attack would be equivalently "try 000000...00000, 0000...000001, 000000...000002", which just comes down to signature forgery. But, since the attacker could themselves just compute the sign+verify operations they can do an offline attack; so by the time they get around to talking to your service they should have already determined they have the right answer (since they are just going to run the same formula you are, modulo whatever access rights you check for based on certificate properties).

They could also just start jamming self-signed certificates (or 3rd party CA signed certificates) at your service to see if you've done an overly simplistic authentication model (such as reading a value out of the subject without doing CA pinning); but that's not really "brute force" so much as "breaking your auth model".

| improve this answer | |

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.