On Fri, Mar 5, 2021 at 3:54 PM Dave Neeley <[email protected]> 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 >
