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.
There can only be so many different server config combinations for algorithm, crypto mode, key size etc, so it would be trivial to have a bot try several combinations and nail your setup on the 5th try or whatever, especially if you selected “standard good” setups, which you should if you’re opening a port.
But overall it will weaken the protocol and there is a risk, even if it’s small, of a downgrade attack being discovered. Simply by having options means that it’s possible to trick the server or force it into a more vulnerable state. You can’t get rid of that except by completely removing the options in the first place because there will be literally nothing to downgrade to.
WG just isn’t into that risk. It’s cool if you want it and I won’t say you’re wrong in general because everyone has their preferences and makes trade-offs to set things up the way that they want, but in this particular context it goes against the design principles of WG by introducing complexity and risk, which is not what it’s about. There’s many other options if that’s what you’re looking for, and a lot of them are just as great/secure.
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.
There can only be so many different server config combinations for algorithm, crypto mode, key size etc, so it would be trivial to have a bot try several combinations and nail your setup on the 5th try or whatever, especially if you selected “standard good” setups, which you should if you’re opening a port.
But overall it will weaken the protocol and there is a risk, even if it’s small, of a downgrade attack being discovered. Simply by having options means that it’s possible to trick the server or force it into a more vulnerable state. You can’t get rid of that except by completely removing the options in the first place because there will be literally nothing to downgrade to.
WG just isn’t into that risk. It’s cool if you want it and I won’t say you’re wrong in general because everyone has their preferences and makes trade-offs to set things up the way that they want, but in this particular context it goes against the design principles of WG by introducing complexity and risk, which is not what it’s about. There’s many other options if that’s what you’re looking for, and a lot of them are just as great/secure.