skip to content

Which properties of SSL 2.0 mean that a peer offering it cannot be made safe by configuration alone?

level: middleimportance: nice to knowfreq 30%

answer

  1. structural, not a configuration setting
  2. MD5-based message authentication
  3. handshake edits nobody detects
  4. one key protects both jobs
  5. an injected FIN ends it silently

basics

~20 s

SSL 2.0 authenticates messages with an MD5-based construction, leaves the handshake unprotected so an intermediary can silently weaken the agreed suite, uses one key for both authentication and encryption, and lets an injected TCP FIN end a session undetectably.

solid answer

~40 s

`RFC 6176` lists the defects and they are structural, not configurable. Message authentication is built on MD5. The handshake messages are not protected, so an intermediary can edit the offered cipher specification list and push both peers onto a weaker choice with nothing at the end of the handshake to reveal it. The same key material protects both encryption and message authentication, so an export-weakened cipher weakens integrity along with confidentiality. And a session can be ended by an injected TCP FIN indistinguishably from a legitimate close, because there is no in-protocol end-of-data signal — the role that `close_notify(0)` later plays. Hence the prohibition: clients must not send the SSL 2.0 CLIENT-HELLO format, and servers must not reply with an SSL 2.0 SERVER-HELLO.

code

pseudocode · 9 lines
pseudocode
an intermediary on the path, SSL 2.0:

    read the CLIENT-HELLO
    remove every strong entry from its cipher specification list
    forward the shortened list unchanged in every other respect

    # the handshake messages are not protected and no transcript
    # check runs at the end, so neither peer ever learns the
    # list was edited: both believe the weak suite was the best offered

go deeper

for a junior

Know that SSL 2.0 is prohibited outright rather than merely dated, and that the reasons sit in the protocol's structure where no setting can reach them.

for a middle

Name the four properties and say what each one costs: an MD5-based construction, an unprotected handshake, one key for two jobs, and no end-of-data signal.

for a senior

Bring out the operational edges — a peer still emitting the old hello format, and a truncated batch that looks complete because nothing signals the end of data.

for a principal

Use it as the reference case for structural risk: when a defect sits below every negotiated parameter, the only lever left is refusing the protocol, and that becomes a counterparty programme.

## Why this version is prohibited rather than discouraged Most protocol hardening is a matter of turning options off. SSL 2.0 is the case where that does not work, because the defects `RFC 6176` records are in the shape of the protocol rather than in the options it offers. Four of them matter, and each closes a different escape route. ### 1. Message authentication built on MD5 The integrity construction is keyed on MD5. There is no negotiation that replaces it, so no configuration reaches it. ### 2. An unprotected handshake The handshake messages are not themselves protected, and there is no check at the end of the handshake that both peers saw the same messages. An intermediary can therefore strip strong entries out of the offered cipher specification list and forward a shortened one; both peers complete the handshake believing the weaker choice was the best available. Later versions close this by binding the whole handshake transcript into the final messages, so any edit is detected before application data flows. ### 3. One key for two jobs The same key material is used for message authentication and for encryption. This is the flaw that makes the export-weakened suites of the era worse than they look: deliberately shortening the key so the cipher could be exported also shortened the key protecting integrity. Confidentiality and integrity fail together rather than independently. ### 4. A session that can be closed by anyone There is no in-protocol signal that the sender has finished sending. An attacker who injects a TCP FIN ends the session, and the receiver cannot distinguish that from a peer that finished normally — so a truncated exchange looks complete. Later versions give the sender an explicit alert for this, `close_notify(0)`, so a connection that ends without it is recognisable as an abrupt end. ## The prohibition, precisely `RFC 6176` does not merely advise against the version. It states that clients must not send the SSL 2.0 CLIENT-HELLO message format, and that servers must not reply with an SSL 2.0 SERVER-HELLO. That first clause catches deployments that think they are unaffected: the SSL 2.0-compatible hello format was for years the way a client announced support for higher versions to peers that might only understand the old format. Emitting it is prohibited even when the client's intention is to negotiate something modern. ## What this means for a long-lived bus | defect | why configuration cannot reach it | what later versions do instead | |---|---|---| | MD5-based message authentication | not negotiable | the construction is negotiated and replaceable | | unprotected handshake messages | no option enables protection | the handshake transcript is bound into the final messages | | one key for authentication and encryption | the derivation is fixed | separate keys per direction and per purpose | | no end-of-data signal | nothing to turn on | an explicit `close_notify(0)` alert | A settlement bus is exactly the environment where the truncation point bites hardest. If a batch can be cut short without either side noticing, the failure is not a broken connection but a silently incomplete set of instructions, and the difference between those two is what an auditor will ask about. ## How to answer the interview version of this - Lead with the fact that the defects are structural, then name them. An interviewer is checking whether you can distinguish "this option is weak" from "this protocol has no way to be strong". - Name the shared-key point explicitly, because it is the one most candidates miss and it explains why the export-weakened suites of the period were worse than their key length alone suggests. - Mention the prohibition on the hello format. It is the part with an operational consequence today: a peer that still emits the old hello format is doing something prohibited even if it never negotiates the old version. - Do not reach for the general argument that broken options should be removed rather than configured. That is a separate discussion; the question here is which specific properties left nothing to configure. ## The contrast that makes it stick SSL 3.0 had one identifiable rule that turned out to be fatal — the unverifiable CBC padding — and it still had to be withdrawn. SSL 2.0 has several, spread across authentication, negotiation, key derivation and session termination, with no negotiated parameter between them and the operator. That is why the response to it is a prohibition on the message formats themselves rather than a recommendation about what to enable.

  • Why is the prohibition written against the CLIENT-HELLO format and not only against negotiating the version?
    Because the SSL 2.0-compatible hello format was widely used as a way to offer higher versions to peers that might not understand the newer format. A client can emit it while intending to negotiate something modern, so `RFC 6176` closes the format itself rather than only the outcome.
  • Which of these defects do later versions repair with a handshake transcript check?
    The unprotected handshake. Binding the transcript into the final handshake messages means any edit an intermediary made to the offered parameters produces a mismatch, and the handshake fails before application data flows. The other three defects are repaired by different means.
  • What is the practical consequence of having no in-protocol end-of-data signal?
    A truncated exchange is indistinguishable from a complete one. An attacker who injects a TCP FIN cuts the stream short and the receiver treats what it has as the whole message. Later versions give the sender an explicit `close_notify(0)` alert, so an end without it is recognisable.

A contract where one signature authorises both the amount and the recipient: weaken it for either purpose and you have weakened it for both at once.

saying these in an interview costs you the question

  • Says SSL 2.0 provides no message authentication at all
  • Thinks disabling weak suites makes SSL 2.0 acceptable
  • Believes the handshake is protected by the record layer
  • Assumes export-weakened keys affected only confidentiality
  • Treats the old hello format as harmless compatibility