A penetration test reports that the appliance's management web service still negotiates an obsolete TLS version with any client that asks for it. What is the correct hardening response for the management services?
Select an answer to reveal the explanation.
Short Explanation
A server's protocol list is your configuration, not the client's. If a scanner can talk an old TLS version out of the box, it's because the box is still offering it - disable the legacy versions where the platform gives you that knob. Isolating the port shrinks the blast radius, sure, but it doesn't remove the flaw.
Full Explanation
TLS endpoints advertise the versions they will accept, and a service still advertising deprecated versions can be dragged into weak handshakes by any client that asks. Hardening means editing what the services offer - restricting to current TLS versions wherever the platform exposes the control - so the finding is removed at its source and a rescan shows refusals. Management interfaces are reachable by design, so whatever they negotiate is surface an attacker studies. Version selection being purely client-side misreads the handshake: a compliant server refuses versions it doesn't support, and an obsolete offer is a server-side fact, not a client entitlement. Isolating to a jump host is defense-in-depth, not remediation - the weak handshake still answers anyone who reaches the port, via a compromised bastion or a forgotten route, and the finding stands as written. Certificate key length governs the authentication chain, not which protocol versions are enabled, so a long RSA key behind an obsolete TLS leaves both findings alive. Exam caveat: TLS control exposure varies by release - confirm what your version lets you disable, and verify legitimate browsers and API clients still connect after tightening. Operational check: rescan the management port, confirm the deprecated versions are refused, and confirm the approved browser still reaches the GUI cleanly.