Basically - a root of trust is something sacrosanct. If you said "use this root of trust" and somehow that fails, trying to run more code when you *know* the requested root of trust did not work is very very wrong. Do not proceed further, do not pass go, do not try to validate the certificate anyway.. No good can come of this.
And don't use the excuse they are debugging tools. if they are debugging tools they should come closer to doing the right thing. On Fri, Apr 1, 2016 at 9:58 AM, Bob Beck <[email protected]> wrote: > Yes, I mean the program should exit with an error message if the > requested CA file (either the default, or via -CAfile) can't be > loaded. > > On Fri, Apr 1, 2016 at 8:44 AM, Florian Zumbiehl <[email protected]> wrote: >> Hi, >> >>> Florian I'm happy to look at this now with you >>> >>> But based on the old discussion I'm not certain I'm happy with the >>> final result. >>> >>> IMO - here's what we need in these: >>> >>> 1) If you specify nothing, you should get the default. >>> 2) If you specify a CAfile, and there is no failure in loading it, >>> you should get that. >>> 3) If any failure occurs in either case 1 or case 2 the program >>> should fail. Do not continue with something else. >>> >>> Try for the above >> >> Well, that's what the patch does? (With the slight modification that case 2 >> also covers the CApath option, that is ...) >> >> Or do you mean that the whole program should abort instead of just warning >> that the requested CAs couldn't be loaded and then just letting the >> verification failure happen? >> >> While that in principle certainly would be sane default behaviour, I am not >> sure whether it's a good idea in this case: At least s_server and s_client >> are primarily debug tools and don't abort on authentication failure anyhow, >> but just print a message, and also, I am not sure whether the default CAs >> can always be expected to be available? >> >> The primary purpose of the patch is to make the output correctly reflect >> the authentication status relative to what the user specified, so it >> doesn't mislead the user when testing stuff, not to make it a secure TLS >> client or server for production use. >> >> Regards, Florian
