Re: libssl 1.0.1 breaking program

2013-07-25 Thread Marios Makassikis 
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

Re: libssl 1.0.1 breaking program

2013-07-25 Thread Dr. Stephen Henson 
On Thu, Jul 25, 2013, Marios Makassikis wrote:

 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.
 

Well that error is caused by a certificate chain verification failure. In
particular the signature verification of a certificate using the key in it's
issuer.

Possibly cause of that is a failure of the cryptographic algorithm (OpenSSL
bug or compiler bug) or for some reason OpenSSL isn't using the correct
certificate to verify the signature.

 
 
 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.
 

OpenSSL (among other things) does this when verifying the certificate chain:

openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem

where allcerts.pem is the complete peer chain and ee.pem is the peer
certificate. I'd be interested to see what that commands produces for
different version. If you use a directory and use -CApath instead.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
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

2013-07-25 Thread Viktor Dukhovni 
On Thu, Jul 25, 2013 at 07:08:30PM +0200, Dr. Stephen Henson wrote:

 openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem
 
 where allcerts.pem is the complete peer chain and ee.pem is the peer
 certificate. I'd be interested to see what that commands produces for
 different version. If you use a directory and use -CApath instead.

It should be noted that OpenSSL 1.0 changed the hashing algorithm
used to index CApath/ directories.  If the OP is using CApath with
c_rehash generated from 0.9.8, that could failure to validate the
client certificate, though the error would typically reflect lack
of trust, not cryptographic integrity problems.

Perhaps the client sends a stale copy of one the CA certificates,
which has the right issuer name, but the wrong public key.  Or
the client's private key and certificate are not as intended...

As for the packe captures on pastebin, it is too difficult to read
pre-decoded packet dumps.  The OP should post links to the binary
pcap files.

-- 
Viktor.
__
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

2013-07-25 Thread Dr. Stephen Henson 
On Thu, Jul 25, 2013, Viktor Dukhovni wrote:

 On Thu, Jul 25, 2013 at 07:08:30PM +0200, Dr. Stephen Henson wrote:
 
  openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem
  
  where allcerts.pem is the complete peer chain and ee.pem is the peer
  certificate. I'd be interested to see what that commands produces for
  different version. If you use a directory and use -CApath instead.
 
 It should be noted that OpenSSL 1.0 changed the hashing algorithm
 used to index CApath/ directories.  If the OP is using CApath with
 c_rehash generated from 0.9.8, that could failure to validate the
 client certificate, though the error would typically reflect lack
 of trust, not cryptographic integrity problems.
 

Yes I'd considered that as a possibility but as you say you'd get a different
error.

 Perhaps the client sends a stale copy of one the CA certificates,
 which has the right issuer name, but the wrong public key.  Or
 the client's private key and certificate are not as intended...
 

The hints I get imply the verify algorithm is using the wrong certificate to
verify the chain. To the OP: do those two CA certificates you mentioned have
the exact same subject name?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
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

2013-07-25 Thread Dave Thompson 
 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 keycert 
that pppd is using, and s_client to that server with the same 
CAcert and client keycert 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

CORR: libssl 1.0.1 breaking program

2013-07-25 Thread Dave Thompson 
 From: owner-openssl-us...@openssl.org On Behalf Of Dave Thompson
 Sent: Thursday, 25 July, 2013 21:32

  From: owner-openssl-us...@openssl.org On Behalf Of Marios Makassikis
  Sent: Thursday, 25 July, 2013 11:56

Aargh. Sorry, I read this wrong:

  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.
 
People so often say only validate server that my eyes 
saw that even though you clearly wrote validate client.
Ignore this and continue with the rest. Phooey.

__
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

2013-06-26 Thread Marios Makassikis 
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

2013-06-26 Thread Viktor Dukhovni 
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:

OpenSSL 1.0.1e support TLSv1.2, while 0.9.8 only TLSv1.

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.

-- 
Viktor.
__
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

2013-06-26 Thread Marios Makassikis 
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:

Re: libssl 1.0.1 breaking program

2013-06-26 Thread Viktor Dukhovni 
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?

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org