[
https://issues.apache.org/jira/browse/GUACAMOLE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833178#comment-16833178
]
Michael Jumper commented on GUACAMOLE-790:
------------------------------------------
{quote}
... 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. ...
{quote}
No, obscurity cannot be used to truly protect anything from anything. The only
way to protect the data noted above is through (1) proper encryption coupled
with (2) verification of identity of the server receiving that encrypted
communication.
{quote}
Am I missing a reason as to why this wouldn't solve that issue if it encrypts
the socket data (forget I mentioned encoding)?
{quote}
To guarantee security and privacy, you need much of what TLS provides, in
particular verification of the identity of the endpoint receiving your
encrypted communication (MITM otherwise becomes a possibility).
{quote}
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.
{quote}
In general, yes, broken thing should be replaced with non-broken thing, but I
don't think that applies in this case.
The issue here is that the nature of the compromised environment means that
there can be no expectation that additional measures would be any more safe
than TLS. The only expectation of security in a situation like this would be
built on the hope that the parties that compromised TLS are not yet aware of
any additional measures, which brings us back to the original point - we can't
rely on obscurity.
{quote}
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.
{quote}
Really, this is just security through obscurity again. If the reason the system
is expected to remain secure is because eavesdropping third parties are unaware
of the system, then it's not actually secure and should not be relied upon.
> 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)
