Exercise 1: Why VNC Isn't One Reliable Security Guarantee — Possible Solution
====================================================================

WHAT THIS CHAPTER SAYS
------------------------------
Per this chapter, "VNC's own security posture varies significantly by
implementation: some VNC servers have historically shipped with weak
encryption, or none at all, by default. 'VNC' isn't one single
security guarantee the way modern RDP roughly is - it depends heavily
on which specific server and client you're using and how it's
configured."

WHY THIS DIFFERS FROM RDP
------------------------------
RDP is a single, Microsoft-controlled protocol built into Windows with
encryption on by default in modern versions - describing something as
"using RDP" carries a fairly consistent baseline security
implication. "VNC" by contrast refers to a family of independently
implemented servers and clients from different vendors, each making
their own choices about default encryption and authentication - so the
name "VNC" alone doesn't tell you what security properties a given
connection actually has.

THE PRACTICAL TECHNIQUE THIS CHAPTER RECOMMENDS
------------------------------
Per this chapter's finding-box, "tunneling VNC traffic through an SSH
port forward gets VNC's real cross-platform reach combined with SSH's
own well-understood encryption and authentication guarantees." Rather
than relying on whatever security properties a specific VNC
implementation happens to have, wrapping the VNC connection inside an
SSH tunnel (directly reusing Chapter 3's own technique) guarantees a
known, consistent level of encryption and authentication regardless of
the underlying VNC server's own configuration.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains specifically why VNC's security is implementation-
dependent (multiple independent implementations vs. one controlled
protocol), and names the chapter's own recommended mitigation,
explaining why tunneling through SSH solves the inconsistency directly.