Add end-to-end encryption

[varunsh-coder]

Ideally, the secrets should be encrypted end-to-end so the backend API cannot access them. Only the GitHub Action should be able to decrypt the secrets.

[ljharb]

That said tho, since I'm typing the secrets directly into your website, I can't avoid implicitly trusting your server - since the HTML/JS served by the page is also under your control.

Or are you talking about encrypting it as soon as the webserver receives it?

[varunsh-coder]

The secrets are stored in a data store for a short time until the GitHub Action workflow fetches them. Once fetched, they are deleted.

One option is to encrypt the secrets in the website using JavaScript before they are sent to the backend API.
Another option is to encrypt them as soon as it hits the backend API.

The idea is that even if the data store is compromised, one should not be able to access the secrets.

[ljharb]

I think encrypting them in the client is nonsense, but encrypting them the instant it hits the webserver seems fine.

[azban]

There could be a simple CLI that takes in a PSK and the plaintext and spits back ciphertext that can be pasted into the browser client. The CLI could also just hit the API directly, I'm assuming?

[ljharb]

There could be, but it would make the feature useless to me since i wouldn’t be able to input secrets easily on the go.

If i don’t trust the webserver here, i should be hosting one myself - ideally there’d be an open source option for self-hosting.

[azban]

OK. There are more benefits to having the hosted server than just having a mobile interface, and people may be willing to have the additional friction but still not want to host a webserver (assuming they trust passing ciphertext to a 3rd party).

There may be multiple concerns: not wanting secrets in plaintext at rest, but being OK with the server having access to those secrets; not wanting the server or client to have plaintext secrets ever. These can be addressed individually, and people could choose what works for them.

[ljharb]

"plaintext" doesn't apply, since it's over HTTPS.

I'm very in support of providing options :-) it's just important to be very clear about what the UX and security tradeoffs are - and the security benefits are pretty minimal unless you're self-hosting.

[azban]

HTTPS is encrypted over the wire but is terminated before or at the server, so "plaintext" does apply because the server has "plaintext". You can pass "ciphertext" via the API and the server will never have the "plaintext" unless they break your encryption. This is end-to-end encryption, which is explicitly what the original specifies as ideal.

Unless I'm mistaken, if you have an AES-256 key and you encrypt your secret, you can pass ciphertext to the server to be decrypted by that same key in an Action, configured by Github, or, better, on a self hosted runner. This would make it non-trivial for the server to decrypt and utilize any given secret.

Handing a server a TOTP token on a consistent basis is essentially handing them over that authentication factor, making it useless. Assuming they gain access to your first factor, they can easily stage an attack for the next time your Action requests a secret. Even if that seems unlikely, MFA is required for some things for a reason.

[ljharb]

Yes, but because any form of encryption in the browser relies on JavaScript controlled by the server, if the server is malicious you are always screwed, there’s no way to protect yourself (short of using out of band means to encrypt, like a CLI tool or an extension, neither of which are available on mobile or to the average user).

On the web, HTTPS is both enough, and the maximum worth doing, to secure content before it hits the server.

[azban]

Ah, makes sense. I thought the CLI bit was still relevant because it was brought up as one option to support one use-case, and technically satisfies the issue description of wanting e2e encryption.

neither of which are available on mobile or to the average user

I don't think this issue is specifically targeting mobile users. And I think most people that are using Github Actions have a terminal and knows how to install and use a CLI.

[ljharb]

Yes, but I want to be able to initiate a workflow, and then leave the house, and start the publish once it's ready, from my phone.

[azban]

Sure, maybe start a new issue? It seems like there's two things going on here, and they are unnecessarily at odds and leading to more conversation and confusion than necessary.

[ljharb]

I think this is the right issue, as they're related. Full end-to-end encryption from a website adds zero security, and actively harms valuable use cases, so it's a harmful thing to be seeking.

[azban]

You're the only one saying this has to be encryption in the browser. The CLI use case is valid for people who want real end-to-end encryption, and does not "harm" the use case that you want. It could be a separate implementation.

Generally not feeling like you are hearing, or trying to hear, any of my comments and are acting like this issue is specifically for you. I'm not affiliated with this project and was just trying to get to a point of clarity. Good luck y'all.

[ljharb]

@azban that's a fair point, that a CLI tool could be an alternative to using the website at all.

[varunsh-coder]

What about this proposal? I think this design will meet all requirements:

1. Create a public/private key pair in the job where wait-for-secrets is run.
2. Send public key to the back-end API.
3. API stores the public key.
4. When API is called to fetch secret metadata, it also returns the public key
5. API will expect the secrets sent to it to be encrypted with the public key
6. The StepSecurity website (which is one client) will do this encryption transparently. So the developer experience will remain same as current. Developer enters secrets into website. Website uses public key to encrypt them and sends to API.
7. There can be more clients, e.g. a phone App, a CLI etc. One could also write their own client if they do not want to trust the StepSecurity website/ clients.
8. Clients should display the public key info, so if developer wants, they can compare it with what is in the build log.
9. Once the API gets the encrypted secrets, it cannot decrypt them. Only the job with the private key can.
10. Job receives the encrypted secrets and decrypts using the private key.

This design will enable end-to-end encryption without changing the current developer experience. It will also enable developers to write their own clients. Thoughts?

[ljharb]

That sounds to me like it'd meet all concerns and use cases here.