0

I am aware that IP spoofing can be used to carry out SYN flooding attacks, and impersonating servers.

However, I have not been able to find detailed step-by-step attack scenarios: where the attacker (let’s assume is on-path between the client and the server) spoofs the client IP address and attempts a TLS connection with the server. Will the attacker succeed in creating this TLS session, fully impersonating the client? How would the attacker do so, when all response packets will be routed to the client?

Additionally, if the server only accepts connections from that client IP, would this attack still be possible?

Let’s also assume TLS mutual authentication is not used.

1 Answer 1

1

let’s assume is on-path between the client and the server

In this case the attacker can not only spoof the clients IP address for sending but also receive the response packets from the server. This is enough to establish a working TCP connection with bidirectional data exchange. It is thus enough to also establish a TLS session. The server is not able to distinguish between the attacker and the real client at the IP and transport level.

How would the attacker do so, when all response packets will be routed to the client?

If the attacker would not be able to see the response packets then they would have a very hard time to even establish a TCP connection. Even if this could be achieved with correctly guessing the servers initial sequence number, it would be impossible to successfully establish a TLS sessions since this depends on practically impossible to guess data. For example the client would need to correctly guess all server data (which include also random data) in order to correctly compute the Finished message.

In short: attacker on-path succeeds in establishing a TLS connection, attacker off-path not.

Let’s also assume TLS mutual authentication is not used.

Then there is no authentication of the client done. No such check means it is trivial to impersonate the client at TLS level.

7
  • Thanks Steffen! Is the reason the censor is able to control the TLS session, because it suppresses (drops) response packets from being sent to the real client?
    – LeStarfish
    Jun 12 at 15:03
  • Are there prevention strategies that do not require keys or secrets?
    – LeStarfish
    Jun 12 at 15:12
  • @LeStarfish: "Is the reason the censor is able to control the TLS session, because it suppresses (drops) response packets from being sent to the real client?" - I don't think that is related to your question: you question is about spoofing the clients IP address (no original client involved here) while censoring is about preventing the client to access the server, i.e. making sure that packets from client don't reach the server. Jun 12 at 15:28
  • Apologies Steffen, let me reword it slightly! Given the original attack, where the attacker is on-path, would the attacker need to somehow suppress response packets from being sent to the real client, so that the censor can control this TLS session?
    – LeStarfish
    Jun 12 at 15:31
  • @LeStarfish: "prevention strategies that do not require keys or secrets" - If the attacker knows everything (i.e. no secrets or secret keys) then it is indistinguishable from the real client. Jun 12 at 15:32

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.