Add checks for Frankencerts style bugs about nogotofail HOT 2 OPEN

Hi Chad,
In addition to Frankencerts, could we have some attack scenarios where we can detect whether the client-side implementation is robust enough?

• broken / incomplete certificate chain (https://community.qualys.com/thread/12831)
• Incorrectly ordered cert. chain (leaf node is not the site cert. etc.)
• Incorrect Basic Constraints (e.g. CA=false for intermediate certs)
• Incorrect hostname validation (using CN, instead of DN
• Handling wildcard certs.
• Known Http Client API used? (Anyway to find out? ... Android, Apache etc.)
• Acceptable Cypher Suites used.
• Issues with certificate validity period (used outside of the valid start & end date)
• deference to CRLs (optional)

I am ready to help if you can through some light & provide a rough direction. Sorry for the long list but unfortunately I could not find any other tool similar to nogotofail for this purpose.

Thanks for contributing your efforts to the community.

Thank you and regards,
Dashmesh

from nogotofail.

Yes, arguably most the TLS attacks done by nogotofail are generally robustness related. Though we limit nogotofail to robustness issues that lead to security issues and not connectivity issues, a client that doesn't work at all is secure ;).

As to your specific ideas:

broken / incomplete certificate chain (https://community.qualys.com/thread/12831)

I don't think this is actually a problem, clients are allowed to have certificates caches or similar features . If the server sends the chain L -> I_1 -> I_2 -> R and ntgf were to remove I_2 the client accepting such a chain doesn't mean the client is incorrect (though a client that doesn't do any chain verification would accept such a chain we already have the selfsigned attack to detect that).

Incorrectly ordered cert. chain (leaf node is not the site cert. etc.)

The only requirement of ordering in the bag of certs from the server is that the first is leaf, otherwise the rest of the chain can be completely out of order (and even full of unused certificates) and the client should correct build the chain from that.

Acceptable Cypher Suites used.

We do have some checking for insecure suites currently, InsecureCipherDetectionHandler. I prefer to keep nogotofail targeting specifically insecure things and not warning when things are outside of best practices (unless that makes them insecure).

As for the rest they fall into the set of tests that require a trusted CA to mount, like frankencerts style testing. Nogotofail normally operates under client modification not being required for tests, but that's not possible with CAs. I'm OK with allowing tests that do require some client modification, but such tests should only be available to run if the client modification is done because otherwise they all degenerate into equivalence to the selfsigned CA test.

The other pitfall with adding more TLS tests is that we're starting to get to the point where we have too many tests for the currently selection logic that does equal weighting between all tests. Arguably we've already hit that point with the addition of tests like CCS and heartbleed that realistically shouldn't be running as often as more common issues like selfsigned/invalidhostname.

That said, for attacks that aren't enabled by default I'm pretty open, you could look at expanding the CA functionality used by selfsigned to support more kinds of certificate and certificate chain issues in some new (not on by default) handlers. You'd want to make sure that a different CA is used from the self-signed CA (that one should always be untrusted), but simply creating another CA that is intended to be trusted probably fine.

from nogotofail.