Stop an RC4-only handshake
04If the client only offers RC4 suites, the server MUST terminate the handshake. It MAY send the insufficient_security fatal alert. These are different requirement levels.
Separate permitted alternative: terminate and send insufficient_security as a fatal alert.
Source for this drawing: RFC 7465 · Read RFC section 2 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The client in this example violates RFC7465; it is a failure demonstration, not an allowed fallback strategy.
- The client in this example violates RFC7465; it is a failure demonstration, not an allowed fallback strategy.
- Termination is mandatory. Sending this particular fatal alert is optional; the no-alert alternative still terminates.
- No RC4 ServerHello selection or application-data delivery follows the failed gate. The optional alert is not an invitation to retry with RC4.
- insufficient_security is a fatal TLS alert; the published alert semantics are in RFC5246§7.2.2. This model is a policy illustration, not a TLS record encoder.
The drawing is a simplified worked example. Follow the linked RFC and its updates for implementation requirements.
Read the RFC section ↗