There is a client which supports really old SSL ciphers, including


Probably it has a really old SSL library with known security bugs. But the server is up to date and properly configured. It it possible to exploit it? If yes - how?


Given how old these ciphers are I could imagine that the client also supports SSLv2 which is broken. Also it will probably accept certificates signed with MD5 or even MD4 or MD2 which are broken too so one should be able to create a faked certificate accepted by the client. That is if the client checks certificates at all because even a few years ago it was still very common that programs did not check the SSL certificate. Thus I think an active man in the middle attack should be possible.

  • Comments are not for extended discussion; this conversation has been moved to chat. – Rory Alsop May 23 '16 at 8:11
  • Well, the chat is deleted. I downvoted this "answer" as it doesn't answer my question. – Smit Johnth Dec 2 '16 at 19:04

I don't think the old ciphersuites are too much of a worry in themselves as your server should not ever negotiate them. What is more of a worry is that they indicate that the SSL/TLS stack in the client in general is very old.

In general with ssl/tls the client authenticates the server but the server does not authenticate the client at a tls level, (higher level protocols will often authenticate the client using their own mechanisms but that authentication doesn't provide MITM protection).

So the type of problems you need to worry about are issues that let the attacker convince the client that they are the server and hence allow the attacker to MITM the connection.

One method of doing that is to attack the certificate hash algorithm. There are two variants of this.

If the attacker has a feasible preimage attack against the cerficate then they can easilly use to make themselves a trusted certificate for any hostname they like. However afaict even for very old hash functions like MD2 preimage attacks are still computationally infesible.

The other method is to exploit a collision attack to create a pair of certificates one of which is a normal end entity cert for a domain the attacker legitimately owns and is signed by a trusted CA. The other certificate is an intermediate CA certificate. The two certificates are constructed to have the same hash which allows the signature to be transplanted. However to pull this off the attacker needs to find a CA that still uses the vulnerable hash function and that operates predictablly enough that the collision attack can succeed. A group of University researchers did manage to pull this attack off with MD5 but the CA they used changed thier practices immediately afterwards.

Another option is to go after the RSA keys themselves. If you can find a CA certificate that the client will trust (either directly as a root certificate or indirectly as an intermediate signed by one of the clients root certificates) with a sufficiently short RSA key then you can factor the modulus and get the private key. Then you can use it to sign certificates for whatever hostname you like. 512 bit RSA is easilly factored but i'm not sure if it was ever used on CA certificates (it was used on end entity certificates but those tend to have shorter expiry and are only useful for impersonating one site) 1024 bit RSA was widely used on root certificates and is probablly crackable with NSA-level resources but is almost certainly still out of the reach of common criminals.

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.