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


Attachment: Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature

Reply via email to