TLS payload goes into tls.pcap only appears after significant delay

[alongir]

After running many tests, I come to the following conclusions:

1. Tracer behavior isn't predictable
2. It does show (sometimes) payload related to openSSL and crypto/tls.
3. Often, payload appears in pcap.tls after a very long time.
4. Often payload is completely ignored for a long time and then appears
5. I can't be sure all traffic intercepted traffic appears there.

You can use this command for testing:

k apply -f https://raw.githubusercontent.com/kubeshark/sock-shop-demo/master/deploy/kubernetes/tls-demo.yaml

Hint: you can check the containers logs, to see the TLS payloads:

[iluxa]

https://github.com/kubeshark/tracer/pull/24 can help for better debugging this issue.

Idea is to have circullar buffer tls_last.pcap pipe alongside with existing tls.pcap with different behaviour: once reading of this new pipe is requested, for example:

find /var/lib/kubelet/pods/ -iname "tls_last.pcap" -exec cat {} > /home/docker/tls_last.pcap \;

tracer dumps all packets from the circular buffer and closes the pipe.

Current existing issues in tracer related to tls.pcap:

• tracer doesn't handle broken pipe error and doesn't reopens the pipe. So, if consumer reopens pipe - new packets can not be received till tracer restart
• pcap format is file oriented format, for example it has file header in begin which can be properly handled by consumer.

I would propose some new packet interface between tracer and consumer, which can resolve above issues:

• it must be stream-oriented
• should has reentrancy support

This can be, for example, unix socket with some simple protocol

[alongir]

https://github.com/kubeshark/tracer/pull/24 shows there's no issue with the tracer. It also provides confident int he tracer implementation. Hopefully https://github.com/kubeshark/tracer/pull/25 will fix this one as well.