Mirth Connect
  1. Mirth Connect
  2. MIRTH-4176

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

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Security Security
    • Resolution: Unresolved
    • Affects Version/s: 2.2.3, 3.0.3, 3.1.1, 3.2.2, 3.5.0, 3.3.2, 3.4.2
    • Fix Version/s: 3.9.0
    • Component/s: Administrator, Server
    • Labels:

      Description

      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.

        Activity

        Hide
        Christopher Schultz added a comment -

        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

        Show
        Christopher Schultz added a comment - 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

          People

          • Assignee:
            Unassigned
            Reporter:
            Nick Rupley
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Development