x509Vnc support

[Dave Neeley <da...@gmail.com>]

There was a pull request two years ago that would have added support for
the x509Vnc protocol in guacd. There was some discussion about storing the
certificates on disk on the guacd server rather than in-memory, and the
code was pulled.

GUACAMOLE-514: Implement additional VNC authentication support by
necouchman · Pull Request #232 · apache/guacamole-server (github.com)
<https://github.com/apache/guacamole-server/pull/232/commits/51ae8a41a138ff7a2a5b7e81b9647b7cd49ebdab>

I would have assumed the certificates most definitely had to be stored on
disk _somewhere_, is that not correct? Say the guacamole web client was
running in one docker container, and guacd was running in a second
container. How would certificates be passed in-memory between these two?

Has anyone found a way to implement x509Vnc support?

-dave

Re: x509Vnc support

[Nick Couchman <vn...@apache.org>]

On Fri, Mar 5, 2021 at 3:54 PM Dave Neeley <da...@gmail.com> wrote:

> Thank you for such a quick response.
>
>
>> To be clear, support is implemented, already.
>
>
> Perhaps I misunderstood? There are -C [Certificate] and -K [Key] startup
> options for guacd, which enables "data sent via the Guacamole protocol [to]
> be encrypted with SSL". I assumed this encryption was only between the
> client and guacd. Is it also between guacd and the VNC server? If the VNC
> server presents a cert, will guacamole's protocol accept it?
>
>
It probably makes sense to back up and talk about the components of
Guacamole:
- Guacamole Server (guacd): Listens on port 4822 for Guacamole protocol
connections and facilitates the back-end connections to the other protocols
(RDP, SSH, Telnet, Kubernetes, and VNC)
- Guacamole Client Java Application: Runs in Tomcat, or a comparable Java
application server, and facilitates the tunneling of the web application
(HTTP/S and/or WS/S) with guacd. It also handles things like
authentication, authorization, and accountability, along with connection
management, via the various authentication extensions.
- Guacamole Client Web Application: Runs in the client browser,
transferring data between the browser and guacd via the Java Web
Application using the Guacamole protocol. It also interacts with the REST
API made available by Guacamole Client to handle authentication, connection
management, etc.

The certificate and key options you mentioned above for guacd are to
facilitate secure communication between Guacamole Client Java Application
and guacd, so that those protocols can communicate via encrypted channels
over a network. This is primarily useful in situations where you run
Guacamole Client (Java) on a separate system from Guacamole Server (guacd),
particularly over untrusted networks. In a lot of cases guacd is run on the
same system as Guacamole Client, either directly/native or closely enough
when run in Docker containers on the same machine, and this doesn't
necessarily add much value.

These guacd certificate/key options do not have anything to do with the
connectivity from guacd out to SSH, RDP, VNC, and/or Kubernetes hosts.
Support for authentication via certificates is based on the options
available in the protocol settings, not via high-level guacd options.


> Otherwise, the kubernetes protocol.c has settings for certs, but the VNC
> protocol doesn't have them in master.
>
> Search · org:apache x509 guacamole (github.com)
> <https://github.com/search?q=org%3Aapache+x509+guacamole&type=commits>
>
> My selfish purpose would not need a certificate or keypair locally on the
> browser/client - x509 could just be "always on".
>
>
Looking further at the code history, we pulled x509 support out prior to
merging GUACAMOLE-514:

https://github.com/apache/guacamole-server/commit/f21621e677804ee39e3a2418e114f064034c76ba#diff-58d5233358bca757bb7692e2f190435788a6ffbf9c5243d052d7bd9a134520af

There is part of the conversation in the pull request that covers this:

https://github.com/apache/guacamole-server/pull/232

Basically, we agreed to pull out the x509 portion of authentication because
having it point to a file on the local filesystem of the guacd system
didn't really seem like a great path to take, given that you usually want
the client to provide the credentials, not some intermediate server. So,
Guacamole does not support VNC x509 authentication today.

-Nick

>

Re: x509Vnc support

[Dave Neeley <da...@gmail.com>]

Thank you for such a quick response.


> To be clear, support is implemented, already.


Perhaps I misunderstood? There are -C [Certificate] and -K [Key] startup
options for guacd, which enables "data sent via the Guacamole protocol [to]
be encrypted with SSL". I assumed this encryption was only between the
client and guacd. Is it also between guacd and the VNC server? If the VNC
server presents a cert, will guacamole's protocol accept it?

Otherwise, the kubernetes protocol.c has settings for certs, but the VNC
protocol doesn't have them in master.

Search · org:apache x509 guacamole (github.com)
<https://github.com/search?q=org%3Aapache+x509+guacamole&type=commits>

My selfish purpose would not need a certificate or keypair locally on the
browser/client - x509 could just be "always on".


On Thu, Mar 4, 2021 at 9:33 PM Nick Couchman <vn...@apache.org> wrote:

> On Thu, Mar 4, 2021 at 19:54 Dave Neeley <da...@gmail.com> wrote:
>
>> There was a pull request two years ago that would have added support for
>> the x509Vnc protocol in guacd. There was some discussion about storing the
>> certificates on disk on the guacd server rather than in-memory, and the
>> code was pulled.
>>
>> GUACAMOLE-514: Implement additional VNC authentication support by
>> necouchman · Pull Request #232 · apache/guacamole-server (github.com)
>> <https://github.com/apache/guacamole-server/pull/232/commits/51ae8a41a138ff7a2a5b7e81b9647b7cd49ebdab>
>>
>>
> Oops, looks like I missed some documentation for those parameters...
>
> I would have assumed the certificates most definitely had to be stored on
>> disk _somewhere_, is that not correct? Say the guacamole web client was
>> running in one docker container, and guacd was running in a second
>> container. How would certificates be passed in-memory between these two?
>>
>
> Yes, the parameters referenced in the pull request would, most likely,
> point to the location of a file, accessible by guacd, that contains the
> certificate, key, CA, and crl data, respectively. So, even though the
> parameters are configured client-side, the client itself (both browser and
> client container for the Java code) need not have any access to or
> knowledge of the contents of the files.
>
>
>> Has anyone found a way to implement x509Vnc support?
>>
>
> To be clear, support is implemented, already. Whether it works
> consistently or not, or behaves as you expect it to, is another story. For
> example, if you’re looking for an implementation where the user can have a
> certificate and key pair locally available to their browser that then gets
> passed through transparently to guacd to use for the VNC connection, that
> definitely will not work as currently implemented, and would take some
> (significant) additional work to make happen.
>
> -Nick
>

Re: x509Vnc support

[Mike Jumper <mi...@glyptodon.com>]

On Thu, Mar 4, 2021 at 8:33 PM Nick Couchman <vn...@apache.org> wrote:

> On Thu, Mar 4, 2021 at 19:54 Dave Neeley <da...@gmail.com> wrote:
>
>> ...
>>
> I would have assumed the certificates most definitely had to be stored on
>> disk _somewhere_, is that not correct? Say the guacamole web client was
>> running in one docker container, and guacd was running in a second
>> container. How would certificates be passed in-memory between these two?
>>
>
> Yes, the parameters referenced in the pull request would, most likely,
> point to the location of a file, accessible by guacd, that contains the
> certificate, key, CA, and crl data, respectively. So, even though the
> parameters are configured client-side, the client itself (both browser and
> client container for the Java code) need not have any access to or
> knowledge of the contents of the files.
>

To clarify on this a bit further:

The details of a connection are passed as part of the Guacamole protocol
during the handshake phase. This is performed by the web application based
on how the connection has been configured by the administrator. Passing
certificate filenames for local use by guacd would go against some of the
core design principles behind the separation of guacd and the webapp. With
the exception of data that absolutely *must* be on disk (like RDP drive
redirection), data dictated by the webapp shouldn't need to be on disk.

Part of the idea behind the separation between guacd and the webapp is that
guacd should be able to consume the data fed to it by the webapp (or some
third-party webapp) and provide a remote desktop connection that satisfies
the request dictated by that data, without making assumptions regarding how
that data is sourced. This includes details like the
credentials/certificates that must be available to authenticate with the
remote desktop.

In the most basic situation where guacd and Guacamole are running on the
same server, it will not immediately make sense why guacd should not assume
that the required certificates are on disk. In the bigger picture, guacd
and Guacamole need not run on the same server, both might actually consist
of multiple nodes behind balancers, and the data in question may actually
come from a database, or might be provisioned just-in-time, or retrieved
from a vault, etc.

TL;DR - No, the certificates are not necessarily stored on disk somewhere.
They may not even be stored at all. It's just not a safe assumption.

Michael Jumper
CEO, Lead Developer
Glyptodon Inc <https://enterprise.glyptodon.com/>.

Re: x509Vnc support

[Nick Couchman <vn...@apache.org>]

On Thu, Mar 4, 2021 at 19:54 Dave Neeley <da...@gmail.com> wrote:

> There was a pull request two years ago that would have added support for
> the x509Vnc protocol in guacd. There was some discussion about storing the
> certificates on disk on the guacd server rather than in-memory, and the
> code was pulled.
>
> GUACAMOLE-514: Implement additional VNC authentication support by
> necouchman · Pull Request #232 · apache/guacamole-server (github.com)
> <https://github.com/apache/guacamole-server/pull/232/commits/51ae8a41a138ff7a2a5b7e81b9647b7cd49ebdab>
>
>
Oops, looks like I missed some documentation for those parameters...

I would have assumed the certificates most definitely had to be stored on
> disk _somewhere_, is that not correct? Say the guacamole web client was
> running in one docker container, and guacd was running in a second
> container. How would certificates be passed in-memory between these two?
>

Yes, the parameters referenced in the pull request would, most likely,
point to the location of a file, accessible by guacd, that contains the
certificate, key, CA, and crl data, respectively. So, even though the
parameters are configured client-side, the client itself (both browser and
client container for the Java code) need not have any access to or
knowledge of the contents of the files.


> Has anyone found a way to implement x509Vnc support?
>

To be clear, support is implemented, already. Whether it works consistently
or not, or behaves as you expect it to, is another story. For example, if
you’re looking for an implementation where the user can have a certificate
and key pair locally available to their browser that then gets passed
through transparently to guacd to use for the VNC connection, that
definitely will not work as currently implemented, and would take some
(significant) additional work to make happen.

-Nick