Hello, On 2017-11-01 02:08 PM, Steffan Karger wrote: > 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.
Data channel performance should /not/ 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. This sounds like a good transition mechanism for now. > 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. This would make our life so much easier, especially if a single daemon can listen to both UDPv6 and TCPv6! I searched for a ticket about this new feature but couldn't find any so if you have a pointer, I'd appreciate it. Thanks, Regards, Simon ------------------------------------------------------------------------------ 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
