Skip to main content

Replaying Traces

tlspuffin creates fuzzing inputs using high-level protocol abstractions. Such an input is a trace of the messages sent to the different agents. Unlike standard fuzzers that can simply submit the generated inputs to the program under tests, executing a trace is a more involved process, including:

  • spawning the network agents involved in the trace
  • building protocol messages
  • transferring messages to agents
  • reading and parsing the outputs generated by the agents

Therefore, tlspuffin provides the ability to store all these steps in a .trace file and execute them on demand.

Executing a Trace​

Through the tlspuffin CLI, the execute command provides a simple way to execute a trace:

./target/debug/tlspuffin execute 'seeds/tlspuffin::tls::seeds::seed_successful.trace'
Trace Validity

Not all traces are valid traces in the sense of the protocol under test. In particular, while fuzzing it is likely to generate invalid traces due to malformed or out-of-order messages. When trying to execute an invalid trace, the execute command will signal whether the execution finished successfully and provide hints about the error encountered in case of failure.

Replaying Against a Real Entity​

While it is useful to let tlspuffin spawn the agents involved in a trace, the communication between these agents is made through a harness interface wrapping the library under test. Using the CLI tcp command, it is also possible to replace the first agent of a trace with a real entity connected through TCP.

For example, one could start an OpenSSL server on port 44410:

openssl s_server -key tlspuffin/assets/alice-key.pem -cert tlspuffin/assets/alice.pem -accept 44410

And replay one of the seed traces against this server:

./target/debug/tlspuffin tcp --port 44410 'seeds/tlspuffin::tls::seeds::seed_client_attacker_full.trace'