(Yes, MD5 is safe for this use)
With tcp MD5 your connection is even secured against an active attacker who can sniff. They can't inject, or even RST the connection. Even if they can sniff and spoof everything.
Sure, it just begs the question: why in the world would you still try to find nails for the hammer called MD5 when (according to Wikipedia) cryptographers recommended upgrading to SHA-1 in 1996 already? This project's first commit was well, well beyond the deprecation of MD5. It's a bit safer than but also not entirely unlike putting a Windows 7 on the internet just because there are no known exploits in an up-to-date 7 system currently.
TCP MD5 has been used for decades to protect BGP, and exactly because it's still safe there's been no push to add TCP-AO.
And it inherently requires kernel support, because it's part of TCP, not the application.
I would have preferred TCP-AO (RFC5925), not TCP MD5 (RFC2385), but the former is not supported anywhere.
See more at https://blog.habets.se/2019/11/TCP-MD5.html
(I should have added this link in my comment, but I forgot I wrote a blog post on the topic)
Despite SHA1 today and MD5 for even longer being “insecure” for some use cases there are plenty of usecases for which they are still secure and will remain so.
The reason for a wide deprecation is that most people can’t evaluate a hash function or an encryption algorithm in context well so it’s easier to say simply don’t use X.
RSA is also crap for many things and it’s slowly but surely being deprecated but it doesn’t mean it’s completely broken for every usecase.
Just to be clear I’m not stating that MD5 is necessarily safe for the usecase the GP states it is.
If confidentiality isn’t a factor (since any hush function that is fast m enough to brute force isn’t going to be particularly secure) and if integrity cannot be compromised through collisions then the hash function is safe for this usecase.
Why use MD5? It’s relatively easy to implement securely m, there are a lot of safe implementations and it’s fast.
This is why CRC32 is still used today also.
I thought this should be clear from the fact that it protects against RST packets. Nothing on an application layer can do that.
I wish I could edit that comment because while I expected people to go "oh, I didn't know TCP had that!", multiple commenters seem to have not read past "MD5" and assumed that this is pure application-level.
There's no reason to choose MD5 over SHA-1. It's less secure and slower and there's plenty of free implementations of SHA-1.
Ideally you'd use SHA-256, because of (smaller) security concerns with SHA-1, but it is a small touch slower than MD5.
% for i in md5 sha1 sha256 sha512; do echo -n "$i: "; time ${i}sum test.bin > /dev/null ; done
md5: ${i}sum test.bin > /dev/null 1.37s user 0.13s system 99% cpu 1.501 total
sha1: ${i}sum test.bin > /dev/null 1.84s user 0.12s system 99% cpu 1.952 total
sha256: ${i}sum test.bin > /dev/null 4.43s user 0.16s system 99% cpu 4.593 total
sha512: ${i}sum test.bin > /dev/null 2.69s user 0.12s system 99% cpu 2.810 total
- Lots of modern x86 machines with SHA-NI that were typically 50-300% faster than MD5
- Older Intel machines, where SHA1 was generally slightly faster, with one or two exceptions where the reverse was true.
- ARM machines with good SIMD/NEON where the NEON implementation of SHA1 was 30-40% faster than MD5.
- Embedded ARM machines with bad SIMD/NEON where it was pretty much a tie.
- A few ARM machines-- most notably Broadcom chipsets in the Raspberry Pi, where MD5 wins big a large margin.
- Embedded MIPS 24k, where MD5 won by 33%.
Then I found http://bench.cr.yp.to/results-hash.html , which bears out what I'd measured.
In any case, I don't think "speed" is any reason to select MD5, unless maybe if you're on MIPS 24k.
SHA512 is expected to be faster than SHA256 on modern 64 bit architectures due to fewer rounds per byte.
What TCP stacks support TCP-AO? They do support TCP-MD5. That's why.
Kernel needs support. This cannot be done in user space.
Or in the case of a PNI between two ISPs over their own cross connect, you absolutely want to have a mutual level of trust and cooperation between the BGP peers on both sides of the session.
And then other more modern methods of verifying that the IP blocks you're seeing from some other AS are legit, like verifying their RPKI signatures, IRR entries, etc.
I mean it's the only auth that exists for BGP, so why would you not want it?
You use what actually exists. It's orders of magnitude better than portknocking BS.
Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.
But also, like I said in my blog post (https://blog.habets.se/2019/11/TCP-MD5.html) this isn't just about targeted attacks, but this also hides from things like Shodan, which connects to all your ports and records your headers.
It helps with wide-scale scanning and wide exploitation. Security isn't a yes/no, and getting out these databases without restricting by IP address isn't without actual security value.
E.g. if you do this then next time there's an OpenSSH bug, you won't be in Shodan and other more secret scanning databases to be picked off right away.
Port knocking is just plain overengineered silliness. If plaintext password to unlock another port is what you want, set up a UDP server. "Connecting to random ports" is just fooling yourself about what you're doing.
TCP MD5 least has the benefit that it prevents any kind of shenanigans happening to your connection.
fail2ban, agreed. The value fail2ban adds is keeping your logs more quiet.
nonstandard SSH ports, agreed. Especially after everyone and their dog scans all ports on the whole internet now anyway.
With TCP MD5 you don't even have to consider SYNfloods or SYNcookies. And because only people with the MD5 secret can even connect, it becomes an early tripwire if someone does have the password. Currently if you have an OpenSSH open to the world you should expect your logs to be spamming 24/7, which makes smarter attacks not stick out.
Frankly, given the option I would prefer to not even have port 22 advertise to the world exactly which OpenSSH and OS I use. Not because of security through obscurity, but just to make it slightly harder, and thus harder to get in without tripping any of the tripwires.
Then there's also people who add 6 digit OTP as a second factor. Those are pretty brute-forcable by default, so you can actually do online brute force of a user's password still. Just slower. (OpenSSH has a ratelimit, but I've gotten around TOTP this way). With a system wide good secret this can prevent brute forcing even in the presence of bad user passwords.
But if you've already decided that security is either yes or no, and that OpenSSH is marked "yes secure, and therefore can be open to the world forever, bravely taunting any attacker saying 'this far, no further'", then there's nothing I can say to convince you.
But also not everything on the Internet is (Open)SSH.