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'
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'