Kyle, what you apparently don't seem to get here is, that users of
Firefox (but also other browsers) experience the most difficulties
BEFORE the browser even tries to send anything. The browser doesn't say
"Hey listen buddy, this server wants that you authenticate with a
client certificate, but it appears that I can't find one which is
valid and accepted by that server"
to the user, instead it sends the server
"No Cert Here"
and the server returns
"Nice try, but without a cert you can't get in"
upon which the browser tells the user
"ssl_error_handshake_failure_alert" or "-12227".
Well great, except that the browser doesn't HELP the user in any way.
Firefox *DOES NOT SEND* a certificate in case a certificate is
*Expired
Revoked
No Cert
Not matches the accepted issuers
*
All it sends is "No Cert Here". There is nothing a server can do, not
TLS and not otherwise. The server can't know that a certificate is
revoked when the client doesn't send one. And Firefox DOES CHECK if the
certificate is revoked. Neither can the server know that the client
might have an expired cert when the client doesn't send one. And Firefox
DOES CHECK the validity of the certificates before attempting to send
it. Neither does the server know if the client has some certificates but
from different issuers because Firefox DOES CHECK if it has any
certificates from the accepted list. And the server can't know that the
client doesn't have any certificates (well, that's actually the only
thing it knows really) because Firefox says that it has no cert ALWAYS.
Only the browser knows that, not the server.
On 10/07/2009 02:04 AM, Kyle Hamilton:
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
--
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
