Renegotiation, Secure Renegotiation, and OCSP Stapling

Three SSL profile settings shape the handshake's safety after the first message: renegotiation decides whether a connection may renegotiate at all, secure-renegotiation enforces the RFC 5746 protection, and ocsp-stapling lets the BIG-IP attach a fresh revocation proof so clients need not phone the CA.

A TLS handshake is not always a single event. Connections can renegotiate mid-stream, and revocation has to be checked somehow. Three SSL profile settings decide how the BIG-IP handles both, and the safe defaults are not always the ones already in place.

renegotiation: should it happen at all?

The renegotiation field is simply enabled or disabled. When disabled, the BIG-IP refuses client-initiated mid-connection renegotiation. That is a deliberate and common hardening choice: it removes a class of denial-of-service amplification (renegotiation is cheap for the client, expensive for the server) and sidesteps the insecure-renegotiation problem entirely. Most public virtual servers run perfectly well with renegotiation disabled.

secure-renegotiation: the RFC 5746 guard

If renegotiation is allowed, it must be the secure kind. The original TLS renegotiation had a flaw that let an attacker splice traffic across a renegotiation boundary; 5746 fixed it with an extension that binds each renegotiation to the connection it belongs to. The secure-renegotiation field chooses how strictly the BIG-IP enforces that extension:

require-strict: the strongest. The peer must support RFC 5746 even on the initial handshake; peers without it are rejected outright.
require: the peer must support RFC 5746 to renegotiate, but the first handshake is still allowed from peers that lack it. A reasonable default.
request: the extension is requested but not enforced; a peer without it may still renegotiate. This is the weak setting, and the SSL profile explainer flags it.

The clean posture is therefore one of two things: disable renegotiation, or require secure renegotiation.

OCSP stapling: revocation without the round trip

A certificate can be revoked before it expires, and clients are supposed to check. Classic (Online Certificate Status Protocol) makes the client contact the 's responder, which is slow and leaks which sites the user visits to the CA. OCSP stapling (the status_request extension in RFC 6066) flips this: the BIG-IP itself fetches a signed, time-stamped OCSP response and staples it into the handshake. The client gets the revocation proof for free, with no extra round trip and no privacy leak. Enabling ocsp-stapling (it needs an OCSP Stapling profile to point at the responder) is a small win for both speed and privacy, which is why the explainer marks it as a positive when present.