3 ms·

without a 3-way handshake, wouldn't it be easier to do spoofing? or a man-in-the-middle attack? I think now there are ways to do the 3-way handshake in hardwa

by m463 2y ago

without a 3-way handshake, wouldn't it be easier to do spoofing? or a man-in-the-middle attack? I think now there are ways to do the 3-way handshake in hardware at hardware speeds, and only involve software if the connection has been vetted. This can protect against Denial-Of-Service attacks.

sedatk 2y ago
No and no. IP spoofing was already trivial with 3-way handshake. That's why random TCP sequence numbers were introduced. It's now harder, but for some scenarios, SYN cookies might also be needed.
toast0 2y ago
> I think now there are ways to do the 3-way handshake in hardware at hardware speeds, and only involve software if the connection has been vetted. This can protect against Denial-Of-Service attacks. Do we need hardware for this? Syncookies have provided a software method to handle large volumes of inbound syn without memory restrictions since the late 90s, and it's been in all major platforms except Mac since the late 2000s; Apple forked FreeBSD's tcp months before FreeBSD added syncookies, and last I checked, Apple never pulled them in. My testing is a bit old, but I had more trouble generating line rate syns at 2x10g than handling them several years ago. Are syncookies in software enough at 100g? I'm not sure, but I'd assume so. There's plenty of things to hardware accelerate on a NIC, but syn handling doesn't seem worthwhile IMHO.
tsimionescu 2y ago
There is no significant difference between a two-way handshake and a three-way handshake, given the other parts of the TCP protocol, IF the client is the one that sends the first piece of data after the handshake. It is in fact very common for optimized hosts to send data with the "third part of the handshake", which makes it perfectly equivalent to using a two-way handshake. This happens because the first segment the client sends after the handshake must ACK the server's sequence number, regardless of whether this is "the third part of the handshake" or "the first data packet after a two-way handshake". The problem appears if the server would like to be the first to send data on a new connection. If the server included its data with the SYN-ACK, that would work perfectly well with benign clients, but it would be a vector for DoS attacks. An attacker could send a small packet with a forged source IP, and cause the server to send a large response to the victim's IP. So, the server can't safely send data until it receives an ACK with its secret SEQ number from the client.
yencabulator 2y ago
Nobody's going to bother with new stuff for better spoof protection of TCP handshakes when TLS removes the actual attack and HTTP/3 obsoletes the whole mechanism.

by m463 2y ago

sedatk 2y ago

No and no. IP spoofing was already trivial with 3-way handshake. That's why random TCP sequence numbers were introduced. It's now harder, but for some scenarios, SYN cookies might also be needed.

toast0 2y ago

> I think now there are ways to do the 3-way handshake in hardware at hardware speeds, and only involve software if the connection has been vetted. This can protect against Denial-Of-Service attacks. Do we need hardware for this? Syncookies have provided a software method to handle large volumes of inbound syn without memory restrictions since the late 90s, and it's been in all major platforms except Mac since the late 2000s; Apple forked FreeBSD's tcp months before FreeBSD added syncookies, and last I checked, Apple never pulled them in. My testing is a bit old, but I had more trouble generating line rate syns at 2x10g than handling them several years ago. Are syncookies in software enough at 100g? I'm not sure, but I'd assume so. There's plenty of things to hardware accelerate on a NIC, but syn handling doesn't seem worthwhile IMHO.

tsimionescu 2y ago

There is no significant difference between a two-way handshake and a three-way handshake, given the other parts of the TCP protocol, IF the client is the one that sends the first piece of data after the handshake. It is in fact very common for optimized hosts to send data with the "third part of the handshake", which makes it perfectly equivalent to using a two-way handshake. This happens because the first segment the client sends after the handshake must ACK the server's sequence number, regardless of whether this is "the third part of the handshake" or "the first data packet after a two-way handshake". The problem appears if the server would like to be the first to send data on a new connection. If the server included its data with the SYN-ACK, that would work perfectly well with benign clients, but it would be a vector for DoS attacks. An attacker could send a small packet with a forged source IP, and cause the server to send a large response to the victim's IP. So, the server can't safely send data until it receives an ACK with its secret SEQ number from the client.

yencabulator 2y ago

Nobody's going to bother with new stuff for better spoof protection of TCP handshakes when TLS removes the actual attack and HTTP/3 obsoletes the whole mechanism.