From chenyt at cs.sjtu.edu.cn  Wed Apr  1 23:15:49 2015
From: chenyt at cs.sjtu.edu.cn (Yuting Chen)
Date: Wed, 1 Apr 2015 14:15:49 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected by
	OpenSSL/PolarSSL
Message-ID: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>

I made a certificate and verified it using gnutls, openssl, and polarssl.
It can be verified by gnutls, but be rejected the other two due to
certificate signature failures. It is a special case because in many other
cases in my experiment, gnutls tends to "reject" certificates if openssl
"rejects" them. Can anyone help me find the reason (to ensure that gnutls
has checked the signature correctly)?

Openssl: openssl verify -CAfile fa_rootCA_key_cert.pem file.pem
Polarssl: cert_app mode='file' filename=file.pem
 ca_file=fa_rootCA_key_cert.pem
Gnutls: certtool -verify
--load-ca-certificate=fa_rootCA_key_cert.pem <file.pem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150401/b3ba24f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file.pem
Type: application/x-x509-ca-cert
Size: 3080 bytes
Desc: not available
URL: </pipermail/attachments/20150401/b3ba24f1/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fa_rootCA_key_cert.pem
Type: application/x-x509-ca-cert
Size: 1815 bytes
Desc: not available
URL: </pipermail/attachments/20150401/b3ba24f1/attachment-0001.crt>

From nmav at gnutls.org  Thu Apr  2 09:21:17 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 2 Apr 2015 09:21:17 +0200
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
Message-ID: <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>

On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn> wrote:
> I made a certificate and verified it using gnutls, openssl, and polarssl. It
> can be verified by gnutls, but be rejected the other two due to certificate
> signature failures. It is a special case because in many other cases in my
> experiment, gnutls tends to "reject" certificates if openssl "rejects" them.
> Can anyone help me find the reason (to ensure that gnutls has checked the
> signature correctly)?

Hello,
 What is the issue in the certificate? Why it shouldn't be verified
successfully?

regards,
Nikos


From chenyt at cs.sjtu.edu.cn  Thu Apr  2 19:00:46 2015
From: chenyt at cs.sjtu.edu.cn (Yuting Chen)
Date: Thu, 2 Apr 2015 10:00:46 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
Message-ID: <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>

Hi, Nikos, I'm not very sure whether the certificate should or should not
pass validation. It is a challenging problem to design tests for testing
SSL tools. I used openssl to create 4000 valid or invalid test certificates
(but I failed to design test oracles). It is interesting that the
certificate is the only that can be accepted by Gnutls, but rejected by
openssl and polarssl. The validation results are:
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted.

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification
Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use
only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA
Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature
length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.",
OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998
VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd,
CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
 failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn>
> wrote:
> > I made a certificate and verified it using gnutls, openssl, and
> polarssl. It
> > can be verified by gnutls, but be rejected the other two due to
> certificate
> > signature failures. It is a special case because in many other cases in
> my
> > experiment, gnutls tends to "reject" certificates if openssl "rejects"
> them.
> > Can anyone help me find the reason (to ensure that gnutls has checked the
> > signature correctly)?
>
> Hello,
>  What is the issue in the certificate? Why it shouldn't be verified
> successfully?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/f53e5acd/attachment-0001.html>

From home_pw at msn.com  Thu Apr  2 19:15:28 2015
From: home_pw at msn.com (Peter Williams)
Date: Thu, 2 Apr 2015 10:15:28 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
Message-ID: <BAY404-EAS1438EAB768F27E8FA13304B92F20@phx.gbl>

Why you trusting a 10 year old cert, with a 1024bit RSA key?

Because google say so?

Sent from my Windows Phone
________________________________
From: Yuting Chen<mailto:chenyt at cs.sjtu.edu.cn>
Sent: ?4/?2/?2015 10:01 AM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Hi, Nikos, I'm not very sure whether the certificate should or should not
pass validation. It is a challenging problem to design tests for testing
SSL tools. I used openssl to create 4000 valid or invalid test certificates
(but I failed to design test oracles). It is interesting that the
certificate is the only that can be accepted by Gnutls, but rejected by
openssl and polarssl. The validation results are:
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted.

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification
Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use
only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA
Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature
length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.",
OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998
VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd,
CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
 failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn>
> wrote:
> > I made a certificate and verified it using gnutls, openssl, and
> polarssl. It
> > can be verified by gnutls, but be rejected the other two due to
> certificate
> > signature failures. It is a special case because in many other cases in
> my
> > experiment, gnutls tends to "reject" certificates if openssl "rejects"
> them.
> > Can anyone help me find the reason (to ensure that gnutls has checked the
> > signature correctly)?
>
> Hello,
>  What is the issue in the certificate? Why it shouldn't be verified
> successfully?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/fa8920cb/attachment.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

From home_pw at msn.com  Thu Apr  2 20:03:43 2015
From: home_pw at msn.com (Peter Williams)
Date: Thu, 2 Apr 2015 11:03:43 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
Message-ID: <BAY404-EAS232018676C6A49A5AFCA18592F20@phx.gbl>

There are no test vectors (outside of dod/nsa or equiv). Unlike crypto alg test vectors.



Sent from my Windows Phone
________________________________
From: ???<mailto:chenyt at cs.sjtu.edu.cn>
Sent: ?4/?2/?2015 10:57 AM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>; Peter Williams<mailto:home_pw at msn.com>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Is it possible to find any test oracles? Given a certificate chain,
how can we decide that it is correct or incorrect?

From: Peter Williams
Sent: Thursday, April 02, 2015 10:31 AM
To: Yuting Chen ; Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

When we write the Verisign cps, we distinguished

Validating a root *(becos it is lusted in a mib, secured by non crypto means, in the days before gchq:s  tpm became embedded in laptops and export grade servers)

Validating a chain from said root to a leaf cert, which includes verifying a sequence signatures and asn1 encodings and control policies (eg chain length) against some cert profile or cps

Verifying a digital signature, distinct from validating it as part of chain processing.

The legal theory was clear. Dig sigs need to be verified using public keys (not certs). The security service of key distribution (cert chains, in this case) delivers leaf public keys to trust store (even ephemeral ones) from which they are accessed by the signature verification modules.

Fyi, ietf tls does not standardize any of the above. It's upto to each vendor, some of whose staff are typically easily compromised to deliver operationnally defective crypto or security services.

Check that the security service claimed by each lib is the same. No point comparing validation vs verification. No point comparing one vendors asn1 int encoding against another *recalling that public key length encoding choices represent  a crypto oracle)




Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ?4/?2/?2015 10:01 AM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Hi, Nikos, I'm not very sure whether the certificate should or should not pass validation. It is a challenging problem to design tests for testing SSL tools. I used openssl to create 4000 valid or invalid test certificates (but I failed to design test oracles). It is interesting that the certificate is the only that can be accepted by Gnutls, but rejected by openssl and polarssl. The validation results are:
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted.

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd, CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn> wrote:
  > I made a certificate and verified it using gnutls, openssl, and polarssl. It
  > can be verified by gnutls, but be rejected the other two due to certificate
  > signature failures. It is a special case because in many other cases in my
  > experiment, gnutls tends to "reject" certificates if openssl "rejects" them.
  > Can anyone help me find the reason (to ensure that gnutls has checked the
  > signature correctly)?

  Hello,
  What is the issue in the certificate? Why it shouldn't be verified
  successfully?

  regards,
  Nikos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/0d865b74/attachment-0001.html>

From home_pw at msn.com  Thu Apr  2 19:31:50 2015
From: home_pw at msn.com (Peter Williams)
Date: Thu, 2 Apr 2015 10:31:50 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
Message-ID: <BAY404-EAS409955844BE92AEE41E0BE792F20@phx.gbl>

When we write the Verisign cps, we distinguished

Validating a root *(becos it is lusted in a mib, secured by non crypto means, in the days before gchq:s  tpm became embedded in laptops and export grade servers)

Validating a chain from said root to a leaf cert, which includes verifying a sequence signatures and asn1 encodings and control policies (eg chain length) against some cert profile or cps

Verifying a digital signature, distinct from validating it as part of chain processing.

The legal theory was clear. Dig sigs need to be verified using public keys (not certs). The security service of key distribution (cert chains, in this case) delivers leaf public keys to trust store (even ephemeral ones) from which they are accessed by the signature verification modules.

Fyi, ietf tls does not standardize any of the above. It's upto to each vendor, some of whose staff are typically easily compromised to deliver operationnally defective crypto or security services.

Check that the security service claimed by each lib is the same. No point comparing validation vs verification. No point comparing one vendors asn1 int encoding against another *recalling that public key length encoding choices represent  a crypto oracle)




Sent from my Windows Phone
________________________________
From: Yuting Chen<mailto:chenyt at cs.sjtu.edu.cn>
Sent: ?4/?2/?2015 10:01 AM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Hi, Nikos, I'm not very sure whether the certificate should or should not
pass validation. It is a challenging problem to design tests for testing
SSL tools. I used openssl to create 4000 valid or invalid test certificates
(but I failed to design test oracles). It is interesting that the
certificate is the only that can be accepted by Gnutls, but rejected by
openssl and polarssl. The validation results are:
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted.

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification
Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use
only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure
Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA
Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted.

Chain verification output: Verified. The certificate is trusted.

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature
length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.",
OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998
VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd,
CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo
CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA
Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary
Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized
use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
 failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn>
> wrote:
> > I made a certificate and verified it using gnutls, openssl, and
> polarssl. It
> > can be verified by gnutls, but be rejected the other two due to
> certificate
> > signature failures. It is a special case because in many other cases in
> my
> > experiment, gnutls tends to "reject" certificates if openssl "rejects"
> them.
> > Can anyone help me find the reason (to ensure that gnutls has checked the
> > signature correctly)?
>
> Hello,
>  What is the issue in the certificate? Why it shouldn't be verified
> successfully?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/2b6c85ca/attachment.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

From chenyt at cs.sjtu.edu.cn  Thu Apr  2 19:45:38 2015
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Thu, 2 Apr 2015 10:45:38 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
	by OpenSSL/PolarSSL
In-Reply-To: <BAY404-EAS1438EAB768F27E8FA13304B92F20@phx.gbl>
References: <BAY404-EAS1438EAB768F27E8FA13304B92F20@phx.gbl>
Message-ID: <0D835B7DF77C4F5091E6DE2F322B416E@sjtu.edu.cn>

The certificates are not the original ones. I have modified and 
resigned them (using the 1024 bit RSA keys).  

From: Peter Williams 
Sent: Thursday, April 02, 2015 10:15 AM
To: Yuting Chen ; Nikos Mavrogiannopoulos 
Cc: GnuTLS development list 
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Why you trusting a 10 year old cert, with a 1024bit RSA key?

Because google say so?

Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ?4/?2/?2015 10:01 AM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Hi, Nikos, I'm not very sure whether the certificate should or should not pass validation. It is a challenging problem to design tests for testing SSL tools. I used openssl to create 4000 valid or invalid test certificates (but I failed to design test oracles). It is interesting that the certificate is the only that can be accepted by Gnutls, but rejected by openssl and polarssl. The validation results are: 
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted. 

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd, CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn> wrote:
  > I made a certificate and verified it using gnutls, openssl, and polarssl. It
  > can be verified by gnutls, but be rejected the other two due to certificate
  > signature failures. It is a special case because in many other cases in my
  > experiment, gnutls tends to "reject" certificates if openssl "rejects" them.
  > Can anyone help me find the reason (to ensure that gnutls has checked the
  > signature correctly)?

  Hello,
  What is the issue in the certificate? Why it shouldn't be verified
  successfully?

  regards,
  Nikos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/14ee0a8e/attachment-0001.html>

From chenyt at cs.sjtu.edu.cn  Thu Apr  2 19:56:56 2015
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Thu, 2 Apr 2015 10:56:56 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
	by OpenSSL/PolarSSL
In-Reply-To: <BAY404-EAS409955844BE92AEE41E0BE792F20@phx.gbl>
References: <BAY404-EAS409955844BE92AEE41E0BE792F20@phx.gbl>
Message-ID: <262ECF50BB904A008BCE94332160CACF@sjtu.edu.cn>

Is it possible to find any test oracles? Given a certificate chain, 
how can we decide that it is correct or incorrect? 

From: Peter Williams 
Sent: Thursday, April 02, 2015 10:31 AM
To: Yuting Chen ; Nikos Mavrogiannopoulos 
Cc: GnuTLS development list 
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

When we write the Verisign cps, we distinguished

Validating a root *(becos it is lusted in a mib, secured by non crypto means, in the days before gchq:s  tpm became embedded in laptops and export grade servers) 

Validating a chain from said root to a leaf cert, which includes verifying a sequence signatures and asn1 encodings and control policies (eg chain length) against some cert profile or cps

Verifying a digital signature, distinct from validating it as part of chain processing.

The legal theory was clear. Dig sigs need to be verified using public keys (not certs). The security service of key distribution (cert chains, in this case) delivers leaf public keys to trust store (even ephemeral ones) from which they are accessed by the signature verification modules.

Fyi, ietf tls does not standardize any of the above. It's upto to each vendor, some of whose staff are typically easily compromised to deliver operationnally defective crypto or security services.

Check that the security service claimed by each lib is the same. No point comparing validation vs verification. No point comparing one vendors asn1 int encoding against another *recalling that public key length encoding choices represent  a crypto oracle)




Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ?4/?2/?2015 10:01 AM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Hi, Nikos, I'm not very sure whether the certificate should or should not pass validation. It is a challenging problem to design tests for testing SSL tools. I used openssl to create 4000 valid or invalid test certificates (but I failed to design test oracles). It is interesting that the certificate is the only that can be accepted by Gnutls, but rejected by openssl and polarssl. The validation results are: 
(1) Gnutls:
Subject: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Issuer: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Checked against: C=US,ST=CA,O=Internet Widgits Pty Ltd,CN=Frankencert CA
Output: Verified. The certificate is trusted. 

Subject: C=US,O=VeriSign\, Inc.,OU=Class 4 Public Primary Certification Authority - G2,OU=(c) 1998 VeriSign\, Inc. - For authorized use only,OU=VeriSign Trust Network
Issuer: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Checked against: C=GB,ST=Greater Manchester,L=Salford,O=Comodo CA Limited,CN=Secure Certificate Services
Output: Verified. The certificate is trusted. 

Chain verification output: Verified. The certificate is trusted. 

(2) Openssl:
140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature length:rsa_sign.c:175:
140637590406816:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:221:
ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign, Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU = "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign Trust Network
error 7 at 0 depth lookup:certificate signature failure

(3) PolarSSL:
  . Loading the CA root certificate ... ok (0 skipped)

  . Loading the certificate(s) ... ok
  . Peer certificate information    ...
      cert. version     : 1
      serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
      issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
      issued  on        : 1998-05-18 00:00:00
      expires on        : 2028-08-01 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits

  . Peer certificate information    ...
      cert. version     : 3
      serial number     : 01
      issuer name       : C=US, ST=CA, O=Internet Widgits Pty Ltd, CN=Frankencert CA
      subject name      : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
      issued  on        : 2004-01-01 00:00:00
      expires on        : 2016-07-06 23:59:59
      signed using      : RSA with SHA1
      RSA key size      : 1024 bits
      basic constraints : CA=true
      key usage         : Digital Signature, Key Encipherment

  . Verifying X.509 certificate...
Verify requested for (Depth 0):
cert. version     : 1
serial number     : 32:88:8E:9A:D2:F5:EB:13:47:F8:7F:C4:20:37:25:F8
issuer name       : C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=Secure Certificate Services
subject name      : C=US, O=VeriSign, Inc., OU=Class 4 Public Primary Certification Authority - G2, OU=(c) 1998 VeriSign, Inc. - For authorized use only, OU=VeriSign Trust Network
issued  on        : 1998-05-18 00:00:00
expires on        : 2028-08-01 23:59:59
signed using      : RSA with SHA1
RSA key size      : 1024 bits
  ! self-signed or not signed by a trusted CA
failed

On Thu, Apr 2, 2015 at 12:21 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Wed, Apr 1, 2015 at 11:15 PM, Yuting Chen <chenyt at cs.sjtu.edu.cn> wrote:
  > I made a certificate and verified it using gnutls, openssl, and polarssl. It
  > can be verified by gnutls, but be rejected the other two due to certificate
  > signature failures. It is a special case because in many other cases in my
  > experiment, gnutls tends to "reject" certificates if openssl "rejects" them.
  > Can anyone help me find the reason (to ensure that gnutls has checked the
  > signature correctly)?

  Hello,
  What is the issue in the certificate? Why it shouldn't be verified
  successfully?

  regards,
  Nikos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/c297681a/attachment.html>

From nmav at gnutls.org  Thu Apr  2 23:07:01 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 02 Apr 2015 23:07:01 +0200
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
 <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
Message-ID: <1428008821.1630.4.camel@gnutls.org>

On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:


> (2) Openssl:
> 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
> signature length:rsa_sign.c:175:
> 140637590406816:error:0D0C5006:asn1 encoding
> routines:ASN1_item_verify:EVP lib:a_verify.c:221:
> ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
> Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
> "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
> Trust Network
> error 7 at 0 depth lookup:certificate signature failure

In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
another one. If you try openssl on each two of them (i.e., split the
file.pem) you'll get an OK. Are you sure that openssl verify can accept
a chain?

regards,
Nikos





From chenyt at cs.sjtu.edu.cn  Thu Apr  2 23:53:38 2015
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Thu, 2 Apr 2015 14:53:38 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
	by OpenSSL/PolarSSL
In-Reply-To: <1428008821.1630.4.camel@gnutls.org>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
 <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
 <1428008821.1630.4.camel@gnutls.org>
Message-ID: <6DDD432E911D499E88AC83DB6916A2F6@sjtu.edu.cn>

Hi, Nikos, I have tried it. I splitted file.pem into file0.pem and 
file1.pem.
I used openssl/polarssl to verify file0.pem against file1.pem, and they 
still
report error messages (unable to get issuer certificate/not signed by a
trusted CA).

I checked the modifications I have made: I tried to delete the "name" field
from the subject of file1.pem (I'm not so sure why I did it like this at 
that time. Does
a subject of an X509 certificate contain the field?). But it may cause some
problems and make the other two tools cannot find the issuer of file0.pem.



-----Original Message----- 
From: Nikos Mavrogiannopoulos
Sent: Thursday, April 02, 2015 2:07 PM
To: Yuting Chen
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected 
by OpenSSL/PolarSSL

On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:


> (2) Openssl:
> 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
> signature length:rsa_sign.c:175:
> 140637590406816:error:0D0C5006:asn1 encoding
> routines:ASN1_item_verify:EVP lib:a_verify.c:221:
> ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
> Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
> "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
> Trust Network
> error 7 at 0 depth lookup:certificate signature failure

In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
another one. If you try openssl on each two of them (i.e., split the
file.pem) you'll get an OK. Are you sure that openssl verify can accept
a chain?

regards,
Nikos




From chenyt at cs.sjtu.edu.cn  Fri Apr  3 03:48:49 2015
From: chenyt at cs.sjtu.edu.cn (Yuting Chen)
Date: Thu, 2 Apr 2015 18:48:49 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <1428008821.1630.4.camel@gnutls.org>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
 <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
 <1428008821.1630.4.camel@gnutls.org>
Message-ID: <CAKra3615SHYHjQ3nH0OLiAWyFkuS-n5+0OKfDr-qMQcAjbwrEA@mail.gmail.com>

Another very different example: when I verify file5.pem (the attached file)
against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of the cert
in file5.pem, but openssl/polarssl can find the issuer and accept it. It is
a little tricky to find the issuer by comparing the "issuer" field of one
certificate with the "subject" field of the ca certificate.

On Thu, Apr 2, 2015 at 2:07 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:
>
>
> > (2) Openssl:
> > 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
> > signature length:rsa_sign.c:175:
> > 140637590406816:error:0D0C5006:asn1 encoding
> > routines:ASN1_item_verify:EVP lib:a_verify.c:221:
> > ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
> > Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
> > "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
> > Trust Network
> > error 7 at 0 depth lookup:certificate signature failure
>
> In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
> another one. If you try openssl on each two of them (i.e., split the
> file.pem) you'll get an OK. Are you sure that openssl verify can accept
> a chain?
>
> regards,
> Nikos
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/589d02dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file5.pem
Type: application/x-x509-ca-cert
Size: 1696 bytes
Desc: not available
URL: </pipermail/attachments/20150402/589d02dd/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fa_rootCA_key_cert.pem
Type: application/x-x509-ca-cert
Size: 1815 bytes
Desc: not available
URL: </pipermail/attachments/20150402/589d02dd/attachment-0001.crt>

From home_pw at msn.com  Fri Apr  3 04:28:35 2015
From: home_pw at msn.com (Peter Williams)
Date: Thu, 2 Apr 2015 19:28:35 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
Message-ID: <BAY404-EAS36D14760CB40993071F80F92F10@phx.gbl>

Some libs chain on the keyids, not the names. Depends on the generation of developer. If paid / indoctrinated in the pem phase, will be name based (since one used the directory to do what we would now call openid connect discovery of tryst points (based on naming domains)). If NSA paid /influenced, it uses keyids (which are just NSA kmids, revisited)

For disclosure, I was NSA paid / influenced, but thoroughly bought into the darpa design , now realized (20 years late) as azure active directory plus openud connect.


Sent from my Windows Phone
________________________________
From: Yuting Chen<mailto:chenyt at cs.sjtu.edu.cn>
Sent: ?4/?2/?2015 6:49 PM
To: Nikos Mavrogiannopoulos<mailto:nmav at gnutls.org>
Cc: GnuTLS development list<mailto:gnutls-devel at lists.gnutls.org>
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Another very different example: when I verify file5.pem (the attached file)
against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of the cert
in file5.pem, but openssl/polarssl can find the issuer and accept it. It is
a little tricky to find the issuer by comparing the "issuer" field of one
certificate with the "subject" field of the ca certificate.

On Thu, Apr 2, 2015 at 2:07 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:

> On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:
>
>
> > (2) Openssl:
> > 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
> > signature length:rsa_sign.c:175:
> > 140637590406816:error:0D0C5006:asn1 encoding
> > routines:ASN1_item_verify:EVP lib:a_verify.c:221:
> > ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
> > Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
> > "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
> > Trust Network
> > error 7 at 0 depth lookup:certificate signature failure
>
> In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
> another one. If you try openssl on each two of them (i.e., split the
> file.pem) you'll get an OK. Are you sure that openssl verify can accept
> a chain?
>
> regards,
> Nikos
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/ec524491/attachment.html>
-------------- next part --------------
_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel

From chenyt at cs.sjtu.edu.cn  Fri Apr  3 06:02:52 2015
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Thu, 2 Apr 2015 21:02:52 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
	by OpenSSL/PolarSSL
In-Reply-To: <BAY404-EAS36D14760CB40993071F80F92F10@phx.gbl>
References: <BAY404-EAS36D14760CB40993071F80F92F10@phx.gbl>
Message-ID: <98289BAF06BE453684F3B57EEA9FCBD4@sjtu.edu.cn>

Interesting! I have never heard about this. Thus it is possible that one tool (e.g., openssl) chains the certificates on their keyids, but gnutls may chain them on their names (or on the contrary), right? 

From: Peter Williams 
Sent: Thursday, April 02, 2015 7:28 PM
To: Yuting Chen ; Nikos Mavrogiannopoulos 
Cc: GnuTLS development list 
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Some libs chain on the keyids, not the names. Depends on the generation of developer. If paid / indoctrinated in the pem phase, will be name based (since one used the directory to do what we would now call openid connect discovery of tryst points (based on naming domains)). If NSA paid /influenced, it uses keyids (which are just NSA kmids, revisited)

For disclosure, I was NSA paid / influenced, but thoroughly bought into the darpa design , now realized (20 years late) as azure active directory plus openud connect.


Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ?4/?2/?2015 6:49 PM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Another very different example: when I verify file5.pem (the attached file) against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of the cert in file5.pem, but openssl/polarssl can find the issuer and accept it. It is a little tricky to find the issuer by comparing the "issuer" field of one certificate with the "subject" field of the ca certificate. 

On Thu, Apr 2, 2015 at 2:07 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:


  > (2) Openssl:
  > 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
  > signature length:rsa_sign.c:175:
  > 140637590406816:error:0D0C5006:asn1 encoding
  > routines:ASN1_item_verify:EVP lib:a_verify.c:221:
  > ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
  > Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
  > "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
  > Trust Network
  > error 7 at 0 depth lookup:certificate signature failure

  In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
  another one. If you try openssl on each two of them (i.e., split the
  file.pem) you'll get an OK. Are you sure that openssl verify can accept
  a chain?

  regards,
  Nikos




-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/401f1ab1/attachment-0001.html>

From chenyt at cs.sjtu.edu.cn  Fri Apr  3 06:18:15 2015
From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=)
Date: Thu, 2 Apr 2015 21:18:15 -0700
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
	by OpenSSL/PolarSSL
In-Reply-To: <BAY404-EAS36D14760CB40993071F80F92F10@phx.gbl>
References: <BAY404-EAS36D14760CB40993071F80F92F10@phx.gbl>
Message-ID: <F8BA139F10EE42D78160E58FB55576CC@sjtu.edu.cn>

B.T.W., I use pyopenssl to decode, modify, and sign the certificates. I guess they should be chained on the basis of their names. 

From: Peter Williams 
Sent: Thursday, April 02, 2015 7:28 PM
To: Yuting Chen ; Nikos Mavrogiannopoulos 
Cc: GnuTLS development list 
Subject: RE: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL

Some libs chain on the keyids, not the names. Depends on the generation of developer. If paid / indoctrinated in the pem phase, will be name based (since one used the directory to do what we would now call openid connect discovery of tryst points (based on naming domains)). If NSA paid /influenced, it uses keyids (which are just NSA kmids, revisited)

For disclosure, I was NSA paid / influenced, but thoroughly bought into the darpa design , now realized (20 years late) as azure active directory plus openud connect.


Sent from my Windows Phone

--------------------------------------------------------------------------------
From: Yuting Chen
Sent: ?4/?2/?2015 6:49 PM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list
Subject: Re: [gnutls-devel] A certificate is verified by Gnutls but rejected by OpenSSL/PolarSSL


Another very different example: when I verify file5.pem (the attached file) against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of the cert in file5.pem, but openssl/polarssl can find the issuer and accept it. It is a little tricky to find the issuer by comparing the "issuer" field of one certificate with the "subject" field of the ca certificate. 

On Thu, Apr 2, 2015 at 2:07 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

  On Thu, 2015-04-02 at 10:00 -0700, Yuting Chen wrote:


  > (2) Openssl:
  > 140637590406816:error:04091077:rsa routines:INT_RSA_VERIFY:wrong
  > signature length:rsa_sign.c:175:
  > 140637590406816:error:0D0C5006:asn1 encoding
  > routines:ASN1_item_verify:EVP lib:a_verify.c:221:
  > ZZZZZZZZZZZZZComodo_Secure_Services_root.pem: C = US, O = "VeriSign,
  > Inc.", OU = Class 4 Public Primary Certification Authority - G2, OU =
  > "(c) 1998 VeriSign, Inc. - For authorized use only", OU = VeriSign
  > Trust Network
  > error 7 at 0 depth lookup:certificate signature failure

  In the file.pem you have 2 certificates (a chain), and the fa_rootCA is
  another one. If you try openssl on each two of them (i.e., split the
  file.pem) you'll get an OK. Are you sure that openssl verify can accept
  a chain?

  regards,
  Nikos




-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150402/fc46b1e3/attachment.html>

From nmav at gnutls.org  Fri Apr  3 07:11:35 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 03 Apr 2015 07:11:35 +0200
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <6DDD432E911D499E88AC83DB6916A2F6@sjtu.edu.cn>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
 <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
 <1428008821.1630.4.camel@gnutls.org>
 <6DDD432E911D499E88AC83DB6916A2F6@sjtu.edu.cn>
Message-ID: <1428037895.1606.1.camel@gnutls.org>

On Thu, 2015-04-02 at 14:53 -0700, ??? wrote:
> Hi, Nikos, I have tried it. I splitted file.pem into file0.pem and 
> file1.pem.
> I used openssl/polarssl to verify file0.pem against file1.pem, and they 
> still
> report error messages (unable to get issuer certificate/not signed by a
> trusted CA).

Add in the file1.pem the ca in the other file you have and verification
will succeed.

regards,
Nikos






From nmav at gnutls.org  Fri Apr  3 07:18:59 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 03 Apr 2015 07:18:59 +0200
Subject: [gnutls-devel] A certificate is verified by Gnutls but rejected
 by OpenSSL/PolarSSL
In-Reply-To: <CAKra3615SHYHjQ3nH0OLiAWyFkuS-n5+0OKfDr-qMQcAjbwrEA@mail.gmail.com>
References: <CAKra3605wi1StR9X+YuOk=4pVvWJbTwAtSCSaRzibxd8xRqJfA@mail.gmail.com>
 <CAJU7zaJC8Nurx-2pewQiVArYwARfU=1X3M2SYr95NSta-BPh1g@mail.gmail.com>
 <CAKra3611DS6Yd65xRW6+4V1Yf5kDbdQPT4fUozQ=F6gkZxs+_A@mail.gmail.com>
 <1428008821.1630.4.camel@gnutls.org>
 <CAKra3615SHYHjQ3nH0OLiAWyFkuS-n5+0OKfDr-qMQcAjbwrEA@mail.gmail.com>
Message-ID: <1428038339.1606.6.camel@gnutls.org>

On Thu, 2015-04-02 at 18:48 -0700, Yuting Chen wrote:
> Another very different example: when I verify file5.pem (the attached
> file) against fa_rootCA_key_cert.pem, gnutls cannot find the issuer of
> the cert in file5.pem, but openssl/polarssl can find the issuer and
> accept it. It is a little tricky to find the issuer by comparing the
> "issuer" field of one certificate with the "subject" field of the ca
> certificate. 

As Peter noticed, the end certificate has authority key identifier set,
and the CA certificate has the subject key identifier set and they don't
match. In any case I think it is counter productive sending random
certificates which their verification doesn't match the other programs.
If you have certificate which you know it should or shouldn't pass but
the result of gnutls' certtool differs, then that will be an interesting
result.

regards,
Nikos





From ranpengui at gmail.com  Fri Apr  3 09:52:58 2015
From: ranpengui at gmail.com (pengui ran)
Date: Fri, 3 Apr 2015 15:52:58 +0800
Subject: [gnutls-devel] =?utf-8?q?Does_GnuTLS_support_path_discovery?=
	=?utf-8?b?77yf?=
Message-ID: <CAPYASnYsZgBqGsibJQtkCHv2U6GHM1BVaGLcTakeMcFrUvnGPw@mail.gmail.com>

Dear everyone,


I am currently trying to test SSL implementations with PKITS. We already
done the Path Validation part and trying to do the Path Discovery part.

The questions is *I can't find the right APIs for  Path Discovery. Does
GnuTLS support Path Discovery*(automatically locate/download the
intermediate certs CRLs) and verify the target cert?

And does any other SSL implementations support this, like openssl, polarssl?

Please help, I am confused.

Best regards,
Ranpengui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150403/540f3f46/attachment.html>

From nmav at gnutls.org  Wed Apr  8 08:41:40 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 08 Apr 2015 08:41:40 +0200
Subject: [gnutls-devel] GnuTLS 3.4.0 released
Message-ID: <1428475300.4991.8.camel@gnutls.org>

We are proud to announce a new GnuTLS release: Version 3.4.0.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and as well as Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2 (or later).  The "extra" GnuTLS
library (which contains), the OpenSSL compatibility library, the self
tests and the command line tools are all distributed under the GNU
General Public License version 3.0 (or later).  The manual is
distributed under the GNU Free Documentation License version 1.3 (or
later).

The project page of the library is available at:
  http://www.gnutls.org/


What's New
==========

Version 3.4.0 is the first stable release on the 3.4.x branch and is
the result of a year of planning and work [0] on the git master branch. 
The GnuTLS 3.4.x branch is marked as stable-next, meaning it is
considered of stable quality but will not yet replace the current stable
releases based on 3.3.0, which will continue to be supported.

[0]. https://gitlab.com/gnutls/gnutls/wikis/Plan3_4


* Version 3.4.0

** libgnutls: Added support for AES-CCM and AES-CCM-8 (RFC6655 and
RFC7251) ciphersuites. The former are enabled by default, the latter
need to be explicitly enabled, since they reduce the overall security
level.

** libgnutls: Added support for Chacha20-Poly1305 ciphersuites
following draft-mavrogiannopoulos-chacha-tls-05 and
draft-irtf-cfrg-chacha20-poly1305-10. That is currently provided as
technology preview and is not enabled by default, since there are no
assigned ciphersuite points by IETF and there is no guarrantee of
compatibility between draft versions. The ciphersuite priority string
to enable it is "+CHACHA20-POLY1305".

** libgnutls: Added support for encrypt-then-authenticate in CBC
ciphersuites (RFC7366 -taking into account its errata text). This is
enabled by default and can be disabled using the %NO_ETM priority
string.

** libgnutls: Added support for the extended master secret
(triple-handshake fix) following draft-ietf-tls-session-hash-02.

** libgnutls: Added a new simple and hard to misuse AEAD API
(crypto.h).

** libgnutls: SSL 3.0 is no longer included in the default priorities
list. It has to be explicitly enabled, e.g., with a string like
"NORMAL:+VERS-SSL3.0".

** libgnutls: ARCFOUR (RC4) is no longer included in the default
priorities list. It has to be explicitly enabled, e.g., with a string
like "NORMAL:+ARCFOUR-128".

** libgnutls: DSA signatures and DHE-DSS are no longer included in the
default priorities list. They have to be explicitly enabled, e.g., with
a string like "NORMAL:+DHE-DSS:+SIGN-DSA-SHA256:+SIGN-DSA-SHA1". The
DSA ciphersuites were dropped because they had no deployment at all on
the internet, to justify their inclusion.

** libgnutls: The priority string EXPORT was completely removed. The
string was already defunc as support for the EXPORT ciphersuites was
removed in GnuTLS 3.2.0.

** libgnutls: Added API to utilize system specific private keys in
"gnutls/system-keys.h". It is currently provided as technology preview
and is restricted to windows CNG keys.

** libgnutls: gnutls_x509_crt_check_hostname() and friends will use
RFC6125 comparison of hostnames. That introduces a dependency on
libidn.

** libgnutls: Depend on p11-kit 0.23.1 to comply with the final PKCS
#11 URLs draft (draft-pechanec-pkcs11uri-21).

** libgnutls: Depend on nettle 3.1.

** libgnutls: Use getrandom() or getentropy() when available. That
avoids the complexity of file descriptor handling and issues with
applications closing all open file descriptors on startup.

** libgnutls: Use pthread_atfork() to detect fork when available.

** libgnutls: The gnutls_handshake() process will enforce a timeout by
default.

** libgnutls: If a key purpose (extended key usage) is specified for
verification, it is applied into intermediate certificates. The
verification result GNUTLS_CERT_PURPOSE_MISMATCH is also introduced. 

** libgnutls: When gnutls_certificate_set_x509_key_file2() is used in
combination with PKCS #11, or TPM URLs, it will utilize the provided
password as PIN if required. That removes the requirement for the
application to set a callback for PINs in that case.

** libgnutls: priority strings VERS-TLS-ALL and VERS-DTLS-ALL are
restricted to the corresponding protocols only, and the VERS-ALL string
is introduced to catch all possible protocols.

** libgnutls: Added helper functions to obtain information on PKCS #8
structures.

** libgnutls: Certificate chains which are provided to
gnutls_certificate_credentials_t will automatically be sorted instead
of failing with GNUTLS_E_CERTIFICATE_LIST_UNSORTED.

** libgnutls: Added functions to export and set the record state. That
allows for gnutls_record_send() and recv() to be offloaded (to kernel,
hardware or any other subsystem).

** libgnutls: Added the ability to register application specific URL
types, which express certificates and keys using
gnutls_register_custom_url().

** libgnutls: Added API to override existing ciphers, digests and MACs,
e.g., to override AES-GCM using a system-specific accelerator. That is,
(crypto.h) gnutls_crypto_register_cipher(),
gnutls_crypto_register_aead_cipher(), gnutls_crypto_register_mac(), and
gnutls_crypto_register_digest().

** libgnutls: Added gnutls_ext_register() to register custom
extensions. Contributed by Thierry Quemerais.

** libgnutls: Added gnutls_supplemental_register() to register custom
supplemental data handshake messages. Contributed by Thierry Quemerais.

** libgnutls-openssl: it is no longer built by default.

** certtool: Added --p8-info option, which will print PKCS #8
information even if the password is not available.

** certtool: --key-info option will print PKCS #8 encryption
information when available.

** certtool: Added the --key-id and --fingerprint options.

** certtool: Added the --verify-hostname, --verify-email and
--verify-purpose options to be used in certificate chain verification,
to simulate verification for specific hostname and key purpose
(extended key usage). 

** certtool: --p12-info option will print PKCS #12 MAC and cipher
information when available.

** certtool: it will print the A-label (ACE) names in addition to
UTF-8.

** p11tool: added options --set-id and --set-label.

** gnutls-cli: added options --priority-list and --save-cert.

** guile: Deprecated priority API has been removed. The old priority
API, which had been deprecated for some time, is now gone; use
'set-session-priorities!' instead.

** guile: Remove RSA parameters and related procedures. This API had
been deprecated.  

** guile: Fix compilation on MinGW. Previously only the static version
of the 'guile-gnutls-v-2' library would be built, preventing dynamic
loading from Guile.

** API and ABI modifications:
Many new additions and removals of obsolete functions. Check the NEWS
file in the distribution.


Community
=========

If you need help to use GnuTLS, or want to help others, you are invited
to join our help-gnutls mailing list, see:

  http://lists.gnutls.org/mailman/listinfo/gnutls-help

If you wish to participate in the development of GnuTLS, you are invited
to join our gnutls-dev mailing list, see:

  http://lists.gnutls.org/mailman/listinfo/gnutls-devel


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.0.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos





From alon.barlev at gmail.com  Fri Apr 10 01:38:36 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 10 Apr 2015 02:38:36 +0300
Subject: [gnutls-devel] [PATCH] build: remove duplicate man pages
Message-ID: <1428622716-19065-1-git-send-email-alon.barlev@gmail.com>

this causes build to fail with some install utilities.

Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>
---
 doc/manpages/Makefile.am | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/doc/manpages/Makefile.am b/doc/manpages/Makefile.am
index 8e793d3..1bce3f5 100644
--- a/doc/manpages/Makefile.am
+++ b/doc/manpages/Makefile.am
@@ -134,11 +134,8 @@ APIMANS += gnutls_certificate_get_peers.3
 APIMANS += gnutls_certificate_get_peers_subkey_id.3
 APIMANS += gnutls_certificate_get_trust_list.3
 APIMANS += gnutls_certificate_get_verify_flags.3
-APIMANS += gnutls_certificate_get_verify_flags.3
-APIMANS += gnutls_certificate_get_x509_crt.3
 APIMANS += gnutls_certificate_get_x509_crt.3
 APIMANS += gnutls_certificate_get_x509_key.3
-APIMANS += gnutls_certificate_get_x509_key.3
 APIMANS += gnutls_certificate_send_x509_rdn_sequence.3
 APIMANS += gnutls_certificate_server_set_request.3
 APIMANS += gnutls_certificate_set_dh_params.3
-- 
2.0.5



From ranpengui at gmail.com  Fri Apr 10 08:37:36 2015
From: ranpengui at gmail.com (pengui ran)
Date: Fri, 10 Apr 2015 14:37:36 +0800
Subject: [gnutls-devel] =?utf-8?q?Does_GnuTLS_support_path_discovery?=
	=?utf-8?b?77yf?=
In-Reply-To: <CAPYASnYsZgBqGsibJQtkCHv2U6GHM1BVaGLcTakeMcFrUvnGPw@mail.gmail.com>
References: <CAPYASnYsZgBqGsibJQtkCHv2U6GHM1BVaGLcTakeMcFrUvnGPw@mail.gmail.com>
Message-ID: <CAPYASnYDJ1EePO_y4G6Dpk5-Wrxryey4UYUqhity7sA_ujBSpQ@mail.gmail.com>

Hello ~~ Anyone know this?
I just wanna know whether *GnuTLS support path discovery or not*?

Best regards,
Ranpengui

2015-04-03 15:52 GMT+08:00 pengui ran <ranpengui at gmail.com>:

> Dear everyone,
>
>
> I am currently trying to test SSL implementations with PKITS. We already
> done the Path Validation part and trying to do the Path Discovery part.
>
> The questions is *I can't find the right APIs for  Path Discovery. Does
> GnuTLS support Path Discovery*(automatically locate/download the
> intermediate certs CRLs) and verify the target cert?
>
> And does any other SSL implementations support this, like
> openssl, polarssl?
>
> Please help, I am confused.
>
> Best regards,
> Ranpengui
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150410/4015b535/attachment.html>

From alon.barlev at gmail.com  Fri Apr 10 09:29:36 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 10 Apr 2015 10:29:36 +0300
Subject: [gnutls-devel] nettle-3.1 and gnutls-3.3
Message-ID: <CAOazyz2U2nwSMat83UFyFD+ApT6ppDroivnLv9b1e29hxEfJ=g@mail.gmail.com>

Hi,

I see that gnutls-3.3 still cannot be built using nettle-3.1[1], I am
unsure if this is a problem in gnutls or nettle, as nettle-3.1 should
have provided a solution.

Before I go a make nettle installed side by side, are there any
immediate plans to resolve this in gnutls-3.3?

Thanks,
Alon Bar-Lev.

[1] https://bugs.gentoo.org/process_bug.cgi


From alon.barlev at gmail.com  Fri Apr 10 09:30:12 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Fri, 10 Apr 2015 10:30:12 +0300
Subject: [gnutls-devel] nettle-3.1 and gnutls-3.3
In-Reply-To: <CAOazyz2U2nwSMat83UFyFD+ApT6ppDroivnLv9b1e29hxEfJ=g@mail.gmail.com>
References: <CAOazyz2U2nwSMat83UFyFD+ApT6ppDroivnLv9b1e29hxEfJ=g@mail.gmail.com>
Message-ID: <CAOazyz2dvOyW9=iHEG1jAYxrj+jwg1BMeEfYA7FLTNqYH4E0kg@mail.gmail.com>

On 10 April 2015 at 10:29, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Hi,
>
> I see that gnutls-3.3 still cannot be built using nettle-3.1[1], I am
> unsure if this is a problem in gnutls or nettle, as nettle-3.1 should
> have provided a solution.
>
> Before I go a make nettle installed side by side, are there any
> immediate plans to resolve this in gnutls-3.3?
>
> Thanks,
> Alon Bar-Lev.
>
> [1] https://bugs.gentoo.org/process_bug.cgi

sorry:
[1] https://bugs.gentoo.org/show_bug.cgi?id=546100


From nmav at gnutls.org  Fri Apr 10 16:27:06 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 10 Apr 2015 17:27:06 +0300
Subject: [gnutls-devel] =?utf-8?q?Does_GnuTLS_support_path_discovery?=
	=?utf-8?b?77yf?=
In-Reply-To: <CAPYASnYDJ1EePO_y4G6Dpk5-Wrxryey4UYUqhity7sA_ujBSpQ@mail.gmail.com>
References: <CAPYASnYsZgBqGsibJQtkCHv2U6GHM1BVaGLcTakeMcFrUvnGPw@mail.gmail.com>
 <CAPYASnYDJ1EePO_y4G6Dpk5-Wrxryey4UYUqhity7sA_ujBSpQ@mail.gmail.com>
Message-ID: <CAJU7zaJ3-Eo7hwFSV_bwh+M1qg7nyNFadXd9dXDV0yJRz1GPVQ@mail.gmail.com>

On Fri, Apr 10, 2015 at 9:37 AM, pengui ran <ranpengui at gmail.com> wrote:
> Hello ~~ Anyone know this?
> I just wanna know whether GnuTLS support path discovery or not?

No.


From nmav at gnutls.org  Fri Apr 10 16:32:03 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 10 Apr 2015 17:32:03 +0300
Subject: [gnutls-devel] [PATCH] build: remove duplicate man pages
In-Reply-To: <1428622716-19065-1-git-send-email-alon.barlev@gmail.com>
References: <1428622716-19065-1-git-send-email-alon.barlev@gmail.com>
Message-ID: <CAJU7za+HeW41BXikfPvRE4tLMqDOPf4KjKe_2w9w1Xw5=GZdSA@mail.gmail.com>

On Fri, Apr 10, 2015 at 2:38 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> this causes build to fail with some install utilities.
> Signed-off-by: Alon Bar-Lev <alon.barlev at gmail.com>

Thanks. I committed a similar patch.

regards,
Nikos


From nmav at gnutls.org  Fri Apr 10 16:31:17 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 10 Apr 2015 17:31:17 +0300
Subject: [gnutls-devel] nettle-3.1 and gnutls-3.3
In-Reply-To: <CAOazyz2U2nwSMat83UFyFD+ApT6ppDroivnLv9b1e29hxEfJ=g@mail.gmail.com>
References: <CAOazyz2U2nwSMat83UFyFD+ApT6ppDroivnLv9b1e29hxEfJ=g@mail.gmail.com>
Message-ID: <CAJU7zaLSDWLZN6vis2CDZoifqmRsPuB6zfOGSi24MkYZ-rHQ+g@mail.gmail.com>

On Fri, Apr 10, 2015 at 10:29 AM, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> Hi,
> I see that gnutls-3.3 still cannot be built using nettle-3.1[1], I am
> unsure if this is a problem in gnutls or nettle, as nettle-3.1 should
> have provided a solution.
>
> Before I go a make nettle installed side by side, are there any
> immediate plans to resolve this in gnutls-3.3?

The API for nettle 3.0 is incompatible with the API in 2.7 and this is
the reason you cannot compile gnutls 3.3 with the latest nettle. There
is no plan to port gnutls 3.3 to nettle 3.1. You can only use gnutls
3.4 with that version of nettle.

regards,
Nikos


From chenyt at cs.sjtu.edu.cn  Fri Apr 10 18:16:40 2015
From: chenyt at cs.sjtu.edu.cn (=?utf-8?B?6ZmI6Zuo5Lqt?=)
Date: Fri, 10 Apr 2015 09:16:40 -0700
Subject: [gnutls-devel] Does GnuTLS support path discovery? (pengui ran)
In-Reply-To: <mailman.689.1428676501.9341.gnutls-devel@lists.gnutls.org>
References: <mailman.689.1428676501.9341.gnutls-devel@lists.gnutls.org>
Message-ID: <93A7C0DCCB0F46F280D505E6EF58D167@sjtu.edu.cn>

The issue about path discovery has been discussed 
recently in different forums. Forget about it. 

Yuting Chen


From ametzler at bebt.de  Sat Apr 11 19:12:42 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sat, 11 Apr 2015 19:12:42 +0200
Subject: [gnutls-devel] GnuTLS 3.4.0 C++ library
Message-ID: <20150411171242.GC5112@downhill.g.la>

Hello,

while the C library had a soname bump in 3.4.0, the C++ library still
has libgnutlsxx.so.28 as soname. Is this correct or an oversight? The
C++ header is unchanged which suggests to me that the part of the
interface exposed by the C++ library is indeed unchanged.

thanks, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


From nmav at gnutls.org  Sun Apr 12 08:34:10 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 12 Apr 2015 09:34:10 +0300
Subject: [gnutls-devel] GnuTLS 3.4.0 C++ library
In-Reply-To: <20150411171242.GC5112@downhill.g.la>
References: <20150411171242.GC5112@downhill.g.la>
Message-ID: <CAJU7za+8TJoJzopwt+eukVKPNdD5PNdN2rVUfq6Vsf0fWfjPBQ@mail.gmail.com>

On Sat, Apr 11, 2015 at 8:12 PM, Andreas Metzler <ametzler at bebt.de> wrote:
> Hello,
> while the C library had a soname bump in 3.4.0, the C++ library still
> has libgnutlsxx.so.28 as soname. Is this correct or an oversight? The
> C++ header is unchanged which suggests to me that the part of the
> interface exposed by the C++ library is indeed unchanged.

That's correct. There are no changes in the C++ library API or ABI.

regards,
Nikos


From meissner at suse.de  Sun Apr 12 13:04:12 2015
From: meissner at suse.de (Marcus Meissner)
Date: Sun, 12 Apr 2015 13:04:12 +0200
Subject: [gnutls-devel] double manpage packaging
Message-ID: <20150412110409.GA3113@suse.de>

Hi,

My man install page of 3.4.0 complains about doubled files copied.

Attached patch fixes that.

Ciao, Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-fix-double-mans.patch
Type: text/x-patch
Size: 804 bytes
Desc: not available
URL: </pipermail/attachments/20150412/facc392c/attachment.bin>

From ametzler at bebt.de  Sun Apr 12 14:41:13 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Sun, 12 Apr 2015 14:41:13 +0200
Subject: [gnutls-devel] double manpage packaging
In-Reply-To: <20150412110409.GA3113@suse.de>
References: <20150412110409.GA3113@suse.de>
Message-ID: <20150412124113.GA1316@downhill.g.la>

On 2015-04-12 Marcus Meissner <meissner at suse.de> wrote:
> My man install page of 3.4.0 complains about doubled files copied.

> Attached patch fixes that.

Thanks, already fixed in GIT.

https://gitlab.com/gnutls/gnutls/commit/7e63027a5caafa55dcca65c5b9bff3bf76c5a41c

cu Andreas


From cloos at jhcloos.com  Thu Apr 16 17:07:05 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 11:07:05 -0400
Subject: [gnutls-devel] forcing 256bit symetric?
Message-ID: <m3oamojena.fsf@carbon.jhcloos.org>

What is the shortest priority to demand aes256, prefering aead, but
accept the certs in actual use in the wild?

SECURE256 fails because it demands sha512 and essentially no one uses
that to sign certs.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From cloos at jhcloos.com  Thu Apr 16 17:22:44 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 11:22:44 -0400
Subject: [gnutls-devel] ccm segv
Message-ID: <m3iocwjdx7.fsf@carbon.jhcloos.org>

With 3.4, I had to comment out the line:

  test_ciphersuite(PRIO_AES_CCM, size);

in benchmark-tls.c in order to run gnutls-cli --benchmark-tls-ciphers,
else it got a segv.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From cloos at jhcloos.com  Thu Apr 16 17:05:35 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 11:05:35 -0400
Subject: [gnutls-devel] chacha
Message-ID: <m3twwgjeps.fsf@carbon.jhcloos.org>

Are there any sites which accept CCA1?

I found that cloudflare has enabled chacha-poly site wide, but from
what I can determine (mostly by way of ssllabs?) they expect CC13.

I had some difficulty in getting gnutls-cli to send the CCAx suites in
the clienthello.  I just tested again and using priority:

 SECURE128:+CHACHA20-POLY1305

finally worked.

1] https://www.ssllabs.com/ssltest/analyze.html?d=cloudflare.com

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From nmav at gnutls.org  Thu Apr 16 18:26:25 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Apr 2015 19:26:25 +0300
Subject: [gnutls-devel] ccm segv
In-Reply-To: <m3iocwjdx7.fsf@carbon.jhcloos.org>
References: <m3iocwjdx7.fsf@carbon.jhcloos.org>
Message-ID: <1429201585.8190.0.camel@gnutls.org>

On Thu, 2015-04-16 at 11:22 -0400, James Cloos wrote:
> With 3.4, I had to comment out the line:
> 
>   test_ciphersuite(PRIO_AES_CCM, size);
> 
> in benchmark-tls.c in order to run gnutls-cli --benchmark-tls-ciphers,
> else it got a segv.

Thanks. Are you sure it is the benchmark-tls-ciphers, and not the
benchmark-ciphers option? If yes, could you please send the output
of running the command with valgrind?

regards,
Nikos




From nmav at gnutls.org  Thu Apr 16 18:28:25 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Apr 2015 19:28:25 +0300
Subject: [gnutls-devel] forcing 256bit symetric?
In-Reply-To: <m3oamojena.fsf@carbon.jhcloos.org>
References: <m3oamojena.fsf@carbon.jhcloos.org>
Message-ID: <1429201705.8190.2.camel@gnutls.org>

On Thu, 2015-04-16 at 11:07 -0400, James Cloos wrote:
> What is the shortest priority to demand aes256, prefering aead, but
> accept the certs in actual use in the wild?

NORMAL:-CIPHER-ALL:+AES-128-GCM:+...

> SECURE256 fails because it demands sha512 and essentially no one uses
> that to sign certs.

Correct. We may need different keywords to indicate secrecy level of
256-bits, while keeping the handshake security level to the current
defaults.





From nmav at gnutls.org  Thu Apr 16 18:34:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Apr 2015 19:34:37 +0300
Subject: [gnutls-devel] chacha
In-Reply-To: <m3twwgjeps.fsf@carbon.jhcloos.org>
References: <m3twwgjeps.fsf@carbon.jhcloos.org>
Message-ID: <1429202077.8190.8.camel@gnutls.org>

On Thu, 2015-04-16 at 11:05 -0400, James Cloos wrote:
> Are there any sites which accept CCA1?

I don't know any. The draft was updated to include some reference
ciphersuite numbers in the beginning of April.

> I found that cloudflare has enabled chacha-poly site wide, but from
> what I can determine (mostly by way of ssllabs?) they expect CC13.

That is not the standardized algorithm but the initial proposal by
google. The ciphersuites of gnutls use the standardized chacha-poly1305
algorithm, with a draft version of their incorporation in TLS [0].
Unfortunately the TLS working group is very slow in adopting these
ciphersuites.

[0]. https://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-05

regards,
Nikos




From cloos at jhcloos.com  Thu Apr 16 19:05:45 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 13:05:45 -0400
Subject: [gnutls-devel] ccm segv
In-Reply-To: <1429201585.8190.0.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Thu, 16 Apr 2015 19:26:25 +0300")
References: <m3iocwjdx7.fsf@carbon.jhcloos.org>
 <1429201585.8190.0.camel@gnutls.org>
Message-ID: <m3d234j95i.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

NM> Thanks. Are you sure it is the benchmark-tls-ciphers, and not the
NM> benchmark-ciphers option? If yes, could you please send the output
NM> of running the command with valgrind?

Sorry, you are right.

CPU is a Kavari APU.

The backtrace shows:

#0  0x0000000000000000 in ?? ()
No symbol table info available.
#1  0x00007fe37f66656d in _gnutls_cipher_init (handle=handle at entry=0x1229a10, e=e at entry=0x7fe37f953620 <algorithms+160>, key=key at entry=0x7ffd0e7647e0, iv=iv at entry=0x7ffd0e7647f0, enc=enc at entry=1) at /usr/src/debug/net-libs/gnutls-3.4.0/gnutls-3.4.0/lib/gnutls_cipher_int.c:101
        ret = <optimized out>
        cc = 0x7fe37f955fa0 <_gnutls_aes_ccm_x86_aesni>

Line 101 is still line 101 in master (1e4df17a4687).

Valgrind says:

:; valgrind gnutls-cli --benchmark-ciphers
==3053== Memcheck, a memory error detector
==3053== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3053== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3053== Command: gnutls-cli --benchmark-ciphers
==3053== 
vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xCE 0x3 0x1D 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==3053== valgrind: Unrecognised instruction at address 0x4011436.
==3053==    at 0x4011436: _dl_allocate_tls_storage (dl-tls.c:380)
==3053==    by 0x4000EA1: init_tls (rtld.c:623)
==3053==    by 0x4003526: dl_main (rtld.c:1687)
==3053==    by 0x40157EB: _dl_sysdep_start (dl-sysdep.c:249)
==3053==    by 0x4004968: _dl_start_final (rtld.c:308)
==3053==    by 0x4004968: _dl_start (rtld.c:414)
==3053==    by 0x40010A7: ??? (in /lib64/ld-2.20.so)
==3053==    by 0x1: ???
==3053==    by 0xFFEFFD0EA: ???
==3053==    by 0xFFEFFD0F5: ???
==3053== Your program just tried to execute an instruction that Valgrind
==3053== did not recognise.  There are two possible reasons for this.
==3053== 1. Your program has a bug and erroneously jumped to a non-code
==3053==    location.  If you are running Memcheck and you just saw a
==3053==    warning about a bad jump, it's probably your program's fault.
==3053== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3053==    i.e. it's Valgrind's fault.  If you think this is the case or
==3053==    you are not sure, please let us know and we'll try to fix it.
==3053== Either way, Valgrind will now raise a SIGILL signal which will
==3053== probably kill your program.
==3053== 
==3053== Process terminating with default action of signal 4 (SIGILL): dumping core
==3053==  Illegal opcode at address 0x4011436
==3053==    at 0x4011436: _dl_allocate_tls_storage (dl-tls.c:380)
==3053==    by 0x4000EA1: init_tls (rtld.c:623)
==3053==    by 0x4003526: dl_main (rtld.c:1687)
==3053==    by 0x40157EB: _dl_sysdep_start (dl-sysdep.c:249)
==3053==    by 0x4004968: _dl_start_final (rtld.c:308)
==3053==    by 0x4004968: _dl_start (rtld.c:414)
==3053==    by 0x40010A7: ??? (in /lib64/ld-2.20.so)
==3053==    by 0x1: ???
==3053==    by 0xFFEFFD0EA: ???
==3053==    by 0xFFEFFD0F5: ???
==3053== Jump to the invalid address stated on the next line
==3053==    at 0x566: ???
==3053==    by 0x1: ???
==3053==    by 0xFFEFFC5AF: ???
==3053==    by 0x1: ???
==3053==    by 0x1: ???
==3053==    by 0xFFEFFC5AF: ???
==3053==    by 0x4000EA1: init_tls (rtld.c:623)
==3053==    by 0x4003526: dl_main (rtld.c:1687)
==3053==  Address 0x566 is not stack'd, malloc'd or (recently) free'd
==3053== 
==3053== 
==3053== Process terminating with default action of signal 11 (SIGSEGV)
==3053==  Bad permissions for mapped region at address 0x566
==3053==    at 0x566: ???
==3053==    by 0x1: ???
==3053==    by 0xFFEFFC5AF: ???
==3053==    by 0x1: ???
==3053==    by 0x1: ???
==3053==    by 0xFFEFFC5AF: ???
==3053==    by 0x4000EA1: init_tls (rtld.c:623)
==3053==    by 0x4003526: dl_main (rtld.c:1687)
==3053== 
==3053== HEAP SUMMARY:
==3053==     in use at exit: 0 bytes in 0 blocks
==3053==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3053== 
==3053== All heap blocks were freed -- no leaks are possible
==3053== 
==3053== For counts of detected and suppressed errors, rerun with: -v
==3053== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From cloos at jhcloos.com  Thu Apr 16 19:07:39 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 13:07:39 -0400
Subject: [gnutls-devel] chacha
In-Reply-To: <1429202077.8190.8.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Thu, 16 Apr 2015 19:34:37 +0300")
References: <m3twwgjeps.fsf@carbon.jhcloos.org>
 <1429202077.8190.8.camel@gnutls.org>
Message-ID: <m37ftcj92c.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

>> I found that cloudflare has enabled chacha-poly site wide, but from
>> what I can determine (mostly by way of ssllabs?) they expect CC13.

NM> That is not the standardized algorithm but the initial proposal by
NM> google.

I didn't determine who had proposed those, but presumed they were in an
earlier draft or pre-id paper.

NM> The ciphersuites of gnutls use the standardized chacha-poly1305
NM> algorithm, with a draft version of their incorporation in TLS [0].

That I knew.

Thanks,

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From cloos at jhcloos.com  Thu Apr 16 19:18:46 2015
From: cloos at jhcloos.com (James Cloos)
Date: Thu, 16 Apr 2015 13:18:46 -0400
Subject: [gnutls-devel] forcing 256bit symetric?
In-Reply-To: <1429201705.8190.2.camel@gnutls.org> (Nikos Mavrogiannopoulos's
 message of "Thu, 16 Apr 2015 19:28:25 +0300")
References: <m3oamojena.fsf@carbon.jhcloos.org>
 <1429201705.8190.2.camel@gnutls.org>
Message-ID: <m31tjkj8jt.fsf@carbon.jhcloos.org>

>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

JC>> What is the shortest priority to demand aes256, prefering aead, but
JC>> accept the certs in actual use in the wild?

NM> NORMAL:-CIPHER-ALL:+AES-128-GCM:+...

That gave me the hint I needed.  I ended up with:

  NORMAL:-VERS-ALL:+VERS-TLS1.2:-CIPHER-ALL:+CHACHA20-POLY1305:+AES-256-GCM

I'll add +AES-256-CCM once I know it is happy on my box.

>> SECURE256 fails because it demands sha512 and essentially no one uses
>> that to sign certs.

NM> Correct. We may need different keywords to indicate secrecy level of
NM> 256-bits, while keeping the handshake security level to the current
NM> defaults.

Sounds like a plan.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6


From home_pw at msn.com  Thu Apr 16 19:40:35 2015
From: home_pw at msn.com (Peter Williams)
Date: Thu, 16 Apr 2015 17:40:35 +0000
Subject: [gnutls-devel] =?utf-8?q?forcing_256bit_symetric=3F?=
Message-ID: <BAY404-EAS399B834728CD0653C8A099592E40@phx.gbl>

we never intended that the ssl ciphersuite addressed cert algs.


one has to be carefuy in designing security protocols (specially if one knows something about how they can and typically are designed-in by standards committee ?consensus? to be broken by cryptanalytical hardware tuned into oracles).






Sent from Windows Mail





From: James Cloos
Sent: ?Thursday?, ?April? ?16?, ?2015 ?10?:?20? ?AM
To: Nikos Mavrogiannopoulos
Cc: GnuTLS development list





>>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

JC>> What is the shortest priority to demand aes256, prefering aead, but
JC>> accept the certs in actual use in the wild?

NM> NORMAL:-CIPHER-ALL:+AES-128-GCM:+...

That gave me the hint I needed.  I ended up with:

  NORMAL:-VERS-ALL:+VERS-TLS1.2:-CIPHER-ALL:+CHACHA20-POLY1305:+AES-256-GCM

I'll add +AES-256-CCM once I know it is happy on my box.

>> SECURE256 fails because it demands sha512 and essentially no one uses
>> that to sign certs.

NM> Correct. We may need different keywords to indicate secrecy level of
NM> 256-bits, while keeping the handshake security level to the current
NM> defaults.

Sounds like a plan.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel at lists.gnutls.org
http://lists.gnupg.org/mailman/listinfo/gnutls-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150416/fc001529/attachment.html>

From nmav at gnutls.org  Thu Apr 16 21:26:15 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 16 Apr 2015 22:26:15 +0300
Subject: [gnutls-devel] ccm segv
In-Reply-To: <m3d234j95i.fsf@carbon.jhcloos.org>
References: <m3iocwjdx7.fsf@carbon.jhcloos.org>
 <1429201585.8190.0.camel@gnutls.org> <m3d234j95i.fsf@carbon.jhcloos.org>
Message-ID: <1429212375.11859.1.camel@gnutls.org>

On Thu, 2015-04-16 at 13:05 -0400, James Cloos wrote:
> >>>>> "NM" == Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> NM> Thanks. Are you sure it is the benchmark-tls-ciphers, and not the
> NM> benchmark-ciphers option? If yes, could you please send the output
> NM> of running the command with valgrind?
> 
> Sorry, you are right.
> 
> CPU is a Kavari APU.
> 
> The backtrace shows:
> #0  0x0000000000000000 in ?? ()
> No symbol table info available.
> #1  0x00007fe37f66656d in _gnutls_cipher_init (handle=handle at entry=0x1229a10, e=e at entry=0x7fe37f953620 <algorithms+160>, key=key at entry=0x7ffd0e7647e0, iv=iv at entry=0x7ffd0e7647f0, enc=enc at entry=1) at /usr/src/debug/net-libs/gnutls-3.4.0/gnutls-3.4.0/lib/gnutls_cipher_int.c:101
>         ret = <optimized out>
>         cc = 0x7fe37f955fa0 <_gnutls_aes_ccm_x86_aesni>

Ok. Should be ok now. It was a fault of the benchmark in gnutls-cli. The
CCM cipher only provides the new AEAD API which the benchmark didn't
use.

regards,
Nikos




From tim.kosse at filezilla-project.org  Sat Apr 18 11:38:53 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 11:38:53 +0200
Subject: [gnutls-devel] [PATCH 0/4] Fixes to compile GnuTLS 3.4.0 using MinGW
Message-ID: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>

Hi,

this set of patches fixes cross-compiling GnuTLS 3.4.0 using MinGW as packaged in Debian Jessie, please see each patch for details.

The issues are new to 3.4.x and do not affect 3.3.x or older.

Regards,
Tim Kosse


Tim Kosse (4):
  Fix include order, include gnutls_int.h before gnutls.h, otherwise
    undefined external references to gnutls_free and gnutls_strdup are
    the result when statically linking against GnuTLS built by MinGW.
  Set _WIN32_WINNT to 0x600, at least with some MinGW versions ncrypt.h
    checks this define to be at least 0x600.
  Fix a preprocessor warning about mismatched quotes.
  ncrypt.h lacks some defines with some versions of MinGW.

 lib/gnutls_supplemental.c |  2 +-
 lib/system-keys-win.c     | 36 ++++++++++++++++++++++++++++++++----
 2 files changed, 33 insertions(+), 5 deletions(-)

-- 
2.1.4



From tim.kosse at filezilla-project.org  Sat Apr 18 11:38:54 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 11:38:54 +0200
Subject: [gnutls-devel] [PATCH 1/4] Fix include order,
	include gnutls_int.h before gnutls.h,
	otherwise undefined external references to gnutls_free and
	gnutls_strdup are the result when statically linking against
	GnuTLS built by MinGW.
In-Reply-To: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <1429349937-2571-2-git-send-email-tim.kosse@filezilla-project.org>

---
 lib/gnutls_supplemental.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/gnutls_supplemental.c b/lib/gnutls_supplemental.c
index 9964cfd..91dfeb1 100644
--- a/lib/gnutls_supplemental.c
+++ b/lib/gnutls_supplemental.c
@@ -43,8 +43,8 @@
  * want to send any data, it is fine to return without doing anything.
  */
 
-#include <gnutls/gnutls.h>
 #include "gnutls_int.h"
+#include <gnutls/gnutls.h>
 #include "gnutls_supplemental.h"
 #include "gnutls_errors.h"
 #include "gnutls_num.h"
-- 
2.1.4



From tim.kosse at filezilla-project.org  Sat Apr 18 11:38:57 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 11:38:57 +0200
Subject: [gnutls-devel] [PATCH 4/4] ncrypt.h lacks some defines with some
	versions of MinGW.
In-Reply-To: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <1429349937-2571-5-git-send-email-tim.kosse@filezilla-project.org>

---
 lib/system-keys-win.c | 26 +++++++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/lib/system-keys-win.c b/lib/system-keys-win.c
index 610cc23..273ae28 100644
--- a/lib/system-keys-win.c
+++ b/lib/system-keys-win.c
@@ -46,10 +46,30 @@
 
 #define DYN_NCRYPT
 
-#ifndef DYN_NCRYPT
-# include <ncrypt.h>
+#include <ncrypt.h>
+
+// MinGW headers may not have these defines
+#ifndef NCRYPT_SHA1_ALGORITHM
+#define NCRYPT_SHA1_ALGORITHM           BCRYPT_SHA1_ALGORITHM
+#endif
+#ifndef NCRYPT_SHA256_ALGORITHM
+#define NCRYPT_SHA256_ALGORITHM         BCRYPT_SHA256_ALGORITHM
+#endif
+#ifndef NCRYPT_SHA384_ALGORITHM
+#define NCRYPT_SHA384_ALGORITHM         BCRYPT_SHA384_ALGORITHM
+#endif
+#ifndef NCRYPT_SHA512_ALGORITHM
+#define NCRYPT_SHA512_ALGORITHM         BCRYPT_SHA512_ALGORITHM
+#endif
+#ifndef NCRYPT_PAD_PKCS1_FLAG
+#define NCRYPT_PAD_PKCS1_FLAG 2
+#endif
+#ifndef NCRYPT_ALGORITHM_PROPERTY
+#define NCRYPT_ALGORITHM_PROPERTY               L"Algorithm Name"
+#endif
+#ifndef CERT_NCRYPT_KEY_HANDLE_TRANSFER_PROP_ID
+#define CERT_NCRYPT_KEY_HANDLE_TRANSFER_PROP_ID 99
 #endif
-/* ncrypt.h and shlwapi.h not included to allow compilation in windows XP */
 
 #define MAX_WID_SIZE 48
 
-- 
2.1.4



From tim.kosse at filezilla-project.org  Sat Apr 18 11:38:56 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 11:38:56 +0200
Subject: [gnutls-devel] [PATCH 3/4] Fix a preprocessor warning about
	mismatched quotes.
In-Reply-To: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <1429349937-2571-4-git-send-email-tim.kosse@filezilla-project.org>

---
 lib/system-keys-win.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/system-keys-win.c b/lib/system-keys-win.c
index 6eb6446..610cc23 100644
--- a/lib/system-keys-win.c
+++ b/lib/system-keys-win.c
@@ -38,7 +38,7 @@
 #include <urls.h>
 
 #if !defined(_WIN32)
-# error shouldn't be included
+# error should not be included
 #endif
 
 #include <wincrypt.h>
-- 
2.1.4



From tim.kosse at filezilla-project.org  Sat Apr 18 11:38:55 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 11:38:55 +0200
Subject: [gnutls-devel] [PATCH 2/4] Set _WIN32_WINNT to 0x600,
	at least with some MinGW versions ncrypt.h checks this define to be
	at least 0x600.
In-Reply-To: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <1429349937-2571-3-git-send-email-tim.kosse@filezilla-project.org>

---
 lib/system-keys-win.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/lib/system-keys-win.c b/lib/system-keys-win.c
index 992ec6d..6eb6446 100644
--- a/lib/system-keys-win.c
+++ b/lib/system-keys-win.c
@@ -18,6 +18,14 @@
  *
  */
 
+// Before including any Windows header we need to set _WIN32_WINNT to Vista
+// (or higher) so that the NCRYPT stuff can be used.
+#if _WIN32_WINNT < 0x600
+#undef _WIN32_WINNT
+#define _WIN32_WINNT 0x600
+#endif
+
+
 #include <gnutls_int.h>
 #include <gnutls_errors.h>
 #include <gnutls/gnutls.h>
-- 
2.1.4



From eliz at gnu.org  Sat Apr 18 12:59:39 2015
From: eliz at gnu.org (Eli Zaretskii)
Date: Sat, 18 Apr 2015 13:59:39 +0300
Subject: [gnutls-devel] [PATCH 2/4] Set _WIN32_WINNT to 0x600,
	at least with some MinGW versions ncrypt.h checks this define to
	be	at least 0x600.
In-Reply-To: <1429349937-2571-3-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
 <1429349937-2571-3-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <83y4lp7ld0.fsf@gnu.org>

> From: Tim Kosse <tim.kosse at filezilla-project.org>
> Date: Sat, 18 Apr 2015 11:38:55 +0200
> 
> +// Before including any Windows header we need to set _WIN32_WINNT to Vista
> +// (or higher) so that the NCRYPT stuff can be used.
> +#if _WIN32_WINNT < 0x600
> +#undef _WIN32_WINNT
> +#define _WIN32_WINNT 0x600
> +#endif

Doesn't this mean the produced GnuTLS will refuse to run on XP and
older, even if the NCRYPT functionality is not used at all, because it
will be linked against ncrypt.dll?  If so, I don't think this is the
right fix; instead, GnuTLS should load ncrypt.dll dynamically, when
needed, and call the functions from there via pointers.


From tim.kosse at filezilla-project.org  Sat Apr 18 13:27:16 2015
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 18 Apr 2015 13:27:16 +0200
Subject: [gnutls-devel] [PATCH 2/4] Set _WIN32_WINNT to 0x600,
 at least with some MinGW versions ncrypt.h checks this define to
 be	at least 0x600.
In-Reply-To: <83y4lp7ld0.fsf@gnu.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
 <1429349937-2571-3-git-send-email-tim.kosse@filezilla-project.org>
 <83y4lp7ld0.fsf@gnu.org>
Message-ID: <55323F94.8080208@filezilla-project.org>

Hi,

merely #including ncrypt.h doesn't link against ncrypt.dll, nor does it
add a library dependency. For that -lncrypt would be needed as linker
argument and one of the exported symbols would need to be used.

GnuTLS already loads ncrypt.dll dynamically, nonetheless it still needs
to include ncrypt.h in order to use the constants defined in it.

Regards,
Tim

On 2015-04-18 12:59, Eli Zaretskii wrote:
>> From: Tim Kosse <tim.kosse at filezilla-project.org>
>> Date: Sat, 18 Apr 2015 11:38:55 +0200
>>
>> +// Before including any Windows header we need to set _WIN32_WINNT to Vista
>> +// (or higher) so that the NCRYPT stuff can be used.
>> +#if _WIN32_WINNT < 0x600
>> +#undef _WIN32_WINNT
>> +#define _WIN32_WINNT 0x600
>> +#endif
> 
> Doesn't this mean the produced GnuTLS will refuse to run on XP and
> older, even if the NCRYPT functionality is not used at all, because it
> will be linked against ncrypt.dll?  If so, I don't think this is the
> right fix; instead, GnuTLS should load ncrypt.dll dynamically, when
> needed, and call the functions from there via pointers.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150418/b382f38b/attachment.sig>

From nmav at gnutls.org  Sun Apr 19 09:25:44 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 19 Apr 2015 09:25:44 +0200
Subject: [gnutls-devel] [PATCH 0/4] Fixes to compile GnuTLS 3.4.0 using
 MinGW
In-Reply-To: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
References: <1429349937-2571-1-git-send-email-tim.kosse@filezilla-project.org>
Message-ID: <1429428344.1699.3.camel@gnutls.org>

On Sat, 2015-04-18 at 11:38 +0200, Tim Kosse wrote:
> Hi,
> 
> this set of patches fixes cross-compiling GnuTLS 3.4.0 using MinGW as packaged in Debian Jessie, please see each patch for details.
> The issues are new to 3.4.x and do not affect 3.3.x or older.

Thank you. All applied.





From ametzler at bebt.de  Mon Apr 20 19:56:01 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Mon, 20 Apr 2015 19:56:01 +0200
Subject: [gnutls-devel] Successor of gnutls_certificate_type_set_priority()
Message-ID: <20150420175601.GB1342@downhill.g.la>

Hello,

3.4.0 dropped gnutls_certificate_type_set_priority(), listing
gnutls_priority_set_direct() as replacement. However as far as I can
tell, priority strings do not have a keyword for certificate_type
(GNUTLS_CRT_X509, GNUTLS_CRT_OPENPGP).

The documentation somehow implies it is possible, but does not say
how:
| Unless the initial keyword is "NONE" the defaults (in preference
| order) are for TLS protocols TLS 1.2, TLS1.1, TLS1.0; for compression
| NULL; for certificate types X.509. In key exchange algorithms when in
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
| NORMAL or SECURE levels the perfect forward secrecy algorithms take
| precedence of the other protocols. In all cases all the supported key
| exchange algorithms are enabled.

I have started wondering when looking for a replacement for this code
in ekg2:
|   /* Allow connections to servers that have OpenPGP keys as well. */
|   const int cert_type_priority[3] = {GNUTLS_CRT_X509, GNUTLS_CRT_OPENPGP, 0};
[...]
|   gnutls_certificate_type_set_priority(ssl, cert_type_priority);

cu Andreas


From nmav at gnutls.org  Mon Apr 20 20:14:12 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 20 Apr 2015 20:14:12 +0200
Subject: [gnutls-devel] Successor of
 gnutls_certificate_type_set_priority()
In-Reply-To: <20150420175601.GB1342@downhill.g.la>
References: <20150420175601.GB1342@downhill.g.la>
Message-ID: <1429553652.1681.2.camel@gnutls.org>

On Mon, 2015-04-20 at 19:56 +0200, Andreas Metzler wrote:
> Hello,
> 
> 3.4.0 dropped gnutls_certificate_type_set_priority(), listing
> gnutls_priority_set_direct() as replacement. However as far as I can
> tell, priority strings do not have a keyword for certificate_type
> (GNUTLS_CRT_X509, GNUTLS_CRT_OPENPGP).
> The documentation somehow implies it is possible, but does not say
> how:

Hi,
 There is +CTYPE-OPENPGP and CTYPE-X509. They are briefly discussed in
the manual, and listed in "gnutls-cli -l". I you have a better idea on
how to list them to be more apparent I'd be happy to incorporate it.

regards,
Nikos




From ametzler at bebt.de  Tue Apr 21 19:25:27 2015
From: ametzler at bebt.de (Andreas Metzler)
Date: Tue, 21 Apr 2015 19:25:27 +0200
Subject: [gnutls-devel] Successor of
 gnutls_certificate_type_set_priority()
In-Reply-To: <1429553652.1681.2.camel@gnutls.org>
References: <20150420175601.GB1342@downhill.g.la>
 <1429553652.1681.2.camel@gnutls.org>
Message-ID: <20150421172527.GB1519@downhill.g.la>

On 2015-04-20 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On Mon, 2015-04-20 at 19:56 +0200, Andreas Metzler wrote:
>> 3.4.0 dropped gnutls_certificate_type_set_priority(), listing
>> gnutls_priority_set_direct() as replacement. However as far as I can
>> tell, priority strings do not have a keyword for certificate_type
>> (GNUTLS_CRT_X509, GNUTLS_CRT_OPENPGP).
>> The documentation somehow implies it is possible, but does not say
>> how:

> Hi,
>  There is +CTYPE-OPENPGP and CTYPE-X509. They are briefly discussed in
> the manual, and listed in "gnutls-cli -l". I you have a better idea on
> how to list them to be more apparent I'd be happy to incorporate it.

Hello,

I thinking adding them to table in the manual would help a lot.
Trivial patch attached.

thanks, cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-List-all-certificate-type-priority-strings.patch
Type: text/x-diff
Size: 832 bytes
Desc: not available
URL: </pipermail/attachments/20150421/8c2c23ed/attachment.patch>

From INVALID.NOREPLY at gnu.org  Thu Apr 23 18:14:58 2015
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Thu, 23 Apr 2015 16:14:58 +0000
Subject: [gnutls-devel] [sr #108806] Cross build of GnuTLS for ARM links
	against build system libraries
Message-ID: <20150423-161457.sv0.77469@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?108806>

                 Summary: Cross build of GnuTLS for ARM links against build
system libraries
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Thu 23 Apr 2015 04:14:56 PM UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: scotty at a-concepts.com
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

When attempting to cross build GnuTLS 3.3.14 for ARM, libtool is forcing the
library to link against the build system crti.o and crtbeginS.o:

libtool: link: g++  -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginS.o  .libs/libgnutlsxx_la-gnutlsxx.o
  -Wl,-rpath -Wl,/home/jhe/lidarcam-base/gnutls-3.3.14/lib/.libs -Wl,-rpath
-Wl,/home/jhe/lidarcam-base/gnutls-3.3.14-build/usr/lib ./.libs/libgnutls.so
-L/usr/lib/gcc/x86_64-linux-gnu/4.8
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o  -O2  
-Wl,-soname -Wl,libgnutlsxx.so.28 -o .libs/libgnutlsxx.so.28.1.0
./.libs/libgnutls.so: error adding symbols: File in wrong format
collect2: error: ld returned 1 exit status

Configure command:

./configure --host=arm-linux-gnueabi --prefix=${GNUTLS_INSTALL}
--exec-prefix=${GNUTLS_INSTALL} --disable-openssl-compatibility --disable-doc
--disable-tests --disable-valgrind-tests --enable-local-libopts
--enable-libopts-install --with-included-libtasn1 --disable-libdane
--disable-guile --without-p11-kit --without-tpm --disable-silent-rules

I have valid crti.o and crtbeginS.o in my target libraries but libtool is
forcing the build system versions to be used.

Any suggestions would be appreciated - I'm shut down on my project

Scotty





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108806>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



From INVALID.NOREPLY at gnu.org  Thu Apr 23 18:52:01 2015
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Thu, 23 Apr 2015 16:52:01 +0000
Subject: [gnutls-devel] [sr #108806] Cross build of GnuTLS for ARM links
	against build system libraries
In-Reply-To: <20150423-161457.sv0.77469@savannah.gnu.org>
References: <20150423-161457.sv0.77469@savannah.gnu.org>
Message-ID: <20150423-165201.sv0.54282@savannah.gnu.org>

Follow-up Comment #1, sr #108806 (project gnutls):

I forgot to mention...The CC environment variable points to my cross
compiler.

Scotty

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108806>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/



From karthik.bhargavan at gmail.com  Sat Apr 25 16:55:31 2015
From: karthik.bhargavan at gmail.com (Karthikeyan Bhargavan)
Date: Sat, 25 Apr 2015 16:55:31 +0200
Subject: [gnutls-devel] Prevent MD5 Downgrade in TLS signatures
Message-ID: <C0F49D12-DAC8-4662-AFED-28152D99BA86@gmail.com>

Prevent MD5 Downgrade in TLS 1.2 Signatures
-------------------------------------------

GnuTLS does not by default support MD5 signatures. Indeed the RSA-MD5
signature-hash algorithm needs to be explicitly enabled using the
priority option VERIFY_ALLOW_SIGN_RSA_MD5. In the NORMAL and SECURE
profiles, GnuTLS clients do not offer RSA-MD5 in the signature
algorithms extension. However, we find that all GnuTLS clients still
accept RSA-MD5 in the ServerKeyExchange and GnuTLS servers still
accept RSA-MD5 in the ClientCertificateVerify.

To see the bug, connect with GnuTLS to an openssl 1.0.1m server with a
modified ssl/s3_srvr.c (attached) which always signs the
ServerKeyExchange with RSA-MD5.  When gnutls-cli connects to a server,
its signature algorithms extension only advertises signature/hash
algorithms that use the SHA family. Notably, it should not allow any
MD5 signature. However, when our server sends it an RSA-MD5 signature,
NSS does not check that this algorithm is included in the allowed
algorithms and quietly accepts it, hence downgrading the expected
security of the connection. 

The root cause for this bug is that, unlike previous versions, TLS 1.2
allows the signer to choose any combination of signature and hash
algorithm (even ECDSA-MD5 if it so wishes) and it is up to the
verifier to check that the algorithm is acceptable. Notably, the
current TLS 1.3 draft also allows MD5 signatures. This means that
unless a TLS library is careful, it may unexpectedly weaken the
security of signatures when upgrading to TLS 1.2.  This potential bug
has been noted before on the TLS mailing list:
https://www.ietf.org/mail-archive/web/tls/current/msg15270.html

We report that GnuTLS currently allows any signature/hash algorithm
combination defined in the sign_algorithms structure in
algorithms/sign.c, including RSA-MD5 and even RSA-RMD160, even though
these algorithms are never sent in the signature algorithms extension
in the client hello.  Similarly, in the ClientCertificateVerify
message, GnuTLS allows any combination defined in this
structure. However, GnuTLS clients and server will themselves never
generate such signatures, although other TLS libraries may do so.

We do not believe that the bug currently exposes any critical
exploits.  The impact of the bug depends on whether an adversary can
trigger meaningful collisions in TLS client and server
signatures. Folklore about TLS has previously suggested that only
second preimage attacks "break" TLS signatures, but collisions do
not. We challenge this assumption and attach a draft research report
that shows that collision resistance is *essential* for the security
of client and server signatures in TLS. We show how chosen-prefix
collisions in the hash function can be used to forge client signatures
in TLS 1.2 and server signatures in TLS 1.3.  We believe this result
is of independent interest for TLS specialists. In particular,
collisions in any of the handshake hashes (including those used in the
Finished message) in TLS can be translated to man-in-the-middle
attacks. Having said that, our proof-of-concept attacks in the
attached report take several hours on academic hardware and are not
widely exploitable.

We would be happy to provide further tests (such as a test server) and
discuss countermeasures. The straightforward fix is to check that the
signature/hash algorithm in the ServerKeyExchange and
ClientCertificateVerify messages is one of the allowed algorithms,
and that it was sent in the ClientHello.




From nmav at gnutls.org  Sat Apr 25 20:30:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 25 Apr 2015 20:30:37 +0200
Subject: [gnutls-devel] Prevent MD5 Downgrade in TLS signatures
In-Reply-To: <C0F49D12-DAC8-4662-AFED-28152D99BA86@gmail.com>
References: <C0F49D12-DAC8-4662-AFED-28152D99BA86@gmail.com>
Message-ID: <1429986637.22618.7.camel@gnutls.org>

On Sat, 2015-04-25 at 16:55 +0200, Karthikeyan Bhargavan wrote:
> Prevent MD5 Downgrade in TLS 1.2 Signatures
> -------------------------------------------
> 
> GnuTLS does not by default support MD5 signatures. Indeed the RSA-MD5
> signature-hash algorithm needs to be explicitly enabled using the
> priority option VERIFY_ALLOW_SIGN_RSA_MD5. In the NORMAL and SECURE
> profiles, GnuTLS clients do not offer RSA-MD5 in the signature
> algorithms extension. However, we find that all GnuTLS clients still
> accept RSA-MD5 in the ServerKeyExchange and GnuTLS servers still
> accept RSA-MD5 in the ClientCertificateVerify.
> 
> To see the bug, connect with GnuTLS to an openssl 1.0.1m server with a
> modified ssl/s3_srvr.c (attached) which always signs the
> ServerKeyExchange with RSA-MD5.  When gnutls-cli connects to a server,
> its signature algorithms extension only advertises signature/hash
> algorithms that use the SHA family. Notably, it should not allow any
> MD5 signature. However, when our server sends it an RSA-MD5 signature,
> NSS does not check that this algorithm is included in the allowed
> algorithms and quietly accepts it, hence downgrading the expected
> security of the connection. 

Hello Karthikeyan,
 That's a nice catch. There seems to be an issue in the function which
checked the used algorithm for validity. I've managed to make a
reproducer, but could you send yours as well (the attachment was
missing).

regards,
Nikos




From jan.vcelak at nic.cz  Tue Apr 28 13:50:39 2015
From: jan.vcelak at nic.cz (Jan Vcelak)
Date: Tue, 28 Apr 2015 13:50:39 +0200
Subject: [gnutls-devel] Memory leak in the ECDSA key generation
Message-ID: <1430221840-16260-1-git-send-email-jan.vcelak@nic.cz>

Hello list,

the attached patch fixes memory leak when generating or verifying an ECDSA key.

The patch is formatted to fit the gnutls_3_3_x branch. But the problem seems
to be present on master as well.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.


Best Regards,

Jan V?el?k
CZ.NIC Labs


From jan.vcelak at nic.cz  Tue Apr 28 13:50:40 2015
From: jan.vcelak at nic.cz (Jan Vcelak)
Date: Tue, 28 Apr 2015 13:50:40 +0200
Subject: [gnutls-devel] [PATCH] fix memory leak in ECDSA key parameters
	verification
In-Reply-To: <1430221840-16260-1-git-send-email-jan.vcelak@nic.cz>
References: <1430221840-16260-1-git-send-email-jan.vcelak@nic.cz>
Message-ID: <1430221840-16260-2-git-send-email-jan.vcelak@nic.cz>

Signed-off-by: Jan Vcelak <jan.vcelak at nic.cz>
---
 lib/nettle/pk.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lib/nettle/pk.c b/lib/nettle/pk.c
index 66815f0..7ac879f 100644
--- a/lib/nettle/pk.c
+++ b/lib/nettle/pk.c
@@ -1578,6 +1578,11 @@ wrap_nettle_pk_verify_priv_params(gnutls_pk_algorithm_t algo,
 		      ecc_cleanup:
 			ecc_scalar_zclear(&priv);
 			ecc_point_clear(&pub);
+
+			mpz_clear(x1);
+			mpz_clear(y1);
+			mpz_clear(x2);
+			mpz_clear(y2);
 		}
 		break;
 	default:
-- 
2.3.6



From nmav at gnutls.org  Tue Apr 28 16:25:25 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 28 Apr 2015 16:25:25 +0200
Subject: [gnutls-devel] [PATCH] fix memory leak in ECDSA key parameters
	verification
In-Reply-To: <1430221840-16260-2-git-send-email-jan.vcelak@nic.cz>
References: <1430221840-16260-1-git-send-email-jan.vcelak@nic.cz>
 <1430221840-16260-2-git-send-email-jan.vcelak@nic.cz>
Message-ID: <CAJU7zaJy-5oLhYfooZyAwk3Za1rva9EM_CPpN9HJLFFOo0HMiA@mail.gmail.com>

On Tue, Apr 28, 2015 at 1:50 PM, Jan Vcelak <jan.vcelak at nic.cz> wrote:
> Signed-off-by: Jan Vcelak <jan.vcelak at nic.cz>
> ---
>  lib/nettle/pk.c | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/lib/nettle/pk.c b/lib/nettle/pk.c
> index 66815f0..7ac879f 100644
> --- a/lib/nettle/pk.c
> +++ b/lib/nettle/pk.c
> @@ -1578,6 +1578,11 @@ wrap_nettle_pk_verify_priv_params(gnutls_pk_algorithm_t algo,

Thanks, applied. I was wondering why this wasn't caught in the test
suite, and it seems that key generation was in the tests/slow
directory which runs without valgrind. Also updated.

regards,
Nikos