> From: owner-openssl-us...@openssl.org On Behalf Of Marios Makassikis > Sent: Thursday, 25 July, 2013 11:56 > To: openssl-users@openssl.org > Subject: Re: libssl 1.0.1 breaking program > > 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:
> >> >> pppd[2236]: EAP-TLS SSL error stack: > >> >> pppd[2236]: error:0D0C5006:asn1 encoding > routines:ASN1_item_verify:EVP lib > >> >> 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. > > 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? > I meant to reply to this earlier but I got busy with other > stuff. Anyhow, I took some time and redid some tests: <snip> > 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. > Are you sure? According to your successful (0.9.8) traces, the server requests client-auth and the client sends it. Unless ppp (can be and) is configured to tell libssl to do client-auth, but then supplies a callback that ignores the validation (a la s_client) it is validating. > 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 1.0.0 enabled ECC suites by default (in 0.9.8 had to enable explicitly) plus a few others. 1.0.1 enabled TLSv1.1 and v1.2 and additional suites for the latter, but ppp is apparently directing only TLSv1.0 even when using openssl 1.0.1. > Certificate, Client Key Exchange, Certificate Verify, Change > Cipher Spec, 'x' Actually that's server Certificate, >CertReq, HelloDone,< then client KeyExchange, CertVerify, ChangeCipher, (Finished) then if successful server (something), ChangeCipher, (Finished) > * '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 ? > The Finished message is a handshake message and is encrypted, since it occurs (just) after ChangeCipher. If Wireshark knows the data keys, it decrypts the message and displays it as Finished. If Wireshark doesn't know the data keys, it just displays Encrypted Handshake Message since it doesn't know which message it is without decrypting. For akRSA key-exchange, as this case, Wireshark can compute the data keys if it can determine the server RSA privatekey. Obviously it did this right in the case that displays (1.0.1). For normal IP connections, Wireshark chooses the server RSA key based on the server IP address and port; I don't know how that works/changes for PPP, but that's where I'd start looking. > > 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 > The 2nd and 4th are the same URL, but even 1st and 3rd appear to be two ends of the same exchange, which is redundant (unless there is frame loss or damage, which there isn't). I don't see anything in the 2nd that would explain sig-fail. Can you try openssl commandline on the same pair(s?) of systems, i.e. run s_server with the same CAcert and server key&cert that pppd is using, and s_client to that server with the same CAcert and client key&cert ppd client is using, for each version of openssl? If that fails we have an easier case to work on. If it works, there must be something about the embedding in EAP by ppp that messes up only sometimes, which would be really nasty. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
