[
https://issues.apache.org/jira/browse/GUACAMOLE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833147#comment-16833147
]
Travis Royer commented on GUACAMOLE-790:
----------------------------------------
{quote}
If you can't trust TLS, all is lost.
{quote}
While it's a huge blow to security, I disagree that all is lost. This feature
wouldn't protect your guac login credentials, but 2FA can help alleviate their
use if they were captured. What this feature _can_ do is protect your socket's
session data, providing security against sniffing keystrokes (client->server)
and session imagery (server->client) from the network, amongst all other socket
messages. Am I missing a reason as to why this wouldn't solve that issue if it
encrypts the socket data (forget I mentioned encoding)?
I agree that encoding is just security through obscurity; encryption would of
course be a better choice, but I just provided it as a simplistic example. An
option to enable web socket message encryption with a given key would be ideal.
TLS decryption and inspection is becoming more and more popular in enterprise
environments. I don't think we should give up on privacy just because we can't
necessarily trust TLS, defense-in-depth is always an important factor and this
is just another one of those steps. If TLS is bypassed/circumvented, our
defense strategy should include another step. I think this step would solve
that, since these environments aren't designed to take this second step in
decryption, nor would they know the key to do so. By all means though, let me
know if I'm missing a hole in this that would continue to make it vulnerable.
Thanks for the response!
> 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)
