[
https://issues.apache.org/jira/browse/GUACAMOLE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833362#comment-16833362
]
Nick Couchman commented on GUACAMOLE-790:
-----------------------------------------
{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.
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}
Not only that, but, if this is the environment you're concerned about and are
trying to protect against (Big Bad Corporate IT spying on you), Guacamole
traffic is not the only thing that is "compromised" in this situation - _all_
of your traffic is compromised. 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, and
certainly out-of-scope for the project.
> 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)
