[?] luci-app-wireguard QR Code shows Private Key

lleachii · June 2, 2019, 5:40pm

In the past weeks since the QR Code function of luci-app-wireguard was added, I've seen different interpretations of what the QR function should be used for.

Some think they should be able to scan and get a config for a new peer (although this would be odd, since at least mobile apps, they generate a keypair themselves in the same way the wg command would work on OpenWrt)
Others think they should be able to scan for the Public Key of the OpenWrt interface, for easy pasting into e.g. a mobile device - this was my belief...

Upon testing myself, the QR Code actually exposes the Private Key and other settings (IP, peers, etc.), as if providing a method to backup the config.

Are there any thoughts on this function, and it's usefulness to expose the Private Key and configs in such a quick manner to copy?

It doesn't seem useful for - what I can see thus far as it's only useful purpose...to make a QR Code of the Public key.

tectonic · June 2, 2019, 5:58pm

Personally, this is what I do / expect. It's also the functionality that's provided by algo.

I create a config for each peer by hand; e.g.:

[Interface]
Address = 192.168.99.2
PrivateKey = <client's privatekey>
ListenPort = 21841

[Peer]
PublicKey = <server's publickey>
Endpoint = <server's ip>:51820
AllowedIPs = 0.0.0.0/0, ::/0

and then create the QR code from this config:

qrencode -t ansiutf8 -o myNewPeer.png -t PNG < myNewPeer.conf

If I need to distribute the configs and/or QR codes, I always encrypt before sharing

dibdot · June 2, 2019, 6:25pm

It's intended to transfer an existing peer config from router to mobile phone, e.g. via Android App ("Create from QR Code"). And of course the private key is part of that config ... and will be not exposed by the Android App. I don't see an issue here.

Original Feature Request: https://github.com/openwrt/luci/issues/2180
Corresponding PR: https://github.com/openwrt/luci/pull/2195

ariznaf · June 2, 2019, 6:48pm

I don't think that is the use of the QR code. If you have provided the public key of the router to the app and its address you don't need the QR code at all.

The QR code is to be able to provide the publick key and other infor to another device, a router or another device.

The router should be able to do the same: provide another device with its public key, address and port, the same way the mobile app doesn..

It should not be used as backup and it should not include the router private key.
If you want to backup the config, backup de config file.

Any way the whole method is cumbersome to be able to provide a tunnecl connection to third parties, like your kids of family.

Some one has to provide its public key to the other part and generate the codes.

You cannot have dynamic IP address, so yo have to configure an IP for each possible device.

Of course not a fault of openWrt or luci-app-openWrt. May be in future versions of WireGuard they provide alternative methods of providing connection.

lleachii · June 2, 2019, 8:03pm

Why would one have the private key of a peer?
Nontheless, I verified that the displayed key is the OpenWrt Private key.

To be clear, are you saying that this feature's purpose - is for creating an entire peer config on OpenWrt to test/use, then completely (and easilly) transfer it to a phone at a later time?

HectoPascal · June 2, 2019, 11:39pm

The issue is it doesn't transfer the peer config. It transfers the server config. That's a massive security flaw.
i can only talk for the scenario without defined peers (on server side) though because if you add a peer the QR Code won't get accepted anymore on Android. The QR Code generation is buggy as hell at the moment.

greybeard · June 3, 2019, 12:55am

+!. The private key of the server is exactly that, private. Whilst it can be used in the peer device, good practice would be to have unique private keys for each peer. (for the same reason as you don't share private keys for ssh).
If wanted to create a 'key pair package(private/public) for use in a peer as a helpful management tool then that is different. But the openwrt private key shouldn't be used on the peer.
ie
openwrt (openwrt private key only) -> share openwrt public key for use on peer.
peer (peer private key only) -> share peer private key for use on openwrt

This way peer has confidence that it is talking to openwrt and openwrt has confidence that is is talking to the peer.

Every peer has a unique address as well.

This page on the wireguard web site sums it up.
cryptokey-routing

lleachii · June 3, 2019, 1:18am

I can verify that the QR Code was an exact copy of the server and peers of the OpenWrt. The QR Code is only useful for transferring the entire config of the router to another device. It had no peer Private Keys - only the OpenWrt's.

The code only recreates the OpenWrt config on another device. It cannot be used to make a new peer to connect to the OpenWrt.

greybeard · June 3, 2019, 2:15am

There is a philosophical issue that would need to be decided regarding any peer private key.

The private key should only be known on the receive side of the connection. ie openwrt should see it's private key and the public key of any peer. The peer should only see it's private key and the public key of any connecting host. And neither openwrt nor the peer should see the other devices private key.
That said, you could create a private/public key pair for a peer and template ip addresses and then make the QR code for a peer on openwrt. It's assuming that the openwrt is secure.
At the least a QR code for as much of the peer config as possible would be nice and/or a luci interface to create private/public keys so you can cut and paste from the gui rather than the command line.

ariznaf · June 3, 2019, 8:10am

A private key shold remain private, and not transmites to any other device.

The QR code should not include the private key of the server, as that breaks security. If it includes it, it is a security problem, people is not going to be aware of it.

If you want a backup copy of the openwrt config, a QR is not the best way, you backup the config file, and you know that a backup should remain in a secure place, not accesible to others.

The QR in wireguard is used in the ooficial app and other apps to make it easier to configure, and transmit the public key and peer config of a device, not its private key.

lleachii · June 3, 2019, 11:42am

Have you actually tried the app?

Have you looked at the QR code it makes for your interface?

ariznaf · June 3, 2019, 1:15pm

I cannot try the qr code interface as it is not present in stable release.

But I don't need to try it to know that if it encodes the private key of the sever, that is a security issue.

I would like to send a QR code or config file to my kids, or my family, but I don't want to send them the private key of my sever, which should remain private.

I don't know if it is true or not, that the QR code contains the private key, I only said that it should not.
And nobody has said that it does not store the private key, and you seem to confirm that it stores al, the server config.

lleachii · June 3, 2019, 2:56pm

I only find the behavior of this app useful for:

backing up an OpenWrt-based Wireguard interface; and
transferring a VPN account from a provider - off the OpenWrt router, into phone

While I would think the most common usages would be:

a user wanting a random keypair generated for a mobile device
the Public Key of the OpenWrt interface - for easy pasting into a mobile device

Demonstration:

An OpenWrt

Private Key: 8NpPIJl5Po6QroxrQNk6clXzHLCb76OCVmQhEayhhUc=
Port: 7506
IP Address: 192.0.2.1/24

A Phone

Public Key: zzcxqEweblND7nvGlpw4DaxTpIvnX9sMdsb/91/gcyg=
IP Address: 192.0.2.2/32

This produces the following UCI-based OpenWrt config at /etc/config/network:

config interface 'forumwg'                                                 
	option proto 'wireguard'
	option private_key '8NpPIJl5Po6QroxrQNk6clXzHLCb76OCVmQhEayhhUc='
	option listen_port '7506'
	list addresses '192.0.2.1/24'

config wireguard_forumwg
	option public_key 'zzcxqEweblND7nvGlpw4DaxTpIvnX9sMdsb/91/gcyg='
	list allowed_ips '192.0.2.2/32'

I then run:

opkg update
opkg install qrencode

Screenshot%20from%202019-06-03%2010-40-05

Screenshot%20from%202019-06-03%2010-40-41

As you can see, the OpenWrt's config... So what occurs when a peer is connected?

How does this data help one create a new Wireguard peer for connection to the OpenWrt device?
NOTICE, I NEVER SHOWED YOU THE PRIVATE KEY OF THE PHONE!

ariznaf · June 3, 2019, 3:09pm

The problem is not showing the private key of the phone, the problem is showing the private key of the router to third parties, when you send them the qr Codd to facilitate them the config of the tunnel from their devices.

There should not be any private key in the qr code, the private key should never go outside any device.

As the adiminidtrator of the router, my kid or familiar shoulx provide me the public key of their device, I configure a peer in my router and assign a ip, and I send the config file or qr code to let their app generate a peer to connect tomy router,

They do not need my private key and i don't need their private key, none of us should know the private key of the other.

lleachii · June 3, 2019, 3:10pm

Exactly!

This is what I assume the code should be:

download

I.E. The Public Key

lleachii · June 3, 2019, 4:13pm

It seems that from description of others; and PMs from a few persons, the intended and programmed use of the QR Code in luci-app-wireguard is the following.

Hypothetical scenario:

You are given an account from a commercial VPN provider (e.g. TunSafe or Azire)
You setup the account on your OpenWrt for temporary/testing purposes only
The VPN account works!
You then wish to transfer the account to your phone for everyday use
You then delete the interface from OpenWrt

This is the only scenario where the QR Code in luci-app-wireguard is useful.
I don't understand why a user would setup an account on the OpenWrt, if the intended use is for a mobile device???

lleachii · June 4, 2019, 8:44pm

All,

From @dibdot:

OK, see PR https://github.com/openwrt/luci/pull/2749 ... feel free to set a back reference in the thread

It will add informative text describing the intended use case; and warnings to the QR Code section when the proper information is not available to generate the code:

wg_info2

HectoPascal · June 5, 2019, 12:42am

I get the same error with missing 'endpoint' when a peer is defined. This value is optional so the error is not correct.

But as i stated on github already i think this implementation is not correct. If the QR Code is capable of transferring 3 keys (a new keypair and the servers public key) we have all we need to distribute and set two independent keypairs as its intended.

lleachii · June 11, 2019, 4:40pm

It may be beneficial (for the future) if the QR Code is only available for Interfaces configured using the two-peer-only option, for example:

ip link add dev wg0 type wireguard
ip address add dev wg0 192.168.2.1 peer 192.168.2.2

or

config interface 'wg0'
	option proto 'wireguard'
	option private_key 'XXXXXXXXXXX='
	option addresses '192.168.2.1'
	option peeraddr '192.168.2.2'

There's a PR to implement a two-peer-only setup, perhaps the app should be changed accordingly, if accepted: https://github.com/openwrt/openwrt/pull/1979

seandex · June 15, 2019, 1:25pm

Here is your define, as define has no rules which is fine. i respect everyone's philosophy regardless it's not true.

Language failure, this language does not even follow its pre-define and rules by itself.

Error code showing without supportive reasons, or references. and has no proof on "security issue".

I think you should go to support topic about luci-app-sshd and complain about private keys.

Where is your family going to scan the QR code? What really are you trying to do?
Let's say we are in the movie called "Hackers 101" I print this QR code on a letter paper, and paste the paper right next to my house numbers outside,
A hacker called 'Fernando' in a suv scanned that code. so what will be happened next? what if he really established a tunnel in a non-sense movie script. what will be the next step for a hacker to do? brute-force internal computers? packet sniffing internal traffics? probably looking at 'htop' on the laptop monitor and rubbing his jaw with a thumb and a index finger and the screen fades out.

ok admin, so how are your family smartphone going to deliver the key to openwrt or you before your own topology in perfectly secured openwrt router based on your security concerns? how's c2c works and nat-traversal by knowing each other? there are rules exist in the different ways.

NAT is not a Netgear Hub-Switch.