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:
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
libssl 1.0.1 breaking program
Hello list, I need to compile a version of PPP that supports EAP-TLS authentication protocol. Fortunately there is a a patch that accomplishes exactly this [1]. I have built the package using the default libssl-dev package provided by my operating system (Debian Wheezy/7.0). Specifically, it is this version : 1.0.1e-2 While there are no issues when building, the resulting binary doesn't behave as expected: EAP-TLS auth fails. 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 first one appears to be a mere warning, as the handshake proceeds, while the second one triggers a TLS Alert message 'Decryption failed'. I thought maybe the encoding error results in a corrupt cert being sent, which would obviously fail the signature check. However, I don't know how to check for this. Both errors disappeared when I replaced the libssl-dev package currently installed by an older version. To be precise, I installed the libssl-dev_0.9.8o-4squeeze14_amd64.deb package. While this solves my problem right now, I am curious as to why this is happening. Additionally, replacing libssl-dev is not exactly acceptable, as other packages may depend on it and require a more up to date version. I've examined the patch and it doesn't to be doing anything out of the ordinary, yet it fails to work properly with a more recent version of the library. For my tests, I generated a CA and a pair of certs with openssl: /usr/lib/ssl/misc/CA.pl -newca /usr/lib/ssl/misc/CA.pl -newreq /usr/lib/ssl/misc/CA.pl -sign Kept the default values mostly, including the empty fields. The only exception being the commonName field where I put the hostname of each machines. I doubt the certificates are the issue as I tested them with s_server / s_client and the handshake completed without any errors. Does anybody know why the patch fails to work with libssl-1.0.1e, and what can be done to fix this ? Let me know if there is any additional information I can provide. Thanks, Marios [1] http://www.nikhef.nl/~janjust/ppp/index.html __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: libssl 1.0.1 breaking program
Hello, On 26 June 2013 16:41, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Wed, Jun 26, 2013 at 02:57:15PM +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) Since you provide very little additional information, a wild guess: Sorry for that, I didn't know what additional information was expected. The error message is the one returned by SSL_CTX_set_verify(3), I couldn' t get additional information regarding this. OpenSSL 1.0.1e support TLSv1.2, while 0.9.8 only TLSv1. TLSv1 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) ^ Same version for all exchanged messages. With TLSv1.2 SHA-2 digests may have been negotiated, and if your RSA key size is too small (e.g. 512-bit RSA keys, which you should not use by the way, too easy to crack) the key may be too small to encrypt a SHA-384 digest. If you capture the handshake and decode it with wireshark, you'll have a lot more detail available. And do make sure your key sizes are all reasonable. Here's some detail on the CA and certs: CA: $ openssl x509 -text -noout -in cacert.pem Certificate: Data: Version: 3 (0x2) Serial Number: 15591382118858604766 (0xd85fb76e2ff1c0de) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST= , O=testca, CN=ca Validity Not Before: Jun 21 13:46:43 2013 GMT Not After : Jun 20 13:46:43 2016 GMT Subject: C=FR, ST= , O=testca, CN=ca Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:ca:02:f4:ea:56:d0:8d:fb:dd:dd:ba:53:52:60: 38:c0:14:cd:d1:cc:26:2e:67:a3:6e:57:e2:f8:8e: 40:ac:9a:67:b3:8f:21:f7:10:d1:9b:1a:4b:7e:2f: 36:38:ee:40:fb:f1:2a:5f:9d:c0:0d:59:d0:91:43: 6d:9f:5e:7d:ff:99:f7:25:1b:de:c3:e1:df:e3:ca: 8a:7d:bb:66:70:8e:3a:bd:c0:0a:c0:4e:b6:d0:1e: 77:84:a5:3f:49:eb:22:ae:97:fd:53:34:aa:62:5e: 23:ad:ea:8c:4b:43:65:d7:7a:57:1c:d7:50:44:9d: 62:2b:7e:b1:ed:8c:20:3f:cb Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 68:02:2C:46:4B:5D:05:B6:F2:DA:9F:D5:11:2D:C0:07:F6:4A:84:1A X509v3 Authority Key Identifier: keyid:68:02:2C:46:4B:5D:05:B6:F2:DA:9F:D5:11:2D:C0:07:F6:4A:84:1A X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 28:0b:de:9c:84:0b:3a:c9:1f:eb:80:8e:4c:92:c1:92:a0:ae: 2f:a6:dd:c8:0c:3b:d1:67:e5:fe:47:6f:93:72:85:67:d0:83: cc:e9:28:f9:02:25:1b:18:45:ca:2f:19:45:36:67:35:81:b1: 26:db:8f:4e:ba:b0:3a:14:03:7e:4a:be:aa:66:f5:35:79:aa: 0f:2a:dd:ef:c6:de:36:58:95:e3:74:86:c5:4b:b1:3b:b8:27: 93:ba:42:71:d9:7d:b7:68:d9:ef:41:a1:c7:84:28:b0:b6:ae: b9:fc:62:1f:67:8b:8d:8a:f3:3c:92:48:ce:db:81:67:0c:98: 29:76 Server cert: $ openssl x509 -text -noout -in server.pem Certificate: Data: Version: 3 (0x2) Serial Number: 15591382118858604776 (0xd85fb76e2ff1c0e8) Signature Algorithm: sha1WithRSAEncryption Issuer: C=FR, ST= , O=testca, CN=ca Validity Not Before: Jun 26 14:58:47 2013 GMT Not After : Jun 26 14:58:47 2014 GMT Subject: C=FR, ST= , O=Internet Widgits Pty Ltd, CN=server Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:c9:dd:7b:41:a3:af:2d:4c:83:4f:6e:ff:42:85: c4:2c:7a:6e:90:dc:09:52:b4:8e:20:4c:48:b5:21: 73:6d:00:e7:5b:1b:7f:0e:25:0a:ca:5f:42:45:39: 2b:e5:f7:1c:4e:f6:5e:f4:8a:e0:66:03:f7:83:02: d6:0f:40:09:2e:40:2e:60:49:f3:dd:05:df:06:0b: 67:88:89:98:24:3d:f5:01:07:3c:a3:aa:ae:e7:4e: 70:d0:88:36:19:14:da:b7:2e:b5:a1:4b:8b:fa:0c: 28:f2:70:8c:46:fc:59:ff:cb:1a:ec:c8:24:8d:e9: c2:21:08:fd:e0:e6:8e:e8:57:9d:49:c9:70:4a:20: 7d:c2:9f:91:2d:ba:b9:cf:4f:29:29:1c:48:f6:b3: f0:97:7b:5e:87:ec:dc:68:51:c9:f1:e9:c4:71:10: b2:cd:ea:8a:09:52:1d:51:06:9a:86:91:e3:fd:2f: c0:43:e4:e2:5b:b4:d3:27:f6:2a:66:60:1f:9b:d5: 53:06:0c:14:6c:cb:b0:79:c4:41:ae:80:0e:1c:5b: a4:7d:20:7f:0f:33:97:85:59:02:5a:18:8e:8c:be: 8a:fb:af:51:9f:52:28:a0:14:6e:c6:32:5a:44:14
