Any MITM tool for forcing weak SSL cipher suite?

Question

Let's say I'm trying to reverse engineering communctions between an Android app and a web server uing HTTPS.

At beginning, I tried to do MITM using webmitm and a fake cert. But the app failed to start because the fake cert used by webmitm is not trusted by the app.(Let's say the app has its own way to decide what cert it trusts and I cannot import the fake cert to Android as trusted cert)

So I come to another approach. I noticed that both the app and web server support weak ciphers(e.g. TLS_RSA_EXPORT_WITH_RC4_40_MD5 ). So I'm thinking, instead of using a fake cert as a bridge, is there any mitm tool which only change the Client Hello packet to enforce weak ciphers, and forward the server's original cert without decryption or encrypting anything in the middle.

In another word, when the app sends "Hello Webserver, I support the following cipher suites: XXX YYY ZZZ. Please choose one your support" , the mitm tool intercepts this packet, and change it to "Hello Webserver, I only support TLS_RSA_EXPORT_WITH_RC4_40_MD5" and forward it to the web server. Since both of them suppor this cipher suite, they are going to use this for the rest of the communication. And the mitm tool just forward everything between them, and record all the packets. And then I try to decrypt the recorded packets offline.

Any idea?

Answer 1

What you are trying to do will be... difficult. The main point is that at the end of the handshake, client and server send each other Finished messages, under the protection of the just-negotiated algorithms and keys; and the contents of these messages are hash values computed over all the previous handshake messages, including the ClientHello and ServerHello. What this amounts to is that if the client and the server do not see the same ClientHello (because you altered it in transit), then the Finished message contents will not match and the handshake will fail.

In order to successfully alter the ClientHello, then you must break the encryption right away, and not offline: you have to recover the encryption keys at the end of the handshake and before forwarding the Finished messages, so that you may adjust the contents.

40-bit encryption is within the realm of the technologically feasible. A first problem is that with export cipher suite, the 40-bit key is only an intermediate key; the final key is expanded to 128 bits. Brute force is still feasible, but precomputated tables (rainbow tables...) are not. A bigger issue is that since you must adjust the contents of the Finished messages, you must not only break the encryption keys, but also the MAC keys -- and these ones are big (128 bits).

Your only remaining option, then, is to break the RSA key used by the server. Theoretically, with TLS_RSA_EXPORT_WITH_RC4_40_MD5, the server's public key should have size 512 bits at most. A 512-bit RSA Key is breakable, but that's still quite an endeavour for an amateur. It has been reported that a single desktop PC can achieve it in two months; more recently, some guy factored a 512-bit RSA key for 75 dollars in three days (75 dollars worth of rented CPU). If you try yourself a connection to the server with a client (e.g. OpenSSL's command-line tool: openssl s_client) which claims to support only TLS_RSA_EXPORT_WITH_RC4_40_MD5, you will see the certificate sent by the server. If the server's public key is 512-bit only, then you can envision to break it. Note, though, that it is entirely possible that the server does not honour the restriction to 512-bit keys for "export ciphers" (since the said export regulations have been lifted more than a decade ago).

If you can break the server's RSA key, then you can impersonate the server, i.e. use the server's own certificate (necessarily valid in the eyes of the client) for your Man-in-the-Middle attack. If you cannot, and there is no way for you to build a fake certificate that the client will accept, then I don't see any way to achieve what you want to do.