Skip to content

F-3.4: STRIPTLS Downgrade Attack on RPC-with-TLS

Classification

  • Severity: High
  • CVSS Vector: Network / Medium Complexity / Requires MITM Position
  • Affected Versions: NFS servers supporting RPC-with-TLS (RFC 9289)
  • RFC Reference: RFC 9289 §6.1.1
  • Prerequisite: On-path attacker between NFS client and server

Summary

RFC 9289 defines RPC-with-TLS as an opportunistic TLS upgrade for NFS connections. The initial AUTH_TLS probe occurs in cleartext, making it vulnerable to a STRIPTLS attack: an on-path attacker can modify or drop the probe to force the connection to fall back to unencrypted NFS, negating all TLS protections.

Technical detail

The AUTH_TLS handshake

Per RFC 9289 §4.1, the TLS upgrade sequence is:

1. Client → Server:  NULL RPC with AUTH_TLS credential
2. Server → Client:  Reply with STARTTLS verifier (if TLS supported)
3. Client ←→ Server: TLS handshake begins
4. All subsequent traffic is encrypted

Step 1 occurs in cleartext. An on-path attacker can:

Attack 1: Drop the AUTH_TLS probe

Client → [Attacker drops AUTH_TLS probe] → Server
         [Attacker sends AUTH_NONE probe]
Server → [Reply: AUTH_TLS not supported] → Client
Client falls back to plaintext NFS

Attack 2: Modify the reply

Client → Server: AUTH_TLS probe (cleartext)
Server → Client: STARTTLS reply (cleartext)
         [Attacker modifies reply to AUTH_REJECTED]
Client sees: TLS not supported, falls back to plaintext

RFC 9289 §6.1.1 (exact quote)

"The initial AUTH_TLS probe occurs in cleartext. An on-path attacker can alter a cleartext handshake to make it appear as though TLS support is not available."

AUTH_SYS remains broken even with TLS

RFC 9289 §6.3:

"The use of AUTH_SYS with peer authentication is problematic because AUTH_SYS does not include a secure user authentication mechanism."

TLS only protects the transport. If AUTH_SYS is used over TLS, the server still trusts client-asserted UIDs/GIDs — the identity attacks are unchanged.

Mitigation: DANE/TLSA

RFC 9289 recommends DANE (DNS-Based Authentication of Named Entities) via TLSA records. If the client has a TLSA record for the server, it can detect the STRIPTLS attack because the non-TLS connection won't match the expected certificate.

However, DANE deployment is extremely rare.

Impact

  • Complete bypass of RPC-with-TLS encryption
  • All NFS traffic remains in cleartext (handles, credentials, file data)
  • Servers that rely on TLS as their only security upgrade are fully exposed
  • AUTH_SYS identity attacks remain possible even if TLS succeeds

Detection (nfswolf)

nfswolf's scanner: 1. Probe for AUTH_TLS support (send NULL RPC with AUTH_TLS credential) 2. Check DNS for TLSA records (DANE) 3. Flag TLS-capable servers without DANE as STRIPTLS-vulnerable 4. Note that AUTH_SYS over TLS provides transport security but not identity security

Remediation

  1. Deploy DANE/TLSA records to prevent STRIPTLS
  2. Require TLS on the server side (reject non-TLS connections)
  3. Use RPCSEC_GSS (krb5p) instead of AUTH_SYS over TLS — provides both transport and identity security
  4. Network segmentation — reduce the attack surface for on-path positions