Visual RFC.
ALL RFCs / RFC 4251
Read the RFC ↗
RFC 4251 / MECHANISMS

An unchecked key enables a middleman

03

An attacker can create two encrypted connections when the client accepts the wrong host key.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

RFC 4251 · § 9.3.4EXAMPLE
3 / 3
An unchecked key enables a middlemanAn attacker can create two encrypted connections when the client accepts the wrong host key. Current state: Trust gate.An unchecked key enables a middlemanClientServerMiddlemankey Bsecond connectionexpected key AEncryption to the wrong key protects a connection to the attacker.
03
Trust gate

A trusted host-key comparison stops the client at the wrong-key boundary.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Encryption to an attacker does not authenticate the intended server.

  • Encryption to an attacker does not authenticate the intended server.
  • A known host-key mismatch can expose the substitution.
  • Verify the server-name-to-key association before relying on authentication.
DETAILS

The illustration is schematic. Example values are illustrative; profiles and later security guidance can add requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Three layers have different jobs
  2. Host keys identify the server
  3. An unchecked key enables a middleman
  4. One transport carries channels
  5. Security has endpoint limits
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗