Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All encryption / decryption should be done on the server, not client side #4053

rbeckman-nextgen opened this issue May 11, 2020 · 1 comment


Copy link

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

Encryption is only done on the client-side currently for exporting (messages, channels, etc.). It would be a performance hit to do encryption on the server for these things, but I think it's necessary from a security standpoint. Right now we're passing the secret symmetric key from the server to the client over the network. Even though that obviously happens from within HTTPS, most users still use the default self-signed cert.

The LDAP extension currently also encrypts the admin password on the client.

Imported Issue. Original Details:
Jira Issue Key: MIRTH-4176
Reporter: narupley
Created: 2017-06-07T09:22:57.000-0700

Copy link
Collaborator Author

@rbeckman-nextgen rbeckman-nextgen commented May 11, 2020

When exporting to a file, then importing into another environment, how do you move the secret that protects the encrypted data? If using an appliance, you'll need to extract the symmetric key from the source server over that same network AND re-send that key over a similar network to the receiving server.

Perhaps it would be better to use a client-provided symmetric key (aka password) to encrypt sensitive data in the export-files (or the whole file, for that matter), then request the same password to be entered into the receiving client in order to decrypt the file.

This way, you:

(1) don't bog-down the server with encryption operations
(2) don't require that the server's symmetric key be ported between different servers
(3) allow different users to use whatever password they want without having to access some kind of privileged secret

Imported Comment. Original Details:
Created: 2019-04-04T20:15:40.000-0700

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.