You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@guacamole.apache.org by Giovanni Magoga <ma...@gmail.com> on 2023/12/12 10:49:29 UTC
Adding AES Encryption to Guacamole tunnel
Hello,
I am developing a Guacamole-based web app with high confidentiality
requirements, that TLS by itself does not fulfill.
Specifically, I require an additional encryption layer: client inputs
should be AES-encrypted by the browser's JS runtime before being sent via
the tunnel, and then decrypted server-side.
I've identified FilteredGuacamoleSocket
<https://github.com/apache/guacamole-client/blob/212955c16c393c08f434f1def0ac12be36b09b2e/guacamole-common/src/main/java/org/apache/guacamole/protocol/FilteredGuacamoleSocket.java#L31>
in guacamole-client as a potential integration point for the cipher,
however, I couldn't find any examples of its usage.
Is this the right approach to add this type of capability? Could you
provide some guidance on where to instantiate the FilteredGuacamoleSocket
if so?
Thanks
*Giovanni Magoga*
linkedin.com/in/ma9o
<https://www.linkedin.com/in/ma9o/>
calendly.com/ma9o
Re: Adding AES Encryption to Guacamole tunnel
Posted by Giovanni Magoga <ma...@gmail.com>.
> 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 <vn...@apache.org> wrote:
> On Tue, Dec 12, 2023 at 9:40 AM Christopher Speck <di...@gmail.com>
> 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
>
Re: Adding AES Encryption to Guacamole tunnel
Posted by Nick Couchman <vn...@apache.org>.
On Tue, Dec 12, 2023 at 9:40 AM Christopher Speck <di...@gmail.com>
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
Re: Adding AES Encryption to Guacamole tunnel
Posted by Christopher Speck <di...@gmail.com>.
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.
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.
- Christopher
> On Dec 12, 2023, at 5:49 AM, Giovanni Magoga <ma...@gmail.com> wrote:
>
> Hello,
>
> I am developing a Guacamole-based web app with high confidentiality
> requirements, that TLS by itself does not fulfill.
> Specifically, I require an additional encryption layer: client inputs
> should be AES-encrypted by the browser's JS runtime before being sent via
> the tunnel, and then decrypted server-side.
>
> I've identified FilteredGuacamoleSocket
> <https://github.com/apache/guacamole-client/blob/212955c16c393c08f434f1def0ac12be36b09b2e/guacamole-common/src/main/java/org/apache/guacamole/protocol/FilteredGuacamoleSocket.java#L31>
> in guacamole-client as a potential integration point for the cipher,
> however, I couldn't find any examples of its usage.
>
> Is this the right approach to add this type of capability? Could you
> provide some guidance on where to instantiate the FilteredGuacamoleSocket
> if so?
>
> Thanks
>
> *Giovanni Magoga*
> linkedin.com/in/ma9o
> <https://www.linkedin.com/in/ma9o/>
> calendly.com/ma9o