Page MenuHomePhabricator

Wireguard keyPair per interface
Closed, ResolvedPublicFEATURE REQUEST

Description

Hello,

I was wondering why there is only one key pair for the whole system. In a normal wireguard config there is one private key per interface. I think it's always best to stay as close to spec as possible. I would greatly appreciate the feature and because of that I would gladly help to implement it. I looked at the concerning files and don't think the needed changes would be huge or even have a big impact on normal operations.

Thanks in advance
Jonas

Details

Difficulty level
Easy (less than an hour)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

jonaswre created this object in space S1 VyOS Public.
afics added a subscriber: afics.Aug 9 2019, 10:18 AM

I second this, I would like to be able to setup different keys for multiple wireguard interfaces too.

Best Regards,
afics

pasik added a subscriber: pasik.Aug 9 2019, 10:28 AM
jonaswre updated the task description. (Show Details)Aug 9 2019, 10:34 AM
runar added a subscriber: runar.Aug 9 2019, 12:01 PM

This sounds like a good improvement!

I propose to create a concept "named key-pairs", a key-pair could be used on one or multiple interfaces as the user wish'es. And if the user dont specify a key, a default key is selected for him. Allso when specifying a non-existant key-pair the key-pair could be autogenerated with that name.

hagbard added a subscriber: hagbard.Aug 9 2019, 2:34 PM

I don't think it's a good idea, for several reasons.

@jonaswre Can you please point me to the specs where it recommends to use for each interface it's own private key?

jonaswre added a comment.EditedAug 15 2019, 7:11 AM

@hagbard It's not stated that you MUST use a new private key for each interface. But it states that

[e]ach network interface has a private key [...]
https://www.wireguard.com/#simple-network-interface ⇒ Cryptokey Routing

to set a private key for each interface only makes sense when you are allowed to use different keys for different interfaces. If there would be any withdraw in using multiple keys they would have just omitted the "privateKey" in the config file and set i globally. Since they didn't do that I can't imagine there is one. But I would be interested in learning what withdraws you see that the developers don't see.

Another quote from the papers:

The interface itself has a private key [...]
https://www.wireguard.com/papers/wireguard.pdf ⇒ Cryptokey Routing [p.4]

I think it is a bad idea to use a single key for all tunnels. If you need to change your key on one interface, that would mean disabling all other connections until changed everywhere. And since a normal wireguard install lets you set a private key per interface why shouldn't you be able to do that on vyos?

@runar I would second the "named key-pairs" idea, I had the same in mind. But I wouldn't make auto generation a high priority.

@jonaswre

[e]ach network interface has a private key [...]

Where does it say that you need a different private key for another interface?

The big disadvantage is if you deal with many wireguard users, with multiple interfaces and crypto routing. You will need to identify the correct key for each connection terminate on an interface, the correct port (endpoint as well) and the IP addresses (allowed-ips - both IPv6 and IPv4). That's the first hassle. Now let's imagine one private key might have been compromised, let's say out of 500 interfaces and each interface let's say has 10 peers. With a single pK, a job of a few minutes since you can share the public key with your peer publically.

As I said before I don't see any benefit nor did I find any specification that a new wg interface would need it's own key.

runar added a subscriber: zx2c4.Aug 16 2019, 9:30 AM

Maybe you could comment on this @zx2c4 ?

zx2c4 added a comment.Aug 23 2019, 7:17 AM

Don't use the same private key in two places at the same time. This means it's not a good idea to copy private keys between computers and use it in two places, and probably also means you shouldn't assign the private key to two interfaces on the same computer at the same time, unless you have a really particular and weird setup and know precisely the implications of it. Doesn't sound like that's the case here. So you're probably best doing a private key per interface.

syncer assigned this task to hagbard.Aug 30 2019, 11:47 PM
syncer triaged this task as Normal priority.
syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.

@zx2c4 The private key stays on the system it is generated in a directory only accessible by the user who created it. Now when you create an interface let's say wg01 with 20 peers set up, you hand out 20 time the same public key and to decrypt the incoming traffic you use the single private key. Now, let's say you create an interface wg02, also with 20 peers. Why would it be better to generate a new key pair for wg02 on the same system and use a new private key just for that interface?

hagbard changed the task status from Open to On hold.Sep 4 2019, 10:05 PM
c-po added a subscriber: c-po.Sep 5 2019, 3:51 AM

Why not specify the keys or the key file location via CLI like other VPN implementations do it?

hagbard added a comment.EditedSep 5 2019, 2:44 PM

Well, it's not so much the technical implementation via cli. The private key gets exposed on the computer you generate it, then you transfer it to the vyos box, now you have a duplicate if the origin is not removed. It creates multiple points where you can get the private key. If you have that key and the connection is not secured via pre-shared key, you can decrypt the traffic easily. Or do i See that completely wrong?

jonaswre added a comment.EditedSep 6 2019, 9:16 AM

@hagbard the private key should stay where its generated. But thats not the point. The point @zx2c4 and I are making, is each interface represent a diffrent Identity. There are only some special cases where you would need the same private key on two interface. Useally you would just add all peers that connect with the same publickey to the same interface. You only need a second interface if there is a second identity you want to assume. For example wg01 might be used to connect to your workplace and wg02 to a vpn service. In that case you would want peers in wg01 and wg02 to know you under different identities.

To be honest i dont understand the difficulty just let the user add a keyalias to the interface.

if config[keyalias] is set {
  If keypair_in_folder(keyalias) {
    privatekey = privateKeys[config[keyalias]]
  } else {
    error
} else {
  privatekey = defaultkey
}

nothing brakes, no mandatory changes to the config. Just more functionality. Feels to me like a no brainer.

runar added a comment.Sep 6 2019, 10:23 AM

i agree with allowing this.

I Don't use this myself, but i can se clear benefits of allowing to use custom key's per interface or on a group of interfaces. this is especially important when we are talking about multi-tendancy and vrf is implemented. (a customer with tunnel X should under no means have any posibillity to enter another customers tunnel Y and so on, in these cases the identity will be in the virtual router and not in this physical device. This also makes sense in the case @jonaswre noted in his last post .

another reason for allowing this is the comments from the author of this protocol @zx2c4, and that the protocol itself is made for doing this.

i propose:

  • Creating possibility to generate "named" keys via extending the op-mode generate command
  • add a optional key-pair node to the wg interface and use something like @jonaswre purpose to set the custom key if selected.

Then, if the user specifies a key, he will get that key or else it will set the default key.

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

hagbard changed the task status from On hold to In progress.Sep 6 2019, 8:24 PM
hagbard changed the status of subtask T1648: add cli command 'delete wireguard named-key <key>' from Open to In progress.Sep 10 2019, 5:16 PM
hagbard changed the task status from In progress to Needs testing.Sep 10 2019, 5:32 PM

https://github.com/vyos/vyos-1x/commit/1017c8103f12ebd6db4f250d8a154571fff32db1
Will be available in tomorrows rolling release for testing. Documentation is underway.

hagbard changed the status of subtask T1650: implement wireguard default key removal from Open to In progress.Sep 10 2019, 6:12 PM
hagbard closed this task as Resolved.Sep 12 2019, 3:27 PM

It's not so much the implementation as I wrote before, it just doesn't seem beneficial. It gets implemented anyway, but I try to understand why a user would like to use that. The private key is by the way no identity and also won't interfere with multiple VPN peers if you are using only one pk. On IP:12345 arrives an encrypted packet, it is simply decrypted using your pk. If it works it's given to your kernel netlink interface as far as I recall and routed there, so no verification of the private key anywhere. If it can't be decrypted, it's discarded. If you have multiple wg interfaces, your 'crypto routing' either allows the traffic to the peer or discards it if it doesn't fit, the private key has nothing to do with that, since the public key of your peer is used to encrypt it. Summary, I still cna't see any benefit having that, which doesn't mean that I won't implement it.

Thanks for being quick with the implementation.
Just to clarify the benefit is not really that you could recive traffic over two different Interfaces but sending using two interfaces with sperate identities. Your company may require to change privatekeys frequently while you dont want to change the privatekey for your personal tunnel.

There is no such thing like separate identities. You can either decrypt a package or you can't, that's about it. You basically have to hand out more public keys, you have to maintain more keys. As I mentioned before I only see currently disadvantages so far. However the user can chose what way to go and multiple options are always good. If it helps you, well that's nice to hear.