Fuzz testing is supposed to prevent bugs like Heartbleed. Why didn't it work here? Well, the problem is that encryption is a natural protection against fuzzing. Any damage to the packets will cause them to be discarded by the outer protocol layers, namely TLS' authentication checks.

In a world where everything is encrypted, the fuzzer really needs to work on the data before the encryption stage. Then it can get past the outer defenses and pound on the rest of the code that we really want to test.

This is not just an issue for TLS - it has relevance to WebRTC too, where any malformed packets will get tossed by the SRTP or DTLS layers. Again, we can avoid this issue if the fuzzer can do its mutation of the data on the send side before it goes to the encryption layer. But this means the fuzzer needs to be completely rethought - rather than something that simply changes bits on the wire, it needs to be part of the actual client.

Something to consider adding as an option in Chrome.

Shared publiclyView activity