Reject RC4 at the server too
03A nonconforming or old client may still offer RC4. The server MUST NOT select an RC4 suite even when the peer offers or prefers it. This chapter uses a separate nonconforming client example.
Return that non-RC4 selection in ServerHello; the rest of the handshake is still pending.
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 example offer contains RC4 and an otherwise acceptable non-RC4 candidate; the first preference does not override the prohibition.
- The example offer contains RC4 and an otherwise acceptable non-RC4 candidate; the first preference does not override the prohibition.
- Server selection must also meet normal TLS rules: choose an offered suite the server supports. RFC5246§7.4.1.3 describes the ServerHello choice.
- This is a new full-handshake example, not session resumption. The selected AES-GCM example assumes matching TLS1.2 capabilities, certificate and all other requirements. The picture stops at ServerHello, not a completed authenticated connection.
- An unsupported non-RC4 offer does not authorize selecting RC4. No acceptable common suite means the handshake cannot proceed.
The drawing is a simplified worked example. Follow the linked RFC and its updates for implementation requirements.
Read the RFC section ↗