[
https://issues.apache.org/jira/browse/GUACAMOLE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833365#comment-16833365
]
Travis Royer commented on GUACAMOLE-790:
----------------------------------------
{quote}The focus on trying to obscure or double/super-encrypt the Guacamole
traffic over any of the other traffic you'd also be generating (e-mail,
banking, medical, etc.) seems misplaced
{quote}
Valid, unless one is only using their Guac when accessing their financial and
PHI data in an effort to protect it :) Honestly though, thanks gents for the
discussions on this and all of your work on the project! It's definitely a
scenario that applies to only a small subset of users right now, and I found it
to be an interesting situation for one to be in.
> Encode/Encrypt websocket messages
> ---------------------------------
>
> Key: GUACAMOLE-790
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-790
> Project: Guacamole
> Issue Type: New Feature
> Components: guacamole-common-js, libguac
> Reporter: Travis Royer
> Priority: Minor
>
> It would be nice to have a feature that will either encode, encrypt, or
> otherwise obfuscate the contents of the tunnel's websocket messages. For
> example:
> *Plaintext (original):*
> {{3.key,3.102,1.1;}}
> *Encoded:*
> {{3.enc,24.My5rZXksMy4xMDIsMS4xOw==;}}
> This would require the client app to encode the message prior to sending it
> to the server, as well as decoding the message upon receipt from the server
> prior to parsing it. Example javascript to encode prior to the
> socket.send(message) call in Tunnel.js:
> {{ message = "3.enc," + getElement(btoa(message));}}
> Of course, you would also need similar functions for the guacamole-server. I
> wasn't able to figure out how to get it to work there; it's been a while
> since I've touched C. For incoming messages, after it parses these encoded
> messages, the "enc" handler would decode the data. Since the data is another
> websocket message, the handler would then need to re-parse and handle that
> instruction.
> *Purpose:* additional privacy and security in insecure environments. While
> TLS would encrypt the entire communication, sometimes this cannot be trusted,
> or sometimes organizations/higher-level entities will proxy/man-in-the-middle
> to decrypt and inspect TLS sessions prior to re-encrypting. In these cases,
> it would be nice to have a means of protecting the websocket messages so that
> they remain unreadable (or at least encoded/not directly readable) when
> running over on an untrusted network.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
