If there's no client certificate, either "access_denied", "bad_certificate", or "certificate_unknown". (I'd suggest the first, since without a certificate you won't grant access.)
Your TLS implementation *can* check the status of the certificate before it's even ever passed to the application layer. Even OpenSSL can. (http://portal.acm.org/citation.cfm?id=1564124&dl=GUIDE&coll=GUIDE has a bunch of information on how the authors of that paper implemented path checking.) libpkix is designed to plug into other libraries as an easy way to get path verification, including the "telepathy" that you claim that TLS doesn't have: expired (thrown by OpenSSL by default), revoked (by CRL), revoked (by OCSP), root not trusted (thrown by OpenSSL by default). There is absolutely *NO* requirement that the client send a currently-valid certificate, and it's up to the server to detect that. What people don't recognize about TLS is that there is no maximum time specified in the protocol for TLS establishment. This means that servers (and clients!) can take as long as they want to do whatever they want with the certs, subject only to per-client/server timeout specifications. But, if you only throw the generic "handshake_failure", how on earth is Firefox (bringing this back onto topic) supposed to know which of those five bad-certificate reasons is the real one -- and how is it even supposed to know that it's a certificate failure instead of a protocol or cipher mismatch? (Higher-security areas, such as after-sign-in areas, are reasonably expected to have a correspondingly more stringent set of cipher requirements, and not all software can be reasonably expected to implement any of the required ciphers.) NSS provides as much information as it can, including the alert sent by the remote. That's all it *can* do. If TLS implementers don't stop doing the "no oracle" thing, there's not going to be any way to fix this. (As an example of something that the user can't know about: if your servers all point to a specified consolidated OCSP server, and you decide for whatever reason that you want to mark a given certificate from another issuer that you trust as revoked and put that in the OCSP server, the client won't be able to tell that it's revoked by checking the issuer. That alone should be enough to suggest that the information that is provided in the generic "handshake_failure" is completely and utterly worse than useless, since there's any number of things that can cause it, and a lot of them aren't in the user's control.) -Kyle H 2009/10/6 Eddy Nigg <eddy_n...@startcom.org>: > On 10/06/2009 08:44 PM, Kyle Hamilton: > Well, the question here, Eddy, is: Does your TLS layer's hard require > actually produce a useful error alert, as enumerated in my earlier > email? Or does it just send the "handshake failure" alert on all > certificate failures? > > If it sends only "handshake failure", your server software is part of > the problem, and not at all part of the solution. > > > I don't think so....what would you expect in return if all the browser sends > (if at all) is "I have no certificate". > > How many different responses do you expect instead? The server has no > telepathic capabilities in order to guess if the client has > > an expired certificate > root not trusted > intermediate missing (OK, we took care of that one) > certificate revoked > no certificate at all > > You already keep track of what is > clicked by each user... how about keeping track of the failures that > each IP has, and figuring out what your system's TLS layer is sending > back?) > > > I suspect that won't help...it will be always the same. Be assured that if a > certificate was revoked and the client sends it nevertheless (because he > turned of OCSP checking for example), the system produces an error > accordingly. But those are the minority of instances. > > -- > Regards > > Signer: Eddy Nigg, StartCom Ltd. > XMPP: start...@startcom.org > Blog: http://blog.startcom.org/ > Twitter: http://twitter.com/eddy_nigg > > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
