Hi, On 01-11-17 17:16, Jan Just Keijser wrote: > On 29/10/17 02:49, Jason Haar wrote: >> Best practice would be to routinely rotate secrets, to mitigate >> configuration misuse/loss, etc. >> >> Due to CAs, certificates already support that concept, >> but tls-auth/tls-auth do not. >> >> So wouldn't it be a good idea to allow tls-auth/tls-crypt to contain >> multiple keys, so that the key could be rotated without an outage >> (really like a "major upgrade"). i.e. >> >> 1. replace server key with one containing old + new >> 2. replace client config, replacing old key with new one >> 3. wait weeks/months (probably) until you know all clients are >> reconfigured >> 4. replace server key with just the new one >> 5. rotation is now complete > > someone else asked me a similar question just lately, so you're not the > only one facing this issue. > There is something to be said for such a replacement scheme, BUT to do > this properly would require an OpenVPN protocol change, IMHO; the > problem is that if you allow multiple tls-auth/tls-crypt keys that you > end up unhashing EVERY packet with EVERY key to see if there is a match. > This will kill performance; performance already takes quite a hit with > tls-auth set.
The first byte of an openvpn packet contains an opcode that indicates whether a packet is a control channel packet or a data channel packet. Only control channel packets are affected by tls-auth (or tls-crypt). Data channel performance should be impacted by tls-auth. > The protocol change I'd envisage is to allow the use of one or multiple > static keys for the tls-auth/tls-crypt control channel and that the > client and server then negotiate a temporary key for the data channel. > This temp key is then used to hash and unhash all data channel packets. > This would require the server to be able to quickly distinguish between > hashed control and data channel packets (we could use some sort of [src > ip+port + dst ip+port] matching for this, but this needs more thought. This is basically what the protocol already does, based on the opcode. But we support only *one* tls-auth or tls-crypt key. > The other thing that is required is a way to quickly determine whether > an 'unhashed' packet is correct or not; this may be already present in > current code but it becomes more important if you need to go through > multiple keys. That too is already done: you compute the MAC (HMAC/GMAC) based on the packet contents, then compare your computed tag with the one in the received packet. Coming back to tls-crypt/tls-auth key rotation: the preferred way is what Ilya suggested: add a new openvpn daemon which is using the new key and is running on another port, then migrate your clients to the new server and finally kill the old server. Heiko and Antonio have been working on something that should make this much easier: supporting multiple sockets. Then you could have one daemon accept connections with tls-auth key A on port x and connections with tls-auth key B on port y. That would not require defining a new IP pool, or jumping through hoops to share the same pool over multiple instances. -Steffan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
