A Citrix Administrator is concerned about preventing an SSL renegotiation attack. What must the administrator do to prevent an SSL renegotiation attack against the Citrix ADC?

Question

Options

• AEnable RC4 ciphers.
• BDeploy Citrix ADC using default settings.
• CDisable TLSv1.3 and SSLv3.
• DImplement TLS_FALLBACK_SCSV.

• A
  4% (1)
• B
  92% (23)
• C
  4% (1)

Explanation

Citrix ADC ships with SSL renegotiation disabled by default in its SSL profile, meaning client-initiated renegotiation - the core mechanism of renegotiation attacks - is already blocked out of the box. An administrator who deploys with default settings inherits this protection without any additional configuration.

Why the distractors fail:

• A (RC4 ciphers): RC4 is a cryptographically broken cipher deprecated due to its own vulnerabilities (e.g., statistical biases); enabling it weakens security and has no bearing on renegotiation.
• C (Disable TLSv1.3 and SSLv3): Disabling SSLv3 is sound practice (POODLE), but disabling TLS 1.3 is actively harmful since it's the most secure protocol. Neither action specifically prevents renegotiation attacks.
• D (TLS_FALLBACK_SCSV): This mechanism prevents downgrade attacks (like POODLE forcing a client to SSLv3), not renegotiation attacks - it's the right tool for the wrong threat.

Memory tip: When a vendor's default configuration already mitigates a specific attack, the exam answer is often "don't touch it." Associate renegotiation = Citrix default protection - the safest ADC is one you haven't misconfigured away from its secure baseline.

No community discussion yet for this question.