1

If someone sniffs the network traffic, can he re-send the exact same encrypted request he sniffed (without tampering it) to the server? For example a request could activate some procedure on the server, so could he re-activate that procedure because he has the request content, even if it was on HTTPS?

BornToCode
  • 9,495
  • 9
  • 66
  • 83
  • http://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing – Tharif May 11 '15 at 08:48
  • @utility - that link says that the data is "a stream of binary data which is encrypted using a private key shared only between you and the server", the question is if someone else sends that same data to the server, will it be decrypted correctly and treated as a valid request (because the server knows the private key that initially encrypted the data)? – BornToCode May 11 '15 at 11:28
  • If your corporation, educational institution, or other Internet connectivity provider installs through group policy or requires you to install an Intermediate Cert on your computer or browser, then they can sniff your traffic:https://www.grc.com/fingerprints.htm – LaJmOn May 11 '15 at 13:24

2 Answers2

2

This is known as a Replay Attack:

A replay attack (also known as playback attack) is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed.

SSL/TLS inherently protects your connection against replay attacks, so anything over HTTPS is protected.

However, if there's a proxy server (possibly transparent) en-route with an SSL certificate trusted by your browser (such as in a corporate environment where root certs signed by the organisation are installed on each computer), then this would be able to replay HTTPS traffic.

SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • Could you please elaborate on how SSL enforces this? Does it use some cryptographic nonce? If so where does it "store" it to determine it was already used once? – BornToCode May 12 '15 at 12:39
  • 1
    From [RFC 4346](http://bit.ly/1zVQyCN): `The master_secret is hashed with the ClientHello.random and ServerHello.random to produce unique data encryption keys and MAC secrets for each connection.To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings.`. It is not stored, but if an attacker replayed the same `ClientHello` message the server would reply with a different random value in `ServerHello` therefore the MAC secret would be different, thus the encryption.. – SilverlightFox May 12 '15 at 12:56
  • ..keys would be different so any attempt at a replay attack would not be understood by the server for the new connection. – SilverlightFox May 12 '15 at 12:57
0

Well the answer depends on who may attack your system:

If the user using your web page or application is the attacker the clear answer is YES, the request data is accessible.

If an local system admin has to considered as potential attacker the answer is YES.

If you are talking about an external attacker which does only have access to the encrypted data packets (e.g. the internet access provider) the answer is NO.

You can always redirect HTTPS traffic through a decrypting proxy which records all request and response data. The client only has to accept/install/trust the certificate of the proxy.

Robert
  • 39,162
  • 17
  • 99
  • 152
  • So what will happen if an attacker will take these encrypted data packets he got access to and simply sends them "as is" to the server? – BornToCode May 12 '15 at 12:00
  • 1
    Nothing. SSLv3/TLS are secured against replay attacks because of used random numbers on server side (32 bit). – Robert May 12 '15 at 14:32