Encryption in GMT

[ArneTR]

Since the advent of the Authentication Feature (#872) GMT handles now (more?) sensitive data.

This discussion is to evaluate the risk-model we see for the data and the users and what and how we want to encrypt stuff.

1. User Data

This is currently fully unencrypted.

Mainly because we deem that all data not highly sensitive.

The only thing that is temporarily stored is the email until the measurement is over and then some more days in the logs.

Do we want to change that?

2. Token

The token is currently sent as-is. GMT must be hosted on an SSL host to have the token encrypted in transit. Do we want to enforce SSL? On the client as well as on the server?

A weird workaround we have is to have Cloudflare in front of it. So everything is encrypted until Cloudflare and then unencrypted to the server. A bad actor could still intervene ...

Furthermore the token is not encrypted in Memory so it could still be dumped by accident or be leeched if ever the code can be compromised.

The SecureVariable class prevents dumping by accident to some degree.

Do we want to change that?

3. DB Transit

All DB connections are currently done unencrypted. Do we want to change that just for the user token?

Is there any additional benefits given the risk model?

[ribalba]

Very important to have this discussion.

I think that if the machines are compromised things are going to go sidewards anyway. So I wouldn't worry about encrypting data on either side (server or client). That being said, what I would do, is do all communication encrypted. I can totally see someone stealing a token in transit. Also we should give people a hint if they don't use encryption in their connection in the frontend as in the backend so people are aware that this might lead to an issue. I am imaging a simple check on GMT run that warns if the DB is not on an encrypted port. Also the frontend should warn when sending a token over non https. (except if .internal:9142)

I think token auth is totally ok as long as we give people the possibility to get a new token.

[ArneTR]

What I want to bring up to re-discuss the encryption in memory / on the machine:

• Having people on the machine is actually our default scenario. Sure, they are in a rootless and sometimes even isolated docker container, but technically they could not fully compromise a machine but maybe leak memory.

What are your thoughts here?

[ribalba]

If they can leak memory they can also get the DB credentials or the key that is used to encrypt. All the memory encryption I know is done to avoid hardware attacks. I am not aware of an encryption that is per application. I know of "Confidential Computing" but that all looks very cloud centric.

[ArneTR]

Good argument.

I will add warnings to non-SSL connections in postgresql and the frontend.

Also we need to get a bridge certificate internally inside our cloudflare network. Will do.

=> Different to what I said before: All our DB traffic is already encrypted. It was apparently the default.

Checked via:

select datname, usename, ssl, client_addr
from pg_stat_ssl
inner join pg_stat_activity on pg_stat_ssl.pid = pg_stat_activity.pid;

[ArneTR]

To conclude this discussion: SSL was added with all the features discussed

#928