> Could you add further information on what security requirements are prompting this?
Essentially we want to operate in a zero-trust environment, where the user only interacts with code of which the integrity can be verified. I'll provide a quick summary of the architecture: - The user runs the Javascript client from a trusted URL, and at some point he is prompted to enter some highly sensitive information over RDP with guacamole. - The remote desktop is hosted in an Azure Confidential VM (CVM), which also contains the guacamole services. - To initiate the exchange the client receives a JWT from the Azure Attestation Service which attests the code integrity of the CVM and provides the client a PubKey, which has its private counterpart in the TPM. - The client creates an AES key, encrypts it with the PubKey and sends it over to the CVM. The CVM decrypts the AES key using the TPM PrivKey and finally provides it to the guacamole services to decrypt incoming traffic. To sum up, the user does see a valid certificate when starting the RDP session, but the certificate only attests the authenticity of the gateway, but not its trustworthiness. There is potentially a way to create a TLS certificate using the TPM's PrivKey, but the user would have to manually verify the trust chain in the browser, which we want to avoid. By encrypting the traffic from Javascript, the client only has to rely on the JWT being trustworthy. See the diagram below. The color scheme reflects the trusted parties from a client perspective: [image: Untitled-2023-11-22-1747(4)(1).png] MS docs for reference: https://learn.microsoft.com/en-us/azure/confidential-computing/guest-attestation-confidential-vms#scenario-relying-party-handshake Thanks for the help! *Giovanni Magoga* linkedin.com/in/ma9o <https://www.linkedin.com/in/ma9o/> calendly.com/ma9o On Tue, Dec 12, 2023 at 4:47 PM Nick Couchman <[email protected]> wrote: > On Tue, Dec 12, 2023 at 9:40 AM Christopher Speck <[email protected]> > wrote: > > > Could you add further information on what security requirements are > > prompting this? I don't follow how encrypting the tunnel further would > add > > additional security over turning on TLS. It would probably be better to > > ensure appropriate network security via routing, firewalls, and vpn. > > > > I agree with this - I'm not sure why AES-encrypting keystrokes would > provide any value outside of the TLS encryption that is already present if > you configure HTTPS and WSS. > > > > > > Terminating the AES of the guacamole protocol would have to be done in > > guacamole-server, where it then converts to RDP/VNC which wouldn't be > able > > to be further encrypted with AES (but you can configure these connections > > to also use TLS). Adding AES here would only prevent the guacamole-client > > web server from being able to inspect the traffic. The guacamole-client > web > > server has to inspect the traffic to some degree as there are some > > instructions managed on the web server and not passed on to the > > guacamole-server. Encrypting at the JS client and decrypting in > > guacamole-server would not be beneficial over using HTTPS from browser to > > guacamole-client web server and TLS between guacamole-client and > > guacamole-server. > > > > A couple of things worth noting, here: > * I cannot think of any place within the Guacamole Client code that runs in > Tomcat that you would need to be able to "see" the Guacamole protocol > traffic, specifically the keystrokes. Basically, Tomcat just facilitates > the tunnel between guacd and the web browser, providing access control and > managing access to connections. But it doesn't really evaluate anything > related to the protocol traffic itself. > * It is possible to encrypt the Guacamole protocol traffic between the > Tomcat instance where the server-side Guacamole Client code runs and the > guacd instance. You can configure the guacd SSL settings and make sure > Tomcat has the correct trust set up, and that traffic will be encrypted. > This is valuable in the case where you have some potentially-untrusted > network distance between Tomcat and guacd. This, combined with HTTPS/WSS, > gives you end-to-end encryption from the Guacamole Perspective - Browser > <-- (HTTPS/WSS) --> Tomcat <-- (TLS) --> guacd. From guacd on to the remote > server you'd need to configure encryption on the connection itself - SSH of > course already has it, RDP defaults to it, and VNC would require support > for TLS. > > -Nick >
