Resend encrypted REST GET request to eavesdrop data

Question

Bob makes a HTTPS GET request to view his personal info on a dating site via a RESTFul web service. He supplies his api key,secret,timestamp and signature to prove that the request came from him. All the header data are encrypted so Bob is very sure no one can eavesdrop on this request.

Alice is a network administrator. She immediately noticed an encrypted request via her Wireshark tool and tries to view the content, but she only sees the encrypted content, the source IP and destination IP.

If Alice submits the exact same encrypted request via her computer (a few seconds after Bob), will she be able to see Bob's personal info?

Rest should be stateless. A CSRF prevention implementation would require a session token right? — Neil Yoga Crypto, Sep 05 '16 at 01:14
Yes, but it can be done different way. Imo the point is to preventing a replay attack — happy, Sep 05 '16 at 01:17
There is software firewall too, not everything has to be done in the script — happy, Sep 05 '16 at 01:18
Guys, TLS is replay safe. The TLS will be rejected by the TLS implementation. Noone will ever see a CSRF token since the request doesn't make it to the application layer .... — kaidentity, Oct 05 '16 at 10:00

score 1 · Accepted Answer · edited Mar 17 '17 at 10:46

1

Alice's replay request will fail on TLS level because TLS is immune against replay attacks (e.g. look here).

And even if it wasn't: Why the hell would Alice be able to decrypt the response from the server? It would be encrypted by the TLS session key. Just replaying something doesn't give you access to the session key...

edited Mar 17 '17 at 10:46

Community

1

answered Oct 05 '16 at 10:03

kaidentity

2,634
13
30

score 0 · Answer 2 · edited Oct 07 '21 at 07:59

At the start of each TLS session, both the server and the client generate a fixed number of random bytes (using a cryptographically secure RNG) and exchange them; they are called "client random" and "server random". One instance where this random data is used is when calculating the keys for symmetric encryption and authentication, see RFC 5246, section 6.3.

So if Alice simply replays the packets she captured, the server will consider this a new TLS session and generate a fresh server random that is almost surely distinct from the one used during Bob's session, and therefore use fresh symmetric encryption and MAC keys. The ciphertext sent by Alice will fail the MAC check and will be ignored by the server.

What you describe about the "MAC check" is also called "replay prevention". — kaidentity, Oct 05 '16 at 10:05

Resend encrypted REST GET request to eavesdrop data

2 Answers2