Frank Swarbrick wrote: >https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe <https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=15416 7> &CR_ID=154167
Frank, without necessarily disagreeing with your RFE myself, note that there is a theology in security that you err on the side of less detail about a security failure, to prevent attackers from gaining information that might help them in their quest. This is why, for example, it's considered better to say "Login failed" than "No such userid". For the "expired certificate", that's clearly not the case: it's trivial to figure out which certificate is in use and whether it's expired. But are there other reasons the connection might fail that should be kept hidden? That's the real question. If there are, then the RFE is more complicated, since it's "Show me the error details *when it's safe to do so*". Having just spent a couple of months on the customer problem I wrote about here that turned out to be due to AT-TLS being turned when the z/OS client was already using TLS natively (and thus attempting double TLS without the server expecting it), I'm more than sympathetic here. And I'm not convinced there are any cases of such a connection failure that should be kept hidden. But that's the question that I suspect will get asked, so if you can head it off, your RFE might progress faster. Apologies if this is old news; it struck me when I read it that it's something I've been through many, many times: "This error is so useless!" "Yes, that's deliberate, because security." Cheers, .phsiii ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
