Hacker News new | past | comments | ask | show | jobs | submit login

Disclaimer: My understanding of the goto fail bug is based on agl's writeup, and my understanding of the GnuTLS bug is limited to this article.

In both of these cases, it seems the code starts with the assumption that the cert is valid and then tries to find various conditions to invalidate it. Isn't that backwards? Why not start with an assumption that the cert is untrusted until you've proven otherwise?




That's not what happened here. The problem is that the logic of the validation predicate was broken. In fact, this bug happened after the code had determined the cert was invalid; it just signaled the error improperly.


This is an interesting question. I agree that invalid-by-default makes sense when reasoning about the higher-level system, but regarding the actual Boolean logic it seems that if a critical condition is broken the particular formulation will not make much of a difference.

Additionally, it seems that in certain situations having several plain-if conditionals set the valid state to `1` would be less robust than having several conditionals set it to `0`. In the first case if any one of the conditions have bugs the false valid state can happen, whereas in the second case the last conditional to execute would have to contain the bug.

Can anyone else comment on this? Are there relevant theories and/or best practices which have been discussed in the security community?


What about several conditionals that set various elements of a struct to 1, and the cert is valid iff all elements are 1. At least that way a skipped check (i.e. goto fail;) wouldn't result in a false positive...


So basically abstract the details of each sub-condition from the final check that all sub-conditions are met?

That does sound like a good idea as long as the meaning of `1` and `0` do not get confused, and as long as we're not talking about some niche context where extra overhead for the sake of code maintainability would be a problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: