2

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.

0a

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: https://ask.wireshark.org/question/14359/wireshark-showing-some-tls-traffic-as-tcp-and-some-as-tlsv12/ 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.) – multithr3at3d May 13 '20 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](https://twitter.com/pizza_4u/status/910957002666446851). I guess as you correctly said, there is some envelope around it and it screws wireshark up. –  May 13 '20 at 12:21
  • Can you post a capture file of making a connection and sending hello world? If TLS is encapsulated but not obfuscated, we'll see it right away. – Z.T. May 13 '20 at 12:54
  • @Z.T. I don't have a test environment with just "Hello World" at the moment, and I can't take any data off a prod system either. Sorry, I know it's shitty from me to say that, but I can't configure a new WCF service on the fly either. –  May 13 '20 at 13:10
  • We'll, if you can get something like a tutorial or msdn sample code working and post pcapng of that, it will be useful. – Z.T. May 13 '20 at 13:12
  • 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. –  May 13 '20 at 13:13
  • I also see Wireshark using TCP not TLS1.2, no sign of 'Client Hello' in the handshake, nor a 'Server Hello' back. This is a problem because I'm using Traefik in TLS mode and as far as I can tell Traefik is simply ignoring non TLS traffic wholsesale. I'm using the NetTCP binding, WCF is configured for 'Transport' security which I figured that alone would have been enough to see a 'Client Hello' - I'd then fathom out how to setup certificates best in our local network. – Jet Set Willy May 26 '20 at 13:00
  • 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). –  May 26 '20 at 13:04
  • OK good to confirm that - but I could not gleam in the bytes sent a 'Client Hello' message so if it is a wrapper then it has obfuscated the message. – Jet Set Willy May 26 '20 at 13:11
  • 1
    @JetSetWilly I think it doesn't use TLS at all, hence why no Client Hello was sent. –  May 26 '20 at 14:52

1 Answers1

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.

Pedro
  • 3,911
  • 11
  • 25