312-50 Question 472
Single answer▪ Cryptography Attack CountermeasuresA financial services company exposes an internal web application over HTTPS for remote employees. During a security assessment, you observe that the server still supports TLS 1.0 and several CBC-mode cipher suites. You successfully demonstrate a proof-of-concept that recovers portions of an authenticated user's session cookie by exploiting weaknesses in legacy TLS handling. Management asks for the most effective countermeasure to reduce the risk of this type of cryptographic attack without relying on user behavior changes. Which action should the security team take first?
- A
Disable TLS 1.0/1.1 and weak CBC-based cipher suites, and enforce TLS 1.2 or TLS 1.3 with strong cipher suites
- B
Increase the RSA certificate key length from 2048 bits to 4096 bits while keeping the current TLS configuration
- C
Replace the current server certificate with a wildcard certificate issued by a different public CA
- D
Force users to change their application passwords every 30 days to limit exposure if cookies are intercepted
Show answer and explanation
Correct answer: A
Explanation
This question tests whether the candidate can distinguish between certificate management, authentication hygiene, and actual cryptographic attack countermeasures. In a real environment, if an assessor demonstrates cookie recovery or session compromise tied to legacy TLS support and CBC-mode weaknesses, the most effective remediation is to harden the TLS configuration: disable deprecated protocol versions, remove weak cipher suites, and enforce modern cryptographic standards. Current best practices from sources such as NIST guidance on TLS configuration and industry recommendations from organizations like OWASP emphasize using modern TLS versions and strong cipher suites, while deprecating legacy protocols and weak algorithms. The key CEH takeaway is to mitigate the root cause at the protocol and cipher level rather than relying on unrelated measures like larger certificate keys, CA changes, or password rotation.
- A. Correct.
Correct. The scenario describes a practical countermeasure against attacks that exploit weaknesses in older TLS versions and legacy cipher handling, such as CBC-related issues in deprecated configurations. The most effective first step is to disable obsolete protocol versions like TLS 1.0/1.1 and remove weak cipher suites, then require modern TLS 1.2 or TLS 1.3 with strong suites. This directly mitigates the attack surface at the cryptographic protocol layer rather than treating a symptom elsewhere.
- B. Incorrect.
Incorrect. Increasing RSA key length may marginally strengthen resistance to brute-force attacks against the certificate's private key, but it does not address protocol-level weaknesses in legacy TLS versions or insecure cipher suite selection. A candidate might choose this because larger keys sound more secure, but the demonstrated attack targets transport negotiation and cipher behavior, not RSA key factorization.
- C. Incorrect.
Incorrect. Changing to a wildcard certificate or using a different certificate authority does not mitigate attacks caused by weak TLS versions or vulnerable cipher suites. The trust chain and certificate scope are separate from the protocol weaknesses being exploited. This distractor reflects a common misconception that certificate replacement alone fixes all HTTPS-related issues.
- D. Incorrect.
Incorrect. Password rotation does not prevent session cookie recovery through cryptographic weaknesses in the transport layer. Even if passwords are changed regularly, an attacker who can recover or hijack active session material may still gain unauthorized access. This option focuses on account management instead of eliminating the cryptographic weakness that enabled the attack.