On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote: > Hi, > > >>> Hubert Kario <hka...@redhat.com> 09/12/16 6:56 PM >>> > > > > are you aware of the tlsfuzzer framework? > > https://github.com/tomato42/tlsfuzzer > > @Hubert Kario: Thanks for pointing me to tlsfuzzer. I had a look at the > repository before and I skimmed through the code. However, I didn't run the > code and I don't know details about the way it is generating input. Is > there some paper or presentation about it?
there are presentation slides in the docs/ directory Decision which messages are to be generated is done using scenarios that describe conversations between client and server. See in scripts/ for them; a simple example is scripts/test-conversation.py while an example of negative test would be scripts/test-early-application-data.py in tlsfuzzer/messages.py is the code that generates the messages, client hello is here: https://github.com/tomato42/tlsfuzzer/blob/master/tlsfuzzer/messages.py#L306 Example of a test case you were asking about (the one with data extending past extensions) would be scripts/test-truncating-of-client-hello.py The messages themselves are generated through a combination of sensible defaults and "guessing" expected values by inspecting already exchanged messages (think TLS state machine that explicitly has support for any state transitions). In general, it allows you to both negotiate connections and send arbitrary messages (through changing their order, modifying them pre or post encryption, or sending raw values). In particular, it does support renegotiation despite the the fact that the underlying tls library doesn't. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
