At which layer can I capture TCP SYNC-ACK, the ciphers selected by the server and the client and ser

NTDEV
1

Hello,
I am writing a WFP kernel mode component and I am still learning about windows filtering platform.
I want to capture certain details about a TLS connection when the TLS connection is being established.
I would like to capture

  1. TLS version
  2. The cipher selected by the server (I need to capture the Server Hello at the client for this I guess)
  3. The certificate details
    I would like to know in which layer can I capture this information
    FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4 - will this layer give me the needed information?
    Thanks in advance.
2

A TLS connection is just a straight TCP protocol. I would think you’d want FWPM_LAYER_STREAM_V4, although you will probably need the FLOW_ESTABLISHED notification so you know about new connections. Remember that TLS can occur on any TCP port.

3

Thanks Tim.

I was looking at MSDN link https://docs.microsoft.com/en-us/windows/win32/fwp/tcp-packet-flows and I can capture the ciphers which the client sends to the server at FWPM_LAYER_ALE_AUTH_CONNECT_V4. However the server in SYNC-ACK sends the cipher it has selected and also the certificate. I would like to capture that information. Also the TLS version, I did not find this info in any of the ALE layers, especially when the client gets Server Hello message. I thought that FWPM_LAYER_STREAM_V4 will be useful once the handshake is complete. Please let me know if FWPM_LAYER_STREAM_V4 can be used to capture Server Hello message.

4

… Also the TLS version, I did not find this info in any of the ALE layers, especially when the client gets Server Hello message. I thought that FWPM_LAYER_STREAM_V4 will be useful once the handshake is complete. Please let me know if FWPM_LAYER_STREAM_V4 can be used to capture Server Hello message.

TLS is not part of the TCP protocol, it’s a separate layer that passes over a TCP socket. So, the TLS handshake shouldn’t even begin until the TCP connection is totally established, and the TLS exchange should just appear as normal TCP traffic. That’s why I would expect it in FWPM_LAYER_STREAM_V4.

However, I freely admit there are things in the filtering platform that don’t match my expectations.

5

You may also use *INBOUND_TRANSPORT_V4/V64 and *OUTBOUND_TRANSPORT_V4/V6 I suppose.

Since TLS 1.3 encrypts all communication after ServerHello, it might be difficult to capture the certificate.

6

Thanks Martin and Tim, I would like to have some more information on the order in which callouts are called and I am not getting an MSDN reference for the same. For example, after a TCP connect, which callout gets called first and the subsequent callouts which get called after that.

Tim I guess you are saying that once the flow is established, I need to monitor the FWPM_LAYER_STREAM_V4. I will proceed in that direction.

Martin, thanks for pointing out about TLS 1.3, will the inbound transport V4 give me unencrypted certificate?

7

No, according to RFC 8446 (TLS 1.3), all handshake messages after the ServerHello are encrypted.

As far as I know, the inbound/outbound transport layers just give you the incoming/outgoing data as packets whereas stream layers allow you to treat them more as stream. I suggested the inbound/outbound transport layers since I have some experience with them.