I think your example of SSH is actually the perfect counterpoint to your position!
SSH is versatile but there’s SO many ways to configure it in an insecure way. It’s important for SSH to be versatile because of how many different devices need it, but that also means it’s really easy to have a config that supports crappy ciphers (3DES, RC4, etc), or enabling root login, or pick any other hundred problems that are either due to user misconfigs or just inherent vulnerabilities in a cipher or key exchange method. Its versatility is the core of its weaknesses.
For ssh, there will for sure be bots hunting the internet for vulnerable ssh servers very soon after. Automating the process of getting in
This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you’re using, trying to exploit known weaknesses.
WG was never meant to be a swiss army knife, even though it is also versatile. It’s designed to be fast, secure, and as dummy proof as possible.
giving a choice of crypto, but not adding to the protocol with negotiation.
I’m not sure how you’d achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.
History shows that every cipher mode eventually will be vulnerable to new computing power, I don’t think that’s avoidable. Quantum computing is the next big event on the horizon, which is why quantum resistant ciphers, even old ones that never really got adopted, are getting a lot of attention if they’re deemed to be quantum resistant.
The important thing is that if, not when, it’s reported that the cipher is vulnerable that people harden their networks in other ways until a new cipher mode is implemented. That’s just how it works IMO. Edge security cannot and should not be your only security method anyways.
Overlay VPNs like tailscale and zerotier are interesting to me because you don’t have to open any ports. I’m sure they have their own inherent vulnerabilities also but they don’t make you punch holes in your firewall, which makes them less vulnerable to random attackers trying to scan your network edge.
This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you’re using, trying to exploit known weaknesses.
I know, except they’re only ever trying lame user/password pairs that only an idiot would have on their luggage. Same as on asterisk and the bots trying to exploit decades old exploits on wordpress etc. Regardless of whether the site you host is even remotely like wordpress.
I’m not sure how you’d achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.
Doesn’t need to change the handshake. If the server is mine, and run by me and I decide I was to change say, just the key exchange part of the process. It could be changed without negotiation. I just need to make sure all clients are configured the same way. My point being there wouldn’t be a negotiation. If you try to connect to wireguard on my server, you’d need to have the key exchange setup in the same way, with the same parameters too. Yes, it should be entirely optional and require specific configuration changes on both client and server to achieve. So long as server and client are configured with the same parameters there’s no negotiation to make. The channel can be setup and if the configuration is wrong it just won’t work.
I think your example of SSH is actually the perfect counterpoint to your position!
SSH is versatile but there’s SO many ways to configure it in an insecure way. It’s important for SSH to be versatile because of how many different devices need it, but that also means it’s really easy to have a config that supports crappy ciphers (3DES, RC4, etc), or enabling root login, or pick any other hundred problems that are either due to user misconfigs or just inherent vulnerabilities in a cipher or key exchange method. Its versatility is the core of its weaknesses.
This already happens right now. If you have 22 open, your firewall is getting hammered with bots trying to get in, regardless of what cipher you’re using, trying to exploit known weaknesses.
WG was never meant to be a swiss army knife, even though it is also versatile. It’s designed to be fast, secure, and as dummy proof as possible.
I’m not sure how you’d achieve this. If you have a mechanism to change cipher modes then there would be part of the codebase and handshake that validates settings in some way, which adds potential attack vector.
History shows that every cipher mode eventually will be vulnerable to new computing power, I don’t think that’s avoidable. Quantum computing is the next big event on the horizon, which is why quantum resistant ciphers, even old ones that never really got adopted, are getting a lot of attention if they’re deemed to be quantum resistant.
The important thing is that if, not when, it’s reported that the cipher is vulnerable that people harden their networks in other ways until a new cipher mode is implemented. That’s just how it works IMO. Edge security cannot and should not be your only security method anyways.
Overlay VPNs like tailscale and zerotier are interesting to me because you don’t have to open any ports. I’m sure they have their own inherent vulnerabilities also but they don’t make you punch holes in your firewall, which makes them less vulnerable to random attackers trying to scan your network edge.
I know, except they’re only ever trying lame user/password pairs that only an idiot would have on their luggage. Same as on asterisk and the bots trying to exploit decades old exploits on wordpress etc. Regardless of whether the site you host is even remotely like wordpress.
Doesn’t need to change the handshake. If the server is mine, and run by me and I decide I was to change say, just the key exchange part of the process. It could be changed without negotiation. I just need to make sure all clients are configured the same way. My point being there wouldn’t be a negotiation. If you try to connect to wireguard on my server, you’d need to have the key exchange setup in the same way, with the same parameters too. Yes, it should be entirely optional and require specific configuration changes on both client and server to achieve. So long as server and client are configured with the same parameters there’s no negotiation to make. The channel can be setup and if the configuration is wrong it just won’t work.