Subject: [TLS] Network middlebox corrupting TLS session resumes

From: [email-masked] (Martin Rex)
Date: Fri, 9 Feb 2018 20:45:24 +0100 (CET)

Hi,

During the analysis of a recent customer support call, I determined
from a wireshark/network trace that the cause of unexpected failures
of TLS session resumption handshakes were caused by some broken
network middlebox, which allegedly was configured for "SSL inspection".

I would like to know whether this problem is visible on the telemetry
data collections of any browser folks.

The network middlebox was seemingly *NOT* doing MitM-Attacks on the
connection, because the full handshakes with (remote 3rd-party) servers
succeeded just fine with genuine TLS server certs.

I noticed what looked like three subtly different kind of failures,
but only got the wireshark trace of one of these for analysis.

TLS session resumes were corrupted by that "SSL inspecting"
network middlebox in the follwoing fashion:

  (1) non-critical (but negligent) corruption:
      the protocol version number of the TLS record that carries
      ServerHello was changed from (3,3) to (3,1) by that
      network middlebox on TLS session resume attempts.
      This change did not occur on TLS full handshakes, and the
      genuine server sends (3,3) at the record layer both times.

  (2) fatal corruption:
      the 5-byte TLS record header of the ChangeCipherSpec handshake
      message was missing (removed from the network stream). and
      the remaining content byte (01) is obviously not a valid start
      of a new TLS record, causing our TLS client to abort the handshake
      with a fatal TLS illegal_parameter alert (although it seems
      that the appropriate alert would be decode_error).

      The genuine server was sending the TLS record with ServerHello
      and the TLS record with ChangeCipherSpec in the same
      TCP segment and IP datagram (152 bytes on the wire),
      and the filtered response that went through that network
      middlebox was just 147 bytes on the wire, with the
      5-byte TLS record header of ChangeCipherSpec missing.

-Martin

---

From: David Benjamin <[email-masked]>
Date: Fri, 09 Feb 2018 20:02:11 +0000

I don't think we've observed this particular issue. We have observed
middleboxes which, when they see a ServerHello they can't parse (such as
the pre-draft-22 TLS 1.3 ServerHello), drop the ServerHello record on the
floor, but pass through any following application_data records as-is.
That's similar to your (2), though not quite as we didn't observe the
record headers getting mangled. (TLS 1.3 did not include a CCS then, so I
don't know if it would have mangled a CCS's record header.)

I think if there's anything I've learned from this mess, it is that there
are no bounds on how badly broken middleboxes are. We've seen middleboxes
that break when we change our cipher suite preferences, because they
suddenly start detecting our ClientHellos as SIP messages! (Yes, SIP. The
text protocol.)

David

On Fri, Feb 9, 2018 at 2:45 PM Martin Rex <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>