The names of the CAs accepted are already supposed to be sent as part of the negotiation. It wasn't until after TLSv1.0 that the spec permitted a wildcard CA name list.
This kind of information-leakage being a vulnerability also depends on the application being authentication-naive. A web application using Apache's optional_no_ca, which looks in the environment for the client-provided certificate chain, could process the authentication as part of the application logic without sending an SSL/TLS alert. Ralf Engelschall and Eric Young are two of the main reasons why web security is stuck in the dark ages (RSE for saying "optional_no_ca is actually against the idea of authentication" in the mod_ssl documentation, and EAY for creating the SSLeay "=====BEGIN [WHATEVER]=====" header for PEM-encoded ASN.1 structures and enforcing that there was no single ASN.1 processing path). This is compounded by the fact that few people in TLS development will listen to anybody who isn't a mathematician or who isn't already indoctrinated into the X.509 PKI Priesthood. Those few who do aren't part of the PKI priesthood, and have shoehorned themselves in to OpenPGP as the only alternative. And, of course, since I'm part of neither group, nobody listens to me either. -Kyle H On Sun, Jul 31, 2011 at 7:06 AM, Martin Boßlet <martin.boss...@googlemail.com> wrote:
Hello, if we do SSL/TSL client authentication, the current OpenSSL 1.0.0d verifies the client certificate upon reception of the Client Certificate message. Let's consider I want to find out whether the server trusts a certain CA I as an attacker am planning to compromise. I would send some certificate signed by that CA and then, it is possible to find out if the server trusts that certificate by interpreting the alert being returned. If the CA is trusted, the server will complain about the Certificate Verify message being wrong, otherwise it will inform me that the CA is untrusted. 1. Couldn't this be considered as a weakness? 2. Wouldn't it be better to send a less revealing alert in this case? 3. Or is this no risk at all and I am overlooking something important? Thanks in advance, Martin Bosslet ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature