Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

v2.envkey.com

Post reply on HN
Print view View original

11–20 of 67 posts

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#11

Post by danenania »

gmfawcett wrote: post #9

Interesting! You show a lot of examples where the server is created as a child of your EnvKey process. That kind of suggests you might encounter EnvKey being the PID 1 in a containerized application. Does EnvKey have a good "PID 1 discipline" -- in particular, reaping zombie processes?

Good question. envkey-source catches kill signals and then sends a SIGTERM on to the process it's running. The process then has a few seconds to handle the SIGTERM and clean up before it's forcefully killed with SIGKILL (the amount of time is configurable via an argument).

Does that answer your question?

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#12

Post by koolba »

danenania wrote: post #10
itake wrote: post #7

I have a few friends that run their own crypto nodes b/c they don't trust cloud providers (and their employees) to have access to their private keys (which may control millions of dollars). Would this tool minimize the risk of an employee snapshots the disk and RAM of their machine?

Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.

Except for a cold boot style attack right?

https://en.m.wikipedia.org/wiki/Cold_boot_attack

I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#13

Post by danenania »

mattste wrote: post #8

How does this compare to Doppler[1]? Is there a way to handle the configuration in Terraform? [1] https://www.doppler.com/

I've met the Doppler founders and greatly respect them (even played some poker with them!). Doppler has great design and UX.

That said, I'd say the key difference is that EnvKey places much more emphasis on security and privacy. Doppler is cloud-hosted and doesn't use end-to-end encryption, so it requires that you trust them to keep your data safe and not make any mistakes in their data security, network security, who they hire, what sub-processors they trust, etc. In my (very biased) opinion, that is not sufficient protection for the most sensitive data.

Doppler also uses a web interface, which is great for convenience and UX, but leaves you vulnerable to compromised browser plugins, XSS, etc. I don't believe browsers are sufficiently secure currently for secrets management (if this changes, we'll add a web interface to EnvKey ASAP!).

There are real costs in terms of UX to end-to-end encryption. EnvKey tries to be as user-friendly as possible, but doesn't compromise on security or privacy. Doppler's design, as I understand it, leans more toward the other side of this tradeoff.

On Terraform--yes, it's easy to use EnvKey with Terraform. The general pattern for integrating EnvKey with any tool or platform is to set your ENVKEYs as secrets in whatever way the platform handles them, then expose each ENVKEY as an environment variable to your VMs, containers, or whatever else you're running. We'll write up a Terraform-specific guide soon to make it as easy as possible.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#14

Post by danenania »

koolba wrote: post #12
danenania wrote: post #10

Earlier quoted context omitted.

Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.

Except for a cold boot style attack right? https://en.m.wikipedia.org/wiki/Cold_boot_attack I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.

We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.)

EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an ENVKEY access key would still have to expose those secrets in RAM to the process that needs them. We don't claim to protect user devices or connected servers from endpoint compromise.

We do offer some features to help mitigate this though:

- You can limit access to an ENVKEY to specific IPs or CIDR ranges.

- On a user device, secrets are periodically removed from RAM if they haven't been accessed recently.

- On a user device, only encrypted data is stored on disk, and the OS keychain is used on Mac and Windows.

- If an ENVKEY's access it cut off, envkey-source can immediately kill the process, making the secrets harder to access from RAM.

- Audit logs can help you track exactly what was exposed and when in the event of an incident.

- Access to secrets is 'pushed' as far down the stack as possible... so your secrets at least wouldn't be accessible in some cloud provider database--they would need to get access to the running process itself or the machine's RAM.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#15

Post by itake »

koolba wrote: post #12
danenania wrote: post #10

Earlier quoted context omitted.

Yes, EnvKey uses client-side end-to-end encryption and never sends secrets to the host server in plaintext (whether it's self-hosted or you use EnvKey Cloud). So there would be no way for a cloud provider employee (or an EnvKey employee) to get access from the server side. Even the names of your variables are encrypted and not accessible except on the client.

Except for a cold boot style attack right? https://en.m.wikipedia.org/wiki/Cold_boot_attack I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.

+1, ideally, it should only decrypt (and fetch?) the when it needs to use the key. So 99% of the time, the key isn't sitting decrypted in memory.

Having to trigger a network call each time the key needs to be used (like to sign a transaction) isn't great though :-/.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#18

Post by itake »

danenania wrote: post #14
koolba wrote: post #12

Earlier quoted context omitted.

Except for a cold boot style attack right? https://en.m.wikipedia.org/wiki/Cold_boot_attack I’m assuming the client side code isn’t keeping the secrets in some kind of TPM right? ie anyone with root access to the server or the ability to dump the memory could pull them out.

We need to distinguish between the server where EnvKey's API is running, which contains EnvKey's back-end logic, and 'client' servers (or user devices) that are connecting to EnvKey to fetch config for a particular app/environment. (It's possible I misunderstood the distinction the parent comment was getting at.) EnvKey's API server has no access to secrets data. But you're right that a server pulling secrets via an…

> - On a user device, secrets are periodically removed from RAM if they haven't been accessed recently.

I looked at the ruby sdk code and it doesn't periodically remove them from RAM. Storing the ENVs in the `ENV` object makes me nervous, because its an easy target for supply attacks to dump the `ENV` to logs / remote servers.

Re: Show HN: EnvKey 2.0 – End-To-End Encrypted Environments (now open source)

#20

Post by KMag »

danenania wrote: post #11
gmfawcett wrote: post #9

Interesting! You show a lot of examples where the server is created as a child of your EnvKey process. That kind of suggests you might encounter EnvKey being the PID 1 in a containerized application. Does EnvKey have a good "PID 1 discipline" -- in particular, reaping zombie processes?

Good question. envkey-source catches kill signals and then sends a SIGTERM on to the process it's running. The process then has a few seconds to handle the SIGTERM and clean up before it's forcefully killed with SIGKILL (the amount of time is configurable via an argument). Does that answer your question?

If your child processes spawn grandchild processes and then exit or otherwise die, and envkey-source is running as PID 1, then envkey-source will become the parent of those orphaned grandchild processes. When those orphans exit, envkey-source must check those process's exit status. Until then, those process IDs can't be reused, and the processes stick around as zombie processes.

In other words, PID 1 is special, because it may have child processes that it never created, and needs to be aware and handle them properly. Otherwise, you can end up leaking zombie processes.

It sounds like envkey-source isn't aware that it may adopt orphaned child processes. Killing them isn't the main issue. Checking their exit statuses is the main issue.

Post reply on HN