~eduvpn/server#86: 
put secrets stored in /var/lib/vpn-user-portal in DB

now secrets are stored on the FS, it might make it much easier to support multi-portal systems if those are stored in the DB. Also easier for backups.

They probably need to be encrypted if (remote) database is used...

We are talking about:

  • /etc/vpn-user-portal/keys/ca/ca.key
  • /etc/vpn-user-portal/keys/ca/ca.crt
  • /etc/vpn-user-portal/keys/oauth.key
  • /etc/vpn-user-portal/keys/node.${n}.key
  • /var/lib/vpn-user-portal/keys/wireguard.${n}.key
  • /var/lib/vpn-user-portal/keys/tls-crypt.${profile_id}.key
Status
REPORTED
Submitter
~fkooman
Assigned to
No-one
Submitted
a month ago
Updated
a month ago
Labels
v3.x

~fkooman a month ago

In order for the CA key to be used in vpn-ca it needs to be either first written to a file, or e.g. passed as through environment variable... We need to modify vpn-ca for this as well to support that.

~fkooman a month ago

not only does vpn-ca need to support reading CA from env, it should probably also work without writing / reading anything from disk. This is a bit more tricky, especially when you want to have cert and key separately. You'd need to pipe stuff, e.g.

$ vpn-ca -gen-key > ca.pem
$ CA_KEY=$(cat ca.pem) | vpn-ca -ca -name "VPN CA" >>ca.pem
$ vpn-ca -gen-key > server.pem
$ CA=$(cat ca.pem) | vpn-ca -server -name foo.example.org >>server.pem

That's quite cumbersome! Especially the self signed case which is weird using this pattern.

~fkooman a month ago*

We may simply get rid of the distinction between key/crt file and store everything in 1 file, i.e. both the cert and private key concatenated. Then it is up to the 'consumer' of vpn-ca output to deal with that.

~fkooman a month ago

Perhaps we make this WAY too complicated and we should only store the "dynamic" keys in the database, i.e. the files in /var/lib/vpn-user-portal. The rest will never change, or only change if there is a serious problem.

~fkooman a month ago

The rest will never change, or only change if there is a serious problem.

The main thing is that these keys are generated on the node(s). So if a profile is added in the config with OpenVPN support, a new tls-crypt key will be generated and registered at the portal(s) and thus needs to be synced as well. It would be neat to only have the need to sync /etc/vpn-user-portal between portals and not /var/lib/vpn-user-portal.

~fkooman a month ago

This feature by itself is maybe not enough to modify the database. If we could also make other stuff part of the DB it might start to make sense, for example configure profiles as well though the DB. Then we can easily modify config through the web for example, or write a script to dynamically create a profile, etc...

~fkooman a month ago*

tls-crypt-default.key|#
...
...

wireguard.0.public.key|++h9x4ws2mGS3+dza3CPPlB9cSGF2Q7SHGp8v8neGz4=

~samer_m a month ago*

one way to handle vpn-ca, is to generate passphrase in environment variable to encrypt the files being generated . once the generation process is completed, the pass phrase can be used to decrypt the files during the db insert.

~fkooman a month ago

one way to handle vpn-ca, is to generate passphrase in environment variable to encrypt the files being generated . once the generation process is completed, the pass phrase can be used to decrypt the files during the db insert.

The encryption is actually the easy part...

The hard part is deciding whether we want this at all, whether we want to have more configuration stuff stored in the database, whether we even want the CA in the database for which I'm currently leaning towards "no", because it never every changes during the lifetime of the server, i.e. it is "static". But if we'd go "database all the way for everything", then it may make sense again.

~samer_m a month ago

moving config to the database will make it robust. as start to be able to view all configs (specially with multi-portal in mind). having portal, profile, nodes config in database, implies having their respective keys along. CA as master key, if stored in database, it think it would require level of security, in-terms of storage-API between all portals and DB instead of direct DB access. portal will have to use portal{x}.key.

Register here or Log in to comment, or comment via email.