A parking-payment kiosk still allows a weak legacy TLS cipher suite that security scanners flag as outdated and breakable with known attacks. Which vulnerability type is primarily indicated?
Select an answer to reveal the explanation.
Short Explanation
Old, weak crypto left on the payment kiosk is a cryptographic vulnerability — the lock on the door is made of cardboard. Turn off legacy suites; this is not VM escape or a fake-audit phone call. Civic payment paths need modern TLS only.
Full Explanation
Cryptographic vulnerability covers weak or outdated cryptography still enabled on a service. A parking-payment kiosk that still allows a legacy TLS cipher suite flagged as breakable keeps confidentiality and integrity of payment sessions at risk despite "using TLS" in name. Disabling obsolete suites and requiring modern protocols is the direct remediation.
VM escape from a guest portal VM into co-hosted finance VMs is virtualization isolation failure. Cipher suite weakness on a kiosk is a crypto configuration issue.
Pretexting that invents a fake audit to obtain badge codes is social engineering. It does not involve TLS cipher negotiation on a payment path.
Public social misinformation about boil-water emergencies manipulates public trust. It is unrelated to weak ciphers on a kiosk.
Exam caveat: Cryptographic vulnerabilities include weak algorithms, flawed implementations, and misconfigurations like enabling legacy suites. "TLS is on" is insufficient if obsolete ciphers remain. Distinguish crypto weakness from certificate expiration (operational hygiene) though both harm transport security.
Operational check: harden kiosk TLS configurations to modern versions and cipher suites only, retest with scanners after changes, validate payment processor requirements, and include crypto posture in routine civic PCI-aligned reviews. Replace kiosks that cannot disable legacy cryptography. Payment paths deserve stricter crypto baselines than general informational sites.