Re: [TLS] Suspicious behaviour of TLS server implementations

[Hubert Kario <[e-mail]>]

On Wednesday, 14 September 2016 15:35:16 CEST Andreas Walz wrote:
> Hi,
> 
> >>> Hubert Kario <[e-mail]> 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