On 26 June 2013 18:44, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
> On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote:
>
>> >> By enabling debug information in the program, I was able to obtain
>> >> these error messages:
>> >>
>> >> pppd[2236]: EAP-TLS SSL error stack:
>> >> pppd[2236]: error:0D0C5006:asn1 encoding
>> >> routines:ASN1_item_verify:EVP lib
>> >>
>> >> and
>> >>
>> >> err: 7 (certificate signature failure)
>
> The error "certificate signature failure" happens only when the
> public key of an issuer certificate in the chain does not generate
> a matching signature for its child certificate. Either the trust
> store (CAfile, CApath, ...) certificates are not identical in the
> two test cases, or one of the two parties sends a different chain,
> or the handshake is somehow corrupted.
>
> crypto/x509/x509_vfy.c:
> internal_verify():
> ...
> else if (X509_verify(xs,pkey) <= 0)
> {
> ctx->error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
>
> Look closely with wireshark at the chains captured on the machine
> where the error is detected. Are the peer certificate chains the
> same in every detail between the two library versions?
>
> Are both cases using compression? Any other differences?
>
I meant to reply to this earlier but I got busy with other stuff. Anyhow, I
took some time and redid some tests:
- ppp with EAP-TLS patch compiled with libssl 0.9.8o-4squeeze14 works ok
(I had some surprises with CRL handling, but that's besides the point
right now)
- ppp with EAP-TLS patch compiled with libssl 1.0.1e-2 exhibits the same
behaviour I originally described, i.e.: server fails to validate
signature and sends an alert message to the client.
I tried two scenarios:
a) one root CA, generates two intermediate CAs. The first intermediate CA
is used to generate a certificate for the server, and the second CA
generates certificates for clients.
b) one root CA, used to generate two certificates (1 for the server and 1
for the client).
In both cases, only the server validates the client cert. Additionally, I made
sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for
message digests as MD5 is broken.
I noticed that the error occurs if one of the two peers is using the binary
linked with libssl 1.0.1.
As Viktor suggested, I examined the handshake with Wireshark.
What I noticed:
ClientHello
* libssl 1.0.1 exposes more cipher suites
* libssl 1.0.1 adds more extensions (ec_point_formats,
elliptic_curves, heartbeat)
ServerHello
* libssl 1.0.1 adds the heartbeat extension
Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, 'x'
* 'x' is a "TLSv1 Record Layer: Handshake Protocol: Finished" for
libssl1.0.1
* 'x' is a "TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake
Message" for libssl0.9.8
I googled around to find more information regarding the encrypted handshake
message and I couldn't find anything relevant. In fact, RFC2246 says the
handshake should end with 'Finished' on both ends. I have no idea where that
'Encrypted Handshake Message' appeared from. Could it be some outdated
function that is called to setup the connection that is changing this
from the default ?
Below the URLs for the (text) captures. Let me know if you need the pcaps ..
though I found having the text version is easier to run diff :-)
Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
I can share the certs & ca files also if needed.
Marios
> --
> Viktor.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
