TLS stacks have had their fare share of problems in the last few years, from simple failures such as Heartbleed and gotofail to cryptographic flaws such as the ever re-emerging problems with mac-then-encrypt cipher suites.

To enable developers and security researchers to test and detect protocol flaws, a number of fuzzing & testing suites have emerged; tlsfuzzer (python), tls-attacker (java), scapy-ssl_tls (python), flextls (python).

What these fuzzers allow you to do is to create custom error modes in the protocol handling, creating a server or client that misbehaves, and then add code to detect if the other side is responding in an incorrect manner.

Assured Ninja Peter Magnusson boldly set out to test if AES_GCM suites' authentication tag actually is being checked by a target platform, and was surprised to realise the first fuzzers I looked at haven't implemented it. As a java / C developer, the obvious choice would seem to be to modify tls-attacker, but I figured "learning" Python was a better choice as a personal learning experience, and I imagined a scripting language such as Python is far more popular among security researchers. I had a very brief look at scapy-ssl_tls but gave up, and then re-focused on Hubert Kario's tlsfuzzer.

TLSFuzzer overview

• An exceptionally easy to understand fuzzing framework, with a clear directory structure: attacks and proof of concepts under /scripts, library code base under /tlsfuzzer, and unit-tests under /tests.
• Mostly Python-2.7 compatible, but the unit tests require Python-3.
• The source code is quite easy to comprehend (considering how complex tasks it carries out), so extending it is not unnecessarily complicated.
• Logically split between tlsfuzzer (the fuzzing framework) and tlslite-ng (the tls stack modified by the fuzzer) which makes the source code easier to comprehend.

Patching TLSFuzzer

Basically I did the awesome thing and fiddled around in the fuzz-mac scripts, made an option for fuzzing AEAD messages. The hardest thing was to understand tlslite-ng structures, but overall it was pretty straight forward, even if I admittedly barely understood my patch and Python :) Created a github pull request (tlsfuzzer #40). Then there was couple of rounds with feedback from Kario, and the patch was significantly refined and generalised to allow fuzzing any ciphertext from any suite. Additionally I created a unit test, which for some silly reasons were way harder than actually creating the new feature, and actually made me understand tlslite-ng and tlsfuzzer quite a bit more!

Final words

So, making custom tests for TLS stacks is getting easier. From my experience tlsfuzzer seems an excellent platform to choose for development, due to being actively developed, having very simple structure to projects and easy to read source code. And submitting patches to github was great, getting useful feedback.