Hello everybody,
we're thinking of buying a TinyPilot, but we'd like to understand certain aspects of the device and the software before.
1. Security of the transmitted screen image stream
We have understood that the TinyPilot offers a Web Interface to configure it, and take it as a matter of course that this interface is secured by modern versions of TLS and that we can choose (at the server side, i.e. on the TinyPilot) which TLS version and ciphers the HTTP server offers / accepts.
However, quite a few of similar devices transmit the console via VNC protocol on port 5900, mostly unencrypted.
Hence the first question: Can the TinyPilot be configured so that everything is securely encrypted, notably the configuration interface, the keystrokes, the mouse actions and the screen image stream, and that it does not offer any unencrypted connections (on other ports)?
Notably, how is the screen video stream transmitted? Is it embedded in HTML pages, and if yes, how (which protocol and encryption)?
2. What to do if the controlled remote PC is also used locally
We have a scenario which may be somehow uncommon: We have some PCs at customers' places. For remote usage, we can turn on and off those PCs remotely, but since their HDDs are encrypted, we need to enter the HDD passphrase before the OS starts, and that's where the TinyPilot comes into play. So far, so good.
But those PCs are also used locally. They have attached a local keyboard and mouse, which should be no problem since the OS can easily handle multiple HIDs (that is, the "simulated" mouse and keyboard from the TinyPilot in addition to the physical mouse and keyboard which is attached locally).
But those PCs also have multiple monitors attached; all ports of the graphics adapters are used. As far as I have understood, the TinyPilot only captures a graphics adapter's output signal, but does not pass it through to a monitor which is attached locally.
How can we deal with that situation? The natural idea would be to use a HDMI splitter, but I am unsure whether that would work. The TinyPilot probably supports only a limited set of resolutions, but the monitor which must be attached to the same graphics adapter port is a 4K device.
To make things as easy as possible:
Basically, we would need the TinyPilot only to operate the BIOS and to enter the HDD decryption passphrase. That is, we do not need it after the OS has started, which in turn means that it does not need to support high resolutions. However, the TinyPilot must somehow be attached to a HDMI port together with a high-end monitor, and of course must not keep the monitor from using its native resolution (e.g. 4K) when the PC is used locally (except during the boot process of course).
We are grateful for any advice.
Thank you very much in advance,
Gorn
Linked from:
David @david2022-11-28 15:23:18.445ZHi Gorn, thanks for your interest in TinyPilot and those questions!
Before trying to answer your questions on security, can I ask whether the HDMI splitter delivering a 4K signal to the monitor is a hard requirement?
Splitters output the highest resolution that both devices support. And TinyPilot supports up to 1080p at 50Hz. So the other monitor attached to the splitter would receive a 1080p signal, too, rather than 4K. In that instance, I'm not sure that TinyPilot is suitable for your use case. Having said that, an HDMI switch (where a user manually toggles between devices receiving the signal) may fit your use case.
Hi David,
thanks for your reply.
Before trying to answer your questions on security, can I ask whether the HDMI splitter delivering a 4K signal to the monitor is a hard requirement?
The splitter itself isn't a hard requirement yet, letting apart its resolution :-) It was just our own idea about one possible solution to our problem. We are open to every other suggestion as well. I guess it would be possible to replace the graphics adapter in the respective PC by a different model with more ports so that the TinyPilot can be attached to a port on its own; then we wouldn't need a splitter.
Having said this, the question regarding the security is more important. It is of utmost importance that nobody can spy on any part of the connection we make to the TinyPilot. We still haven't understood which ports it listens on, which of those ports are secured by TLS, and which TLS versions and cipher suites are used. We have some experience with Linux systems, though, so if the O/S the TinyPilot runs is Linux-like, we surely can configure its web server as desired. But that wouldn't answer which other ports are open and how they are encrypted.
Could you please provide a brief list of all ports which the TinyPilot listens on in the default configuration, and shortly explain what purpose each port serves, how it is encrypted and whether it can be turned off or configured? If that information is provided elsewhere, could you please give the link? Maybe we've missed it.
Best regards,
Gorn
David @david2022-11-29 16:17:11.940ZOk great! An HDMI switch is the most straightforward option if user interaction is acceptable.
TinyPilot's OS uses Debian 10 (Buster) as its base. As for security, TinyPilot encrypts all its communication with the browser over TLS.
TinyPilot's web application serves over TLS 1.2. It sends all keyboard & mouse input through the encrypted TLS tunnel and receives the display output via TLS too.
By default, the TinyPilot Pro web application does not serve without TLS. However, it is possible to enable plaintext support in the security settings.
Here's the list of external-facing TCP ports used by default:
- 443 - HTTPS
- 80 - HTTP (only listens to redirect to HTTPS)
Debian has a few external-facing UDP ports that listen by default too:
- 68 - [udp/bootpc]
- 546 - [udp/dhcpv6-client]
- 5353 - [udp/mdns]
- 46153 - [udp/*]
SSH access is disabled by default (port 22). But you can enable SSH in the web interface's security settings.
TinyPilot runs
nginxwith a custom cipher list:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;You're free to reconfigure the server, but the modifications you make may be overwritten if you update the TinyPilot software.
I hope that helps answer your questions about security. Please let me know if you have any other queries!
Thank you very much for your precise and clear reply. That is exactly what we wanted to know. Debian buster is fine for us because it runs on some of our servers, and we know how to cope with it. Now we'll probably buy one of your devices (and enable SSH and disable all of the other ports except HTTPS).
One last question, though: Debian Buster is no longer supported by the Debian project and won't receive security updates any more. What is your policy in such cases? Will you update the O/S to the newest version in a timely manner? Not talking just about Bullseye here, but about future versions as well (Debian 12, 13, 14 and so on).
Thanks again,
Gorn
Michael Lynch @michael2022-12-05 20:57:37.948Z2023-01-23 20:20:28.544ZDebian Buster is no longer supported by the Debian project and won't receive security updates any more. What is your policy in such cases?
Yes, we're currently in the process of migrating to Debian Bullseye. Migrating to Bullseye is a top priority for us, and we expect to complete the transition in early 2023.
We actually use a fork of Debian that's optimized for the Raspberry Pi called Raspberry Pi OS Lite (formerly Raspbian). The Raspberry Pi OS maintainers are continuing to update Raspberry Pi OS Buster until June 2024.
In the future, we plan to migrate to the latest OS before any upstream Debian OS version reaches end of life. The Buster -> Bullseye transition is TinyPilot's first OS version update, so it's taking a little longer than we'd like. There were also significant changes in TinyPilot-critical OS APIs between Buster and Bullseye, so that's adding to the complexity of this upgrade, but we'll definitely get there soon.
Update (2023-01-23): We expect to ship a Bullseye-based TinyPilot image in about one month.