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.
Cryptographers usually recommend switching to function X for usecase Y.
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.
Okay but that doesn't explain why it makes sense to still pick an algorithm that more and more holes are being found in when every library already ships more modern alternatives. It would be better to remove the old MD5 code so we can't accidentally have someone use it for use-cases for which it isn't secure, but if people are pedantic about "but for this case I can still use it! Let me just do that!" that will just never happen and we're stuck with MD5 indefinitely.
I’m not going to evaluate if MD5 is safe for “tcpauth” even if I was competent enough to do so.
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.
No, "why use MD5" is because MD5 is the only one supported by kernels. And it has to be supported by kernels in order to allow any realistic use of a BGP daemon.
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.
% 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
Surprisingly, SHA256 is much slower than SHA512 here.
a very small percentage of ISPs at some major IX points still want MD5 auth on BGP sessions across the fabric. Usually a moot point these days since the IX operator should have solid, reliable documentation of exactly what switch port and fiber patch panel assignment goes to which cage/suite/cabinet and ISP.
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.
Citation needed: I've maintained direct sessions over the fabric (not via route servers) between my AS and peers' ASes, with over a hundred ISPs, at some of the world's largest IXes. Out of those more than a hundred, maybe 3 used MD5. We also have a lot of PNIs direct with other carriers with POPs in the same building. Sorry I obviously can't provide a copy/paste of the junos config showing all the peers.
Not a joke. I'm suspecting you don't understand that this is using a kernel-level feature, so if you think the joke is MD5, then please add rfc5925 to every OS so that I can switch to a better algorithm.
You use what actually exists. It's orders of magnitude better than portknocking BS.
Deploying a half-assed encrypted transport in front of a full-assed encrypted transport because you're afraid you might not know how to configure the full-assed encrypted transport is pretty funny, which is why I thought it might be a joke.
Port knocking, fail2ban, nonstandard SSH ports, all of that stuff is theater.
Well, sorta. TCP MD5 hasn't had preauth exploits. OpenSSH has.
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.
How long ago was the last viable standard-configuration OpenSSH pre-auth vulnerability? Was it within the last decade? If it's the Debian RNG vulnerability --- a platform vulnerability, not an OpenSSH vulnerability --- how much further back do you have to go to find the next one?
Sure, it was a while ago. But there are less severe bugs too. Fact remains though that something more complex is more likely to have a bug.
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.
Oh, another aspect to this: OpenSSH may not have a bug, but maybe you need to interface using a PAM module to a radius or LDAP server. Suddenly the trust weakens.
(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.