In a .NET application, communication between client and service can be implemented using various different bindings, NetTcpBinding being one of them.

The class defines an attribute named Security, which, according to this article, defaults to Transport.

This further article explains how Transport works:

The NetTcpBinding class uses TCP for message transport. Security for the transport mode is provided by implementing Transport Layer Security (TLS) over TCP. The TLS implementation is provided by the operating system.

This sounds to me as if, upon connecting with a WCF Service, the client would perform a TLS handshake. However, if I watch the traffic with Wireshark 3.2.3, the traffic is only recognized as "TCP", with no TLS handshakes in sight. If there is a TLS handshake going on, shouldn't Wireshark recognize it as such? Why does it only see generic "TCP Data"?

I did some more digging after this, and discovered that NetTcpBinding in this scenario uses the .NET Message Framing Protocol, and I was able to decode the first message that went across the wire:

00 01 00

This indicated that it was a Version record, indicating version 1.0.

01 02

This was a Mode record, indicating a Duplex transmission.

02 ... ... ...

This was a Via record, which defines the URI to which subsequent records are bound.

03 08

This was a Known Encoding record, specifying that the encoding was Binary with in-band dictionary, as specified in MC-NBFSE.

09 15 61 70 70 6c 69 63 61 74 69 6f 6e 2f 6e 65 67 6f 74 69 91 74 65

This was a Upgrade Request record, which encoded the string application/negotiate, which indicates GSS-API Negotiation should be used, as defined in RFC 4178.


This was the response from the server, indicating that the upgrade request was being honoured.

I don't really know how to proceed from here, but most packets start with 16 01 00, which I assume is documented somewhere in the GSS-API or such? I honestly don't know enough about that. But I guess it's sufficient for my purposes.

  • I have seen custom wire protocols that actually have a header on every packet in front of the TLS data; anything like that going on? E.g. read(), parse header, add content past the header to the SSL context buffer, then call SSL_read(). Or, this link isn't too helpful, but maybe messing with the enabled protocols could help: ask.wireshark.org/question/14359/… You could also look at the first few packets to see if there are any plaintext strings from the client/server hello (TLS <= 1.2, SNI host, certificate details etc.) Commented May 13, 2020 at 12:16
  • @multithr3at3d I did some more investigation. Apparently, it uses .NET Message Framing, and all I could find for Wireshark support was this tweet from 2017. I guess as you correctly said, there is some envelope around it and it screws wireshark up.
    – user163495
    Commented May 13, 2020 at 12:21
  • 1
    @Z.T. I'll see if I can spin something up, but I'm in a heavily restricted environment at the moment, so don't expect miracles please.
    – user163495
    Commented May 13, 2020 at 13:13
  • 1
    @JetSetWilly As I said, I figured out that it wasn't TLS at all, but instead GSS-API, which I assume is different (or at least a wrapper).
    – user163495
    Commented May 26, 2020 at 13:04
  • 1
    @JetSetWilly I think it doesn't use TLS at all, hence why no Client Hello was sent.
    – user163495
    Commented May 26, 2020 at 14:52

1 Answer 1


Because it lacks a filter to correctly identify this protocol's data stream as being TLS. As discussed in the comments, it's not a straight-forward TLS over TCP connection.

You must log in to answer this question.