Implement SSL on layout server

[pling-scottlogic]

Background

We want to implement SSL on the layout server so that we can use a secure HTTPS connection when calling from Vuu UI. This will also satisfy the static code analysis and therefore remove the need to reference the calling code in the .semgrepignore file.

Work Required

• Generate a self-signed SSL certificate using the keytool CLI or find an existing one from the Vuu server (looks like we might already be using OpenSSL)
• Enable SSL in the application.properties file for the layout server
• Create a SecurityConfig class to redirect HTTP requests to HTTPS
• Configure the UI to make requests over HTTPS
• chckout SSL usage in Scala code (vuu\src\main\scala\org\finos\vuu\net\http\VuuHttp2Server.scala)
• remove "vuu-ui/packages/vuu-layout/src/layout-persistence/RemoteLayoutPersistenceManager.ts" from .semgrepignore

Testing

• Ensure that calls over HTTPS are picked up successfully
• Ensure that calls over HTTP are redirected to HTTP

[cfisher-scottlogic]

@scottlogic-alex unblocked me, woo!

[cfisher-scottlogic]

WIP on branch SLVUU-79-ssl-on-layout-server

I've created a working implementation of SSL on the server. There are a few caveats which requires more thought before we can implement TLS:

1. Certificate & password storage
   • Storing the public certificate isn't an issue. But the layout server needs the private certificate/key in order to encrypt/decrypt for the TLS protocol
   • Uploading the private key to GitHub wouldn't be wise, as this would entirely negate the point of it being private
   • Since we're not hosting this on any platforms yet, and this is all locally developed, we don't have any to-hand third party tools or infrastructure for private key storage
   • It's also not the best idea to push an unencrypted password to GitHub
   • Even if we encrypt the password in application.properties so it's not pushed to GitHub, someone will need to know that password, and it will remain a matter of how do you share that password to all developers who may need it?
2. Replicating the certificate creation process
   • A possible solution to the private-key storage issue is to get developers who want to use the server to replicate the certificate creation process locally
   • This would work if they made sure to create the certificate with the properties the server expects, as defined in application.properties (keystore type, keystore location, keystore password, key alias)
   • Creating the certificates is super easy with mkcert (the tool I used), as it abstracts away the need for complicated CLI commands, self-signing, trusting, etc. One command handles the whole thing, and makes destroying the tickets super simple too.
   • But this places a blocker on developers being able to use the remote server - it would fail to build if application.properties is expecting certificates to be available which wouldn't be if a developer hadn't generated certs
   • The CLI command could possibly be incorporated into the server build process? Which would negate the need for manual intervention, and ensures all developers will have certs. Costly overhead if it happens every time though.

The certificates that exist on the branch shouldn't be used, because by pushing it remotely we've exposed the private key. If this work is going to be used, make sure to delete the current certificates and regenerate new ones.

[pling-scottlogic]

Draft PR raised into Finos repo.