-
Notifications
You must be signed in to change notification settings - Fork 418
Add checks for Frankencerts style bugs #5
Comments
Hi Chad,
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, |
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:
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).
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.
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. |
We found some fun stuff in the frankencerts paper(http://www.cs.utexas.edu/~shmat/shmat_oak14.pdf) and should look into adding tests for similar issues here.
To really test for these kinds of issues however you'll need to control a CA trusted by the device. So far we've avoided adding tests that require device modification but it could be a useful thing to add so long as we make sure trusted CA tests are only run on clients that trust the CA controlled by nogotofail(separate from the one used for the selfsigned certs, which must not be trusted).
The text was updated successfully, but these errors were encountered: