Port 5900: VNC — The Window Through the Wire

Port 5900 is the default listening port for VNC (Virtual Network Computing), a protocol that lets you see another computer's screen and control it with your keyboard and mouse as if you were sitting in front of it.¹ When a sysadmin fixes a server from home at 3am, when a help desk technician says "let me take a look at your screen," when your parents need you to troubleshoot their computer from across the country, that's VNC. Port 5900 carries vision.

How VNC Works

VNC uses a protocol called RFB (Remote Framebuffer), and its fundamental insight is almost comically simple: don't try to be smart.²

Other remote desktop protocols like X11 or Microsoft's RDP try to understand what's happening on screen. They transmit drawing commands: "draw a window here, put this text there, render this button." This requires both ends to understand the same graphical primitives.

RFB doesn't do that. It has exactly one graphics operation: put a rectangle of pixels at these coordinates.³ That's it. The server captures what's on screen, compresses it, and sends colored rectangles to the client. The client draws them. The protocol doesn't know or care if it's transmitting a spreadsheet, a video game, or classified documents. It just sees pixels.

This deliberate ignorance is VNC's superpower. Because it works at the framebuffer level, it runs on Windows, macOS, Linux, industrial control panels, medical devices, embedded systems, anything with a screen and a network connection.⁴ The server doesn't need special drivers or integration with the windowing system. It just reads the framebuffer and sends what it sees.

The Protocol Dance

When a VNC client connects to port 5900, they negotiate:⁵

1. Protocol version (3.3, 3.7, or 3.8)
2. Security type (none, password, TLS, or vendor extensions)
3. Pixel format (how colors are encoded: bit depth, byte order, color masks)
4. Encodings (how rectangles are compressed)

Then the client says "I'm ready" and the server starts streaming framebuffer updates. The client sends keyboard events and mouse movements. The server captures what changes on screen and sends back new rectangles.

The encodings are where the real engineering happens. Raw encoding (just send all the pixels) works but wastes bandwidth. CopyRect says "copy this rectangle from somewhere else on screen," perfect for when windows move or content scrolls. ZRLE compresses with zlib. Tight encoding gets fancy with JPEG for photographic regions. A good VNC implementation can achieve 60+ fps over a decent connection.⁶

Stateless by Design

Here's something elegant: VNC clients are stateless.³ If your connection drops and you reconnect, you don't lose your work. The server doesn't care that you disconnected. It keeps running. When you reconnect, it just sends you the current screen state and you pick up where you left off.

You can even connect multiple clients to the same VNC server. They all see the same screen. They can all move the mouse. (This gets chaotic fast, but it's useful for training or collaboration.)

The History: A Thin Client Dream in Cambridge

VNC was invented at the Olivetti Research Laboratory (ORL) in Cambridge, UK, in the mid-1990s.⁷ The lab had a fascinating pedigree: founded by Hermann Hauser and Andy Hopper after Olivetti acquired Acorn Computers (the company that created the ARM processor), it later became the Olivetti & Oracle Research Lab, then AT&T Laboratories Cambridge after AT&T's acquisition in 1999.⁸

The lead inventor was Tristan Richardson, who designed the RFB protocol and wrote the reference implementations.⁹ The project was led by Andy Harter, with contributions from Quentin Stafford-Fraser, James Weatherall, and Andy Hopper himself.

VNC wasn't the original goal. The team was working on something called the Videotile, an extremely thin client device with just an LCD screen, pen input, and a fast ATM network connection.¹⁰ The idea was radical minimalism: put all the computing power on the network, and make the device at your desk as simple as possible.

The Videotile needed a way to receive screen updates from servers. Richardson designed RFB for this purpose, optimizing for the scenario where the client is dumb and the server does all the work. The protocol was so useful that it transcended its original purpose. They realized it could connect any screen to any computer, not just specialized thin clients.

In 1998, ORL released VNC as open source software under the GPL.¹¹ This was a pivotal decision. By making it free, they ensured the protocol would spread everywhere. Anyone could implement a VNC server or client. Anyone could modify it. The RFB specification was published openly.

When AT&T closed the Cambridge lab in April 2002, several team members including Richardson and Harter founded RealVNC Ltd to continue developing VNC commercially while maintaining the open protocol.¹²

The Ecosystem: Forks and Variants

Because VNC was released under the GPL with an open protocol specification, it spawned an entire ecosystem of compatible implementations:¹³

• RealVNC: The commercial continuation by the original inventors
• TightVNC: Added better compression for slow connections (the "Tight" encoding)
• UltraVNC: Windows-focused, added features like file transfer
• TigerVNC: High-performance fork focusing on Unix/Linux
• TurboVNC: Optimized for 3D and video applications
• x11vnc: Shares an existing X11 display (rather than creating a virtual one)

The beautiful thing: they all speak RFB. A TightVNC client can connect to a RealVNC server. An UltraVNC client can control a Linux machine running x11vnc. The protocol's extensibility through negotiated encodings and security types means implementations can add features while staying compatible.

Port 5900+N: The Display Number Convention

Unlike most services that use a single port, VNC has a convention for running multiple servers on one machine:¹⁴

• Port 5900 = Display :0
• Port 5901 = Display :1
• Port 5902 = Display :2
• And so on...

This comes from VNC's Unix heritage, where X11 uses the same pattern (port 6000 for display :0, 6001 for display :1). If you're connecting to "server:1", you're really connecting to port 5901.

There's also port 5800+N for the Java applet viewer (a web page that runs a VNC client), though this has fallen out of favor as Java applets died.¹⁵

And port 5500 for "reverse connections," where the server connects out to a listening client.¹ This is useful when the server is behind a firewall that blocks incoming connections.

Security: The Elephant in the Framebuffer

VNC's security history is troubled, and honesty requires saying so plainly.

The original VNC authentication is weak. Passwords are limited to 8 characters (longer passwords are silently truncated).¹⁶ The authentication uses DES encryption with a challenge-response mechanism that, while not sending passwords in plaintext, is vulnerable to offline cracking if an attacker captures the handshake.¹⁷

More critically, the original protocol sends all pixel data and keystrokes unencrypted after authentication.³ Anyone sniffing your network can see exactly what's on your screen and everything you type.

Vulnerabilities Over the Years

Security researchers have found serious flaws in VNC implementations:

• 2019: Kaspersky discovered 37 vulnerabilities across LibVNC, TightVNC 1.X, TurboVNC, and UltraVNC, some dating back 20 years. Many allowed remote code execution through memory corruption.¹⁸
• Authentication bypass: RealVNC 4.1.1 had a flaw where clients could request "Type 1 - None" authentication even when the server didn't offer it.¹⁹
• Denial of service: Older versions crashed when flooded with connections.
• Local privilege escalation: Windows installer vulnerabilities allowed unprivileged users to gain system privileges.²⁰

The Exposure Problem

VNC servers exposed directly to the Internet are regularly scanned and exploited. Shodan searches reveal thousands of VNC servers with authentication disabled entirely, waiting for anyone to connect.²¹ In 2017, Shodan found approximately 8,000 VNC servers with "authentication disabled" accessible from the public Internet.²²

How to Use VNC Safely

Modern VNC deployments should:

1. Never expose port 5900 directly to the Internet
2. Tunnel VNC through SSH (ssh -L 5900:localhost:5900 server, then connect to localhost:5900)
3. Use VPN to access VNC servers on private networks
4. Enable TLS encryption (supported by modern implementations)
5. Use strong, unique passwords (understanding the 8-character limit)
6. Keep VNC software updated to patch known vulnerabilities

VNC is a tool for trusted networks. Treat it accordingly.

What Flows Through Port 5900

This port carries presence.

When a parent in Ohio needs help with their computer and their child in Seattle says "let me see your screen," that's port 5900 carrying the pixels. The child sees what the parent sees. They move the mouse together. They solve the problem together, separated by two thousand miles but sharing one screen.

When a sysadmin gets paged at 3am because a production server is misbehaving, they don't drive to the data center. They open their laptop, tunnel through SSH, connect to port 5900, and see the server's console. They fix the problem from bed, in their pajamas, watching the same screen they'd see if they were physically there.

When an engineer in Germany needs to support industrial equipment in a factory in China, VNC bridges the gap. They see the control panel. They adjust the settings. The machine runs correctly. No flight required.

VNC carries technical support, system administration, remote work, and human connection across arbitrary distances. It's not the fanciest protocol. It's not the most efficient. But it works on everything, it's been around for decades, and it keeps working because it solved the problem correctly the first time: just send the pixels.

Related Ports

Summary

Port 5900 is the default port for VNC (Virtual Network Computing), a protocol that transmits screen pixels and input events to enable remote desktop access. Created at Olivetti Research Laboratory in Cambridge in the mid-1990s and released as open source in 1998, VNC's simple "just send the pixels" approach makes it universally compatible but requires careful security practices to use safely.