5 ms·
I agree with your original point, but none of the stuff after [EDIT] makes much sense to me. "Since TCP acts as a pure transport protocol, it has no per-packet
by xyzzy123 14y ago
I agree with your original point, but none of the stuff after [EDIT] makes much sense to me.
"Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet."
I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption thingy you use. Otherwise, any modern TCP stack should be able to reject blind FINs or RSTs as out-of-sequence.
Generally, the reason people avoid TCP-over-TCP is not DoS, but basically "timer fights", as per: http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html. That said, everything-over SSL is still popular for practical reasons, such as clientless VPNs which need to work around proxies, firewalls etc.
- latitude 14y agoNo, not the MITM. A simple denial of service - I can terminate your TLS-over-TCP connection at will by sending a FIN or RST packet. More generally speaking, I can alter the state of your secure over-TCP connection with an unauthenticated packet. Compare this to ESP where every packet that can potentially alter the state is first authenticated.
- xyzzy123 14y agoBlind, or with some way to observe the sequence numbers? If it's blind (e.g. window guessing) I'm interested in what your techniques are. If it's not blind and you don't have MITM and you don't share a medium, I'm interested in how you're doing that. Challenge: I have the following TCP connection open (oh man I'm really asking for it, but what the heck :) tcp 0 0 192.168.0.10:52352 216.240.155.220:80 ESTABLISHED 16284/nc If you can terminate it with a FIN or an RST in the next hour, I'll post proclaiming your victory. If either the box or my local link drops, we'll call it a draw.
- tcoppi 14y agoThere aren't that many combinations you need to brute force in order for it to work. http://www.blackhatlibrary.net/TCP-RST_Injection http://www.blackhatlibrary.net/TCP-RST_Injection has sample code and an explanation of the attack. EDIT: Just downloaded the sample code and it looks like it won't quite work out of the box, but I'm sure someone with more time could through together something with scapy or similar pretty quickly.
- xyzzy123 14y agoWell I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc
- xyzzy123 14y agoWrite failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!
- 18pfsmt 14y agoSorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?
- xyzzy123 14y agoNah not silly questions at all. I changed the remote port from 80 to 4007 because I figured my web server might get DoS'd :) I have a crappy cable modem which is kind of a "research problem" to root, so I did the netstat on the web server end to get the local port.
- ay 14y ago