Hacker News new | past | comments | ask | show | jobs | submit login

TCP uses a 32bit sequence number that should be initially seeded to a _securely generated_ random number. As each packet is sent back and forth between endpoints, this number increments by 1. If an adversary wanted to disrupt the connection (denial of service) they could obtain the sequence number and other numbers such as the source and destination ports and spoof some packets pretending to be the real client. It would then become a race between the real and fake clients as to which packet is accepted first. There is usually over 2^40 bits of entropy that an adversary would need to know to hijack a TCP session.

If the adversary is in the middle (MITM) they can read all your traffic and obtain the required entropy in real time. In this scenario, it doesn't matter how much entropy is contained in each packet because the adversary knows that information in real time. Thus the adversary will be able to inject packets to reset/terminate the TCP session, causing a Denial of Service situation.

Cryptographic protocols including SSH and TLS are designed to solve the majority of problems that MITM adversaries can cause. The notable exception is that these protocols rely on unprotected TCP sessions. MITM adversaries are still able to reset/terminate TCP sessions (when SSH/TLS protocols are detected).

IPSec protects not only the information transmitted, but the IP packet headers as well. An Authentication Header (AH)[1] is appended and verified to ensure that packets haven't been tampered with or forged. MITM session reset/termination attacks are therefore no longer possible because forged packets will be ignored.

[1] https://en.wikipedia.org/wiki/IPsec#Authentication_Header




While IPSec would solve the technical problem using it would make blocking even easier unfortunately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: