A scan shows your server still supports SSLv3/TLS 1.0 and RC4. What do you do?
Short answer
SSLv3, TLS 1.0, and RC4 are broken or deprecated and enable downgrade and decryption attacks, so disable them and require TLS 1.2 or 1.3 with strong, forward-secret cipher suites — accepting the rare loss of very old clients. Leaving them on for compatibility keeps the weakness exploitable. Adding a second certificate or switching to a self-signed one doesn't remove the weak protocols, and self-signed certs harm trust without fixing the cryptography.
A scan flagging SSLv3, TLS 1.0, and RC4 is reporting cryptography that the industry retired years ago. These aren't theoretical weaknesses — they have named, practical attacks — so the right move is to disable the obsolete protocols and ciphers and require modern TLS.
Why these are broken
- SSLv3 is fatally undermined by POODLE, which lets a network attacker decrypt bytes from an encrypted session.
- TLS 1.0 carries structural weaknesses (e.g., BEAST) and is deprecated by PCI DSS and major browsers.
- RC4 has biases that make recovering plaintext feasible and is prohibited by RFC 7465.
The deeper danger is the downgrade attack: even if a modern client can speak TLS 1.3, an active attacker can strip the negotiation down to the weakest option both sides still offer. As long as your server advertises RC4 or SSLv3, you remain exploitable — the mere availability is the risk.
The correct fix
Configure the server to require TLS 1.2 at minimum (prefer 1.3) and offer only strong, forward-secret cipher suites (ECDHE key exchange, AES-GCM or ChaCha20-Poly1305). Forward secrecy ensures that compromising the server's long-term key later cannot decrypt previously captured sessions. Validate the result with a fresh scan. The trade-off — losing a handful of ancient clients — is almost always acceptable and far cheaper than a breach.
Why the distractors are wrong
- "Leave it enabled for compatibility" preserves the exact weakness an attacker downgrades to; convenience for a few legacy clients exposes everyone.
- Adding a second certificate addresses identity/SAN coverage, not the protocol and cipher negotiation — the weak options are still on the menu.
- Switching to a self-signed certificate is actively worse: it breaks the trust chain (browser warnings, easier MITM) while leaving SSLv3/TLS 1.0/RC4 fully enabled. It confuses certificate trust with protocol strength.
The interviewer is checking that you fix the negotiated cryptography, understand downgrade risk, and don't mistake certificate changes for protocol hardening.
Likely follow-ups
- What attacks specifically target SSLv3 and RC4, and how does a downgrade attack force their use?
- What does forward secrecy give you, and which cipher suites provide it?
- How would you roll this out without breaking a small set of legacy clients you can't upgrade?