Preventing HTTPS Replay Attacks

Question

I've read here that HTTPS replay attacks aren't possible from MITM attacks but I want to be sure that it's not saying that HTTPS replay attacks aren't possible at all. I want to know if I have to implement my own obscure method for temporarily preventing the inevitable or if something like this already exists.

Suppose the attacker is the client. They have access to the client and are communicating with the server legitimately, analyzing the traffic. Therefore the attacker has access to the client's private key (or at least, the ability to replicate its generation). What's stopping them from just replaying the traffic through a fake client after sniffing the payload before it's encrypted? That is to say, running it through the client to encrypt it then send it themselves.

My client relies on the hardware information from the system to validate one-user-per-subscription and want to know what all of the weak points are for this system. Spoofing it seems really easy if they generate it normally once then spoof it every time after.

Answer 1

Your attacker can replicate any HTTP message and is indistinguishable from a legitimate client.

In this case, the replay defense has to be at the HTTP application layer (the web server or web application needs explicit code to prevent replays). Something like POE (POST Once Exactly) can help prevent a literal re-POST.

Note, however, that an attacker in this position likely also gets the nonces used for POE, so its unlikely a reliable defense against a concerted attacker in this position is possible or practical to fully defend against.

You should consider upgrading your one-per-user subscription shared secret to be based on public key cryptography and digital signatures. The initial subscription would generate an asymmetric key pair, store the private key, and submit the public key to the server and thereafter the server would submit challenges the client must sign with their private key and the server would validate the signature against the public key on file. This is not something I would recommend inventing, but instead looking at options for using existing digital signature libraries or even the secure enclave on the client to perform if its available to your client app. The private key should never be exchanged so the attacker should not have access without persistent total compromise of the client.

Answer 2

A replay attack at the TLS level (and thus HTTPS) as you imagine would mean that some attacker could simply replay a captured TLS session or inject a previously captured packet into an existing TLS session.

None of this is possible: Replaying a full session cannot be done since the master_secret as the base for encryption includes both client and server random data, i.e. the master_secret does not depend on the client alone. Injecting a previously sniffed record is not possible since each record has a sequence number and simply replaying a record will be detected due to an old sequence number. Changing the sequence number will not work either since it is protected against manipulation like the rest of the record.

But if an attacker has access to the plain (unencrypted) request he can simply replay this request within some new TLS session. This would be HTTP level replay though and not TLS or HTTPS level replay.

My client relies on the hardware information from the system to validate one-user-per-subscription ...

Based on this your client relies on the client not cheating in the first place - which is contrary to the attack vector you describe. But a client could do cheating: for example the client could run in some emulated environment which can be cloned and exhibit the same behavior in another system.

The client could also partially reverse engineer or hook your app to capture and modify the plain request before it gets send. This way it can capture the plain (unencrypted) request on one system and make sure that the other system uses the same request.