From sandals at crustytoothpaste.net Sat Sep 1 01:42:52 2012 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Fri, 31 Aug 2012 23:42:52 +0000 Subject: gnutls claims a disabled algorithm was negotiated Message-ID: <20120831234252.GA1006360@crustytoothpaste.ath.cx> I've recently moved my mail server to running postfix, and as a result, am now able to provide an EC key and certificate for TLS (the certificate is signed by my local RSA CA). However, when I try to connect to postfix either using gnutls-cli or mutt (linked against 3.0.22), gnutls provides the following error: *** Fatal error: An algorithm that is not enabled was negotiated. This seems odd to me, since OpenSSL is very happy to make the connection (as the client), and the algorithm that was negotiated is ECDHE_ECDSA_AES_128_GCM_SHA256, which I'm pretty sure both GnuTLS and OpenSSL support. It also is odd that the complaint doesn't happen until GnuTLS tries to verify the signature; shouldn't it die sooner if the server picks an algorithm that it doesn't support? Anyway, some help would be great. I looked through the mailing list archive and in Google, but found nothing. I've attached a debug log. I can provide the certificate on request, but I can't leave postfix with it enabled, or I can't send mail. Also, I'm using Debian sid, if that's useful to know. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -------------- next part -------------- |<2>| Intel AES accelerator was detected |<2>| Intel GCM accelerator was detected |<2>| p11: loaded provider 'gnome-keyring-module' with 5 slots |<2>| ASSERT: pkcs11.c:459 Processed 152 CA certificate(s). Resolving 'smtp.crustytoothpaste.net'... Connecting to '2001:470:1f05:79::1:587'... |<4>| REC[0x188ae60]: Allocating epoch #0 - Simple Client Mode: 220 castro.crustytoothpaste.net ESMTP Postfix (Debian GNU/Linux) EHLO lakeview 250-castro.crustytoothpaste.net 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH GSSAPI 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN STARTTLS 220 2.0.0 Ready to start TLS *** Starting TLS handshake |<2>| ASSERT: gnutls_constate.c:717 |<4>| REC[0x188ae60]: Allocating epoch #1 |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 (C0.09) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 (C0.0A) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 (C0.08) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 (C0.2F) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 (C0.27) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 (C0.30) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14) |<3>| HSK[0x188ae60]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 (C0.12) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 (00.45) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 (00.88) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256 (00.A2) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 (00.40) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 (00.6A) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 (00.44) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 (00.87) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13) |<3>| HSK[0x188ae60]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05) |<3>| HSK[0x188ae60]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04) |<3>| EXT[0x188ae60]: Sending extension SERVER NAME (30 bytes) |<3>| EXT[0x188ae60]: Sending extension SAFE RENEGOTIATION (1 bytes) |<3>| EXT[0x188ae60]: Sending extension SUPPORTED ECC (12 bytes) |<3>| EXT[0x188ae60]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) |<3>| EXT[0x188ae60]: sent signature algo (4.1) RSA-SHA256 |<3>| EXT[0x188ae60]: sent signature algo (4.2) DSA-SHA256 |<3>| EXT[0x188ae60]: sent signature algo (4.3) ECDSA-SHA256 |<3>| EXT[0x188ae60]: sent signature algo (5.1) RSA-SHA384 |<3>| EXT[0x188ae60]: sent signature algo (5.3) ECDSA-SHA384 |<3>| EXT[0x188ae60]: sent signature algo (6.1) RSA-SHA512 |<3>| EXT[0x188ae60]: sent signature algo (6.3) ECDSA-SHA512 |<3>| EXT[0x188ae60]: sent signature algo (3.1) RSA-SHA224 |<3>| EXT[0x188ae60]: sent signature algo (3.2) DSA-SHA224 |<3>| EXT[0x188ae60]: sent signature algo (3.3) ECDSA-SHA224 |<3>| EXT[0x188ae60]: sent signature algo (2.1) RSA-SHA1 |<3>| EXT[0x188ae60]: sent signature algo (2.2) DSA-SHA1 |<3>| EXT[0x188ae60]: sent signature algo (2.3) ECDSA-SHA1 |<3>| EXT[0x188ae60]: Sending extension SIGNATURE ALGORITHMS (28 bytes) |<3>| HSK[0x188ae60]: CLIENT HELLO was queued [218 bytes] |<4>| REC[0x188ae60]: Preparing Packet Handshake(22) with length: 218 |<4>| REC[0x188ae60]: Sent Packet[1] Handshake(22) in epoch 0 and length: 223 |<2>| ASSERT: gnutls_buffers.c:976 |<4>| REC[0x188ae60]: SSL 3.3 Handshake packet received. Epoch 0, length: 89 |<4>| REC[0x188ae60]: Expected Packet Handshake(22) |<4>| REC[0x188ae60]: Received Packet Handshake(22) with length: 89 |<4>| REC[0x188ae60]: Decrypted Packet[0] Handshake(22) with length: 89 |<3>| HSK[0x188ae60]: SERVER HELLO was received. Length 85[85], frag offset 0, frag length: 85, sequence: 0 |<3>| HSK[0x188ae60]: Server's version: 3.3 |<3>| HSK[0x188ae60]: SessionID length: 32 |<3>| HSK[0x188ae60]: SessionID: 150354b21172b769f53dec4f93d264944474e695425f5729ef1f57c4af958a41 |<3>| HSK[0x188ae60]: Selected cipher suite: ECDHE_ECDSA_AES_128_GCM_SHA256 |<3>| HSK[0x188ae60]: Selected compression method: NULL (0) |<3>| EXT[0x188ae60]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<3>| EXT[0x188ae60]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (4 bytes) |<3>| HSK[0x188ae60]: Safe renegotiation succeeded |<2>| ASSERT: gnutls_buffers.c:976 |<4>| REC[0x188ae60]: SSL 3.3 Handshake packet received. Epoch 0, length: 1192 |<4>| REC[0x188ae60]: Expected Packet Handshake(22) |<4>| REC[0x188ae60]: Received Packet Handshake(22) with length: 1192 |<4>| REC[0x188ae60]: Decrypted Packet[1] Handshake(22) with length: 1192 |<3>| HSK[0x188ae60]: CERTIFICATE was received. Length 1188[1188], frag offset 0, frag length: 1188, sequence: 0 |<2>| ASSERT: verify.c:410 |<2>| ASSERT: verify.c:674 - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - The hostname in the certificate matches 'smtp.crustytoothpaste.net'. *** Verifying server certificate failed... |<2>| ASSERT: gnutls_buffers.c:976 |<4>| REC[0x188ae60]: SSL 3.3 Handshake packet received. Epoch 0, length: 213 |<4>| REC[0x188ae60]: Expected Packet Handshake(22) |<4>| REC[0x188ae60]: Received Packet Handshake(22) with length: 213 |<4>| REC[0x188ae60]: Decrypted Packet[2] Handshake(22) with length: 213 |<3>| HSK[0x188ae60]: SERVER KEY EXCHANGE was received. Length 209[209], frag offset 0, frag length: 209, sequence: 0 |<3>| HSK[0x188ae60]: Selected ECC curve SECP384R1 (3) |<3>| HSK[0x188ae60]: verify handshake data: using ECDSA-SHA256 |<2>| ASSERT: gnutls_sig.c:365 |<2>| ASSERT: dhe.c:329 |<2>| ASSERT: gnutls_kx.c:494 |<2>| ASSERT: gnutls_handshake.c:2524 *** Fatal error: An algorithm that is not enabled was negotiated. - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - |<2>| ASSERT: dn.c:286 |<2>| ASSERT: dn.c:286 subject `C=US,ST=Texas,L=Houston,O=Crusty Toothpaste,OU=Certificate Authority,CN=castro.crustytoothpaste.net', issuer `C=US,ST=Texas,L=Houston,O=Crusty Toothpaste,OU=Certificate Authority,CN=Crusty Toothpaste Certificate Authority,EMAIL=ca at crustytoothpaste.net', EC key 384 bits, signed using RSA-SHA512, activated `2012-08-28 00:00:00 UTC', expires `2020-05-06 23:59:59 UTC', SHA-1 fingerprint `d2d1ac6d014c0861618488dd032e37e4192aabef' Public Key Id: a74f88402a90c7da20856073d9cfa1a6c71ad21d Public key's random art: +--[ EC 384]----+ |o+..o | |o+o. . . | |= o . + . | |o= o E o | |o + * . S . | | o + = . + | | . + . o . | | . o | | . | +-----------------+ |<4>| REC: Sending Alert[2|80] - Internal error |<4>| REC[0x188ae60]: Preparing Packet Alert(21) with length: 2 |<4>| REC[0x188ae60]: Sent Packet[2] Alert(21) in epoch 0 and length: 7 *** Handshake has failed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From nmav at gnutls.org Sat Sep 1 10:31:55 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 01 Sep 2012 10:31:55 +0200 Subject: gnutls claims a disabled algorithm was negotiated In-Reply-To: <20120831234252.GA1006360@crustytoothpaste.ath.cx> References: <20120831234252.GA1006360@crustytoothpaste.ath.cx> Message-ID: <5041C7FB.50202@gnutls.org> On 09/01/2012 01:42 AM, brian m. carlson wrote: > I've recently moved my mail server to running postfix, and as a result, > am now able to provide an EC key and certificate for TLS (the > certificate is signed by my local RSA CA). However, when I try to > connect to postfix either using gnutls-cli or mutt (linked against > 3.0.22), gnutls provides the following error: > > *** Fatal error: An algorithm that is not enabled was negotiated. > > This seems odd to me, since OpenSSL is very happy to make the > connection (as the client), and the algorithm that was negotiated is > ECDHE_ECDSA_AES_128_GCM_SHA256, which I'm pretty sure both GnuTLS and > OpenSSL support. It also is odd that the complaint doesn't happen until > GnuTLS tries to verify the signature; shouldn't it die sooner if the > server picks an algorithm that it doesn't support? Interesting case. > |<3>| HSK[0x188ae60]: Selected ECC curve SECP384R1 (3) > |<3>| HSK[0x188ae60]: verify handshake data: using ECDSA-SHA256 > |<2>| ASSERT: gnutls_sig.c:365 I suppose that your server's certificate has the SECP384R1 curve, is that right? In that case the server should have used the SHA-384 or SHA-512 hash algorithms (see http://tools.ietf.org/html/rfc5480#section-4 ). However your server used SHA-256 instead and that's why gnutls complains. Is that the case? regards, Nikos From nmav at gnutls.org Sat Sep 1 19:17:08 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 01 Sep 2012 19:17:08 +0200 Subject: gnutls claims a disabled algorithm was negotiated In-Reply-To: <20120831234252.GA1006360@crustytoothpaste.ath.cx> References: <20120831234252.GA1006360@crustytoothpaste.ath.cx> Message-ID: <50424314.3020402@gnutls.org> On 09/01/2012 01:42 AM, brian m. carlson wrote: > I've recently moved my mail server to running postfix, and as a result, > am now able to provide an EC key and certificate for TLS (the > certificate is signed by my local RSA CA). However, when I try to > connect to postfix either using gnutls-cli or mutt (linked against > 3.0.22), gnutls provides the following error: > > *** Fatal error: An algorithm that is not enabled was negotiated. > > This seems odd to me, since OpenSSL is very happy to make the > connection (as the client), and the algorithm that was negotiated is > ECDHE_ECDSA_AES_128_GCM_SHA256, which I'm pretty sure both GnuTLS and > OpenSSL support. It also is odd that the complaint doesn't happen until > GnuTLS tries to verify the signature; shouldn't it die sooner if the > server picks an algorithm that it doesn't support? I've pushed a patch to make gnutls more tolerant in ECDSA violations. Does this fix the issue for you? http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5bd518deaab699d46164f9e82744f482f3dabde7 regards, Nikos From sandals at crustytoothpaste.net Sat Sep 1 19:32:04 2012 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Sat, 1 Sep 2012 17:32:04 +0000 Subject: gnutls claims a disabled algorithm was negotiated In-Reply-To: <5041C7FB.50202@gnutls.org> References: <20120831234252.GA1006360@crustytoothpaste.ath.cx> <5041C7FB.50202@gnutls.org> Message-ID: <20120901173204.GB1006360@crustytoothpaste.ath.cx> On Sat, Sep 01, 2012 at 10:31:55AM +0200, Nikos Mavrogiannopoulos wrote: > Interesting case. > > |<3>| HSK[0x188ae60]: Selected ECC curve SECP384R1 (3) > > |<3>| HSK[0x188ae60]: verify handshake data: using ECDSA-SHA256 > > |<2>| ASSERT: gnutls_sig.c:365 > > I suppose that your server's certificate has the SECP384R1 curve, is > that right? In that case the server should have used the SHA-384 or > SHA-512 hash algorithms (see > http://tools.ietf.org/html/rfc5480#section-4 ). However your server used > SHA-256 instead and that's why gnutls complains. Yes, that is the case. I suppose this is a bug in OpenSSL? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From sandals at crustytoothpaste.net Sat Sep 1 19:53:32 2012 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Sat, 1 Sep 2012 17:53:32 +0000 Subject: gnutls claims a disabled algorithm was negotiated In-Reply-To: <50424314.3020402@gnutls.org> References: <20120831234252.GA1006360@crustytoothpaste.ath.cx> <50424314.3020402@gnutls.org> Message-ID: <20120901175332.GA15833@crustytoothpaste.ath.cx> On Sat, Sep 01, 2012 at 07:17:08PM +0200, Nikos Mavrogiannopoulos wrote: > I've pushed a patch to make gnutls more tolerant in ECDSA violations. > Does this fix the issue for you? > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=5bd518deaab699d46164f9e82744f482f3dabde7 Yes, that works very nicely. I am now able to send mail if EC is enabled. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From nmav at gnutls.org Sun Sep 2 01:54:40 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 02 Sep 2012 01:54:40 +0200 Subject: gnutls claims a disabled algorithm was negotiated In-Reply-To: <20120901173204.GB1006360@crustytoothpaste.ath.cx> References: <20120831234252.GA1006360@crustytoothpaste.ath.cx> <5041C7FB.50202@gnutls.org> <20120901173204.GB1006360@crustytoothpaste.ath.cx> Message-ID: <5042A040.3010400@gnutls.org> On 09/01/2012 07:32 PM, brian m. carlson wrote: > On Sat, Sep 01, 2012 at 10:31:55AM +0200, Nikos Mavrogiannopoulos wrote: >> Interesting case. >>> |<3>| HSK[0x188ae60]: Selected ECC curve SECP384R1 (3) >>> |<3>| HSK[0x188ae60]: verify handshake data: using ECDSA-SHA256 >>> |<2>| ASSERT: gnutls_sig.c:365 >> >> I suppose that your server's certificate has the SECP384R1 curve, is >> that right? In that case the server should have used the SHA-384 or >> SHA-512 hash algorithms (see >> http://tools.ietf.org/html/rfc5480#section-4 ). However your server used >> SHA-256 instead and that's why gnutls complains. > Yes, that is the case. I suppose this is a bug in OpenSSL? Unfortunately yes, and I'm afraid the issue may be bigger. IETF has failed to clarify details of ECDSA/DSA usage and this is one of the side-effects. That's why I think I'll deviate from the ECDSA protocol to support those buggy implementations. regards, Nikos From nmav at gnutls.org Sun Sep 2 20:37:38 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 02 Sep 2012 20:37:38 +0200 Subject: gnutls 3.0.23 Message-ID: <5043A772.5010502@gnutls.org> Hello, I've just released gnutls 3.0.23. This is a bug-fix release on the old stable branch. * Version 3.0.23 (released 2012-09-02) ** gnutls-serv: Listens on IPv6. Patch by Bernhard R. Link. ** libgnutls: Be tolerant in ECDSA signature violations (e.g. using SHA256 with a SECP384 curve instead of SHA-384), to interoperate with openssl. ** libgnutls: Fixed DSA and ECDSA signature generation in smart cards. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.23.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.23.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.23.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.23.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.23.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 gnutls.org> uid Nikos Mavrogiannopoulos 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 nmav at gnutls.org Sun Sep 2 20:51:34 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 02 Sep 2012 20:51:34 +0200 Subject: gnutls 3.1.1 Message-ID: <5043AAB6.5050004@gnutls.org> Hello, I've just released gnutls 3.1.1. This release includes optimizations the elliptic curve subsystem and fixes several bugs in current stable branch. * Version 3.1.1 (released 2012-09-02) ** gnutls-serv: Listens on IPv6. Patch by Bernhard R. Link. ** certtool: Changes in password handling of certtool. Ask password when required and only if the '--password' option is not given. If the '--password' option is given during key generation then assume the PKCS #8 file format, instead of ignoring the password. ** tpmtool: No longer asks for key password in registered keys. ** libgnutls: Elliptic curve code was optimized by Ilya Tumaykin. wmNAF is now used for point multiplication and other optimizations. (the major part of the work was done during Google Summer of Code). ** libgnutls: The default pull_timeout_function only uses select instead of a combination of select() and recv() to prevent issues when used in stream sockets in some systems. ** libgnutls: Be tolerant in ECDSA signature violations (e.g. using SHA256 with a SECP384 curve instead of SHA-384), to interoperate with openssl. ** libgnutls: Fixed DSA and ECDSA signature generation in smart cards. Thanks to Andreas Schwier from cardcontact.de for providing me with ECDSA capable smart cards. ** API and ABI modifications: gnutls_sign_algorithm_get: Added gnutls_sign_get_hash_algorithm: Added gnutls_sign_get_pk_algorithm: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.1.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.1.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.1.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.1.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.1.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 gnutls.org> uid Nikos Mavrogiannopoulos 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 simon at josefsson.org Wed Sep 5 10:23:02 2012 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Sep 2012 10:23:02 +0200 Subject: GNUTLS + MingGW help In-Reply-To: (Minh Nguyen Huu's message of "Tue, 28 Aug 2012 17:23:20 +0000") References: Message-ID: <87r4qgop3t.fsf@latte.josefsson.org> Minh Nguyen Huu writes: > Hi, > > > I'm trying to compilre the gnutls library using MinGW on Windows 7 > (64bit). After some struggling, I've managed to compile Nettle (+GMP), > however I cannot make GNUTLS. When I run ./configure in the GNUTLS > everything seems ok, but when I try to make the library I keep getting > the same error, which I have pasted below. Does anyone have experience > making gnutls on Windows and can help me out? Do you really have a shared library DLL for GMP? The messages below suggests you only have a static library. Also, sometimes it helps to do 'lt_cv_deplibs_check_method=pass_all ./configure ...' /Simon > Thanks in advance, > > Minh > > > > *** Warning: This system can not link to static lib archive D:/MinGW/lib/libgmp. > la. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > Creating library file: .libs/libgnutls.dll.a > nettle/.libs/libcrypto.a(mpi.o): In function `wrap_nettle_mpi_new': > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/mpi.c:97: undefined referen > ce to `___gmpz_init2' > nettle/.libs/libcrypto.a(mpi.o): In function `wrap_nettle_mpi_div': > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/mpi.c:342: undefined refere > nce to `___gmpz_cdiv_q' > nettle/.libs/libcrypto.a(ecc_make_key.o): In function `ecc_make_key': > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_make_key.c:142: undefin > ed reference to `___gmpz_set_str' > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_make_key.c:143: undefin > ed reference to `___gmpz_set_str' > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_make_key.c:144: undefin > ed reference to `___gmpz_set_str' > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_make_key.c:145: undefin > ed reference to `___gmpz_set_str' > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_make_key.c:146: undefin > ed reference to `___gmpz_set_str' > nettle/.libs/libcrypto.a(ecc_make_key.o):D:\MinGW\msys\1.0\home\Minh\gnutls-3.0. > 22\lib\nettle/ecc_make_key.c:147: more undefined references to `___gmpz_set_str' > follow > nettle/.libs/libcrypto.a(ecc_projective_dbl_point_3.o): In function `ecc_project > ive_dbl_point': > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_projective_dbl_point_3. > c:113: undefined reference to `___gmpz_divexact_ui' > nettle/.libs/libcrypto.a(ecc_projective_add_point.o): In function `ecc_projectiv > e_add_point': > D:\MinGW\msys\1.0\home\Minh\gnutls-3.0.22\lib\nettle/ecc_projective_add_point.c: > 214: undefined reference to `___gmpz_divexact_ui' > collect2.exe: error: ld returned 1 exit status > make[3]: *** [libgnutls.la] Error 1 > make[3]: Leaving directory `/home/Minh/gnutls-3.0.22/lib' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/Minh/gnutls-3.0.22/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/Minh/gnutls-3.0.22' > make: *** [all] Error 2 > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls From barsandcat at gmail.com Sun Sep 9 11:34:37 2012 From: barsandcat at gmail.com (Dmythro Tsakhilov) Date: Sun, 9 Sep 2012 12:34:37 +0300 Subject: SRP and null cipher Message-ID: To run unit tests on my network code, which uses gnutls with SRP key exchange, I want to substitute socket with beforehand prepared data stream. As I understand, same packet after encryption result in different output each time, so if stored data send from server, and try to feed them back to client during another session - it will not work. That could be solved if I could, some how, disable encryption for unit tests. I've read about NULL cipher, but could not find any documentation about how to switch it on with SRP extension. May be there is gnutls-serv and gnutls-cli example? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Sep 11 09:54:29 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 11 Sep 2012 09:54:29 +0200 Subject: SRP and null cipher In-Reply-To: References: Message-ID: On Sun, Sep 9, 2012 at 11:34 AM, Dmythro Tsakhilov wrote: > To run unit tests on my network code, which uses gnutls with SRP key > exchange, I want to substitute socket with beforehand prepared data stream. > As I understand, same packet after encryption result in different output > each time, so if stored data send from server, and try to feed them back to > client during another session - it will not work. > That could be solved if I could, some how, disable encryption for unit > tests. I've read about NULL cipher, but could not find any documentation > about how to switch it on with SRP extension. SRP does not define any ciphersuites with the NULL cipher, but what you mention wouldn't work in any case because the key of the MAC would also vary. What you could do is to verify against some independent implementation of TLS-SRP. regards, Nikos From nmav at gnutls.org Thu Sep 13 13:14:38 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Sep 2012 13:14:38 +0200 Subject: the "crime" attack on TLS Message-ID: Hello, If you're not already aware there is a new attack on TLS called "crime". I was asked by the author of this attack not to disclose any information, but it seems it is public already [0] so I can comment on it. That attack takes advantage of compression and by forcing an HTTPS client to use carefully formatted data it may be able to guess the contents of other non-controlled by the attacker data, based on the compressed size. Because there is no formal description of the attack, nor a precise use-case where the attack is considered dangerous, and due to that there may be overreactions. The attack works when you have compression enabled and data from an adversary can be mixed with sensitive data (e.g. a URL that is provided by an adversary is mixed with secret cookie data in an HTTPS request). Moreover the adversary must be able to invoke multiple trials (e.g. force a user to visit specially crafted URLs again and again - perhaps by using javascript). So currently the threat is mostly on the HTTPS protocol and especially browsers. To sum up. * Who does this attack affect: 1. clients or servers that use compression and provide the ability to an adversary to inject data (multiple times) in their session. * How to mitigate the attack? 1. Do not enable compression (gnutls' doesn't enable it by default) 2. When using compression use the CBC ciphers that include a random padding up to 255 bytes. That would increase the number of trials an attacker needs to perform significantly. 3. Make sure that even if you must mix adversary-controlled data with sensitive data, that the adversary cannot trigger that multiple times. I'll add a recommendation on the web site later today. regards, Nikos [0]. http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/ From alfredo.pironti at inria.fr Thu Sep 13 14:52:46 2012 From: alfredo.pironti at inria.fr (Alfredo Pironti) Date: Thu, 13 Sep 2012 14:52:46 +0200 Subject: the "crime" attack on TLS In-Reply-To: References: Message-ID: Hello, Indeed, compression-based attacks on TLS have been known for a while [1], but it is interesting that this can be exploited at the browser-end. Best, Alfredo [1] https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/barghavan.pdf On Thu, Sep 13, 2012 at 1:14 PM, Nikos Mavrogiannopoulos wrote: > Hello, > If you're not already aware there is a new attack on TLS called > "crime". I was asked by the author of this attack not to disclose any > information, but it seems it is public already [0] so I can comment on > it. That attack takes advantage of compression and by forcing an HTTPS > client to use carefully formatted data it may be able to guess the > contents of other non-controlled by the attacker data, based on the > compressed size. Because there is no formal description of the attack, > nor a precise use-case where the attack is considered dangerous, and > due to that there may be overreactions. The attack works when you have > compression enabled and data from an adversary can be mixed with > sensitive data (e.g. a URL that is provided by an adversary is mixed > with secret cookie data in an HTTPS request). Moreover the adversary > must be able to invoke multiple trials (e.g. force a user to visit > specially crafted URLs again and again - perhaps by using javascript). > > So currently the threat is mostly on the HTTPS protocol and especially > browsers. To sum up. > > * Who does this attack affect: > 1. clients or servers that use compression and provide the ability to > an adversary to inject data (multiple times) in their session. > > * How to mitigate the attack? > 1. Do not enable compression (gnutls' doesn't enable it by default) > 2. When using compression use the CBC ciphers that include a random > padding up to 255 bytes. That would increase the number of trials an > attacker needs to perform significantly. > 3. Make sure that even if you must mix adversary-controlled data with > sensitive data, that the adversary cannot trigger that multiple times. > > I'll add a recommendation on the web site later today. > > regards, > Nikos > > [0]. http://arstechnica.com/security/2012/09/crime-hijacks-https-sessions/ > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > https://lists.gnu.org/mailman/listinfo/help-gnutls From help-gnutls-phil at spodhuis.org Fri Sep 14 06:03:08 2012 From: help-gnutls-phil at spodhuis.org (Phil Pennock) Date: Fri, 14 Sep 2012 00:03:08 -0400 Subject: the "crime" attack on TLS Message-ID: <20120914040307.GA38063@redoubt.spodhuis.org> [ Sorry to Nikos who sees this twice; my first reply was rejected by the list, so new message-id. ] On 2012-09-13 at 13:14 +0200, Nikos Mavrogiannopoulos wrote: > * How to mitigate the attack? > 1. Do not enable compression (gnutls' doesn't enable it by default) > 2. When using compression use the CBC ciphers that include a random > padding up to 255 bytes. That would increase the number of trials an > attacker needs to perform significantly. > 3. Make sure that even if you must mix adversary-controlled data with > sensitive data, that the adversary cannot trigger that multiple times. One thing I noted is that the attack relies upon compression working, while DEFLATE uses a new Huffman tree for each compression block. So if you end a _compression_ block any time you switch sensitivity level within the stream, you protect different parts of the cleartext from each other and this attack shouldn't work. Both GnuTLS and OpenSSL use Z_SYNC_FLUSH to get a complete set of data for sending, while still being in a compression block. Z_FULL_FLUSH is needed to end a compression block, or to end the compression with Z_FINISH. OpenSSL has BIO_flush() which will end up using Z_FINISH to end a compression block, with the side-effect of also flushing down to the wire level which would be unfortunate performance wise. I couldn't find anything similar in GnuTLS and was wondering if a new control call to end a compression block, starting a new one, would be useful for senders who want to be able to use compression but split contexts at security boundaries within the stream? I wrote up my preliminary views at: http://bridge.grumpy-troll.org/2012/09/tls-crime-beast-and-you-programmer.html -Phil From nmav at gnutls.org Fri Sep 14 11:41:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Sep 2012 11:41:17 +0200 Subject: the "crime" attack on TLS In-Reply-To: <20120914040307.GA38063@redoubt.spodhuis.org> References: <20120914040307.GA38063@redoubt.spodhuis.org> Message-ID: On Fri, Sep 14, 2012 at 6:03 AM, Phil Pennock wrote: > One thing I noted is that the attack relies upon compression working, > while DEFLATE uses a new Huffman tree for each compression block. So if > you end a _compression_ block any time you switch sensitivity level > within the stream, you protect different parts of the cleartext from > each other and this attack shouldn't work. The issue is that you cannot easily determine when the sensitivity level changes. E.g. if TLS is used for a VPN, how are one user's data distinguished from another's? Is it enough to assume that data of different sensitivity are included in different records? > Both GnuTLS and OpenSSL use Z_SYNC_FLUSH to get a complete set of data > for sending, while still being in a compression block. Z_FULL_FLUSH is > needed to end a compression block, > or to end the compression with Z_FINISH. > OpenSSL has BIO_flush() which will end up using Z_FINISH to end a > compression block, with the side-effect of also flushing down to the > wire level which would be unfortunate performance wise. > I couldn't find anything similar in GnuTLS and was wondering if a new > control call to end a compression block, starting a new one, would be > useful for senders who want to be able to use compression but split > contexts at security boundaries within the stream? GnuTLS operates much differently than openssl. It's operation is comparable to unix sockets. You provide data for sending in each record. That data is then compressed. I'm thinking whether it makes sense to use Z_FULL_FLUSH on each record boundary, or drop compression altogether. regards, Nikos From help-gnutls-phil at spodhuis.org Sat Sep 15 02:30:30 2012 From: help-gnutls-phil at spodhuis.org (Phil Pennock) Date: Fri, 14 Sep 2012 20:30:30 -0400 Subject: the "crime" attack on TLS In-Reply-To: References: <20120914040307.GA38063@redoubt.spodhuis.org> Message-ID: <20120915003030.GA50788@redoubt.spodhuis.org> On 2012-09-14 at 11:41 +0200, Nikos Mavrogiannopoulos wrote: > On Fri, Sep 14, 2012 at 6:03 AM, Phil Pennock > wrote: > > One thing I noted is that the attack relies upon compression working, > > while DEFLATE uses a new Huffman tree for each compression block. So if > > you end a _compression_ block any time you switch sensitivity level > > within the stream, you protect different parts of the cleartext from > > each other and this attack shouldn't work. > > The issue is that you cannot easily determine when the sensitivity > level changes. E.g. if TLS is used for a VPN, how are one user's data > distinguished from another's? Is it enough to assume that data of > different sensitivity are included in different records? TLS has always been a "mostly works, kindof" solution for a VPN. Mind, for a link to a network, I think IPsec uses one stream for all flows, if memory serves, so would have the same problem, if it used compression. I've assumed that link-layer TCP-based VPN stuff doesn't use stream compression because of the latency hit, but uses PPP header compression. I've not actually investigated to find out. Ultimately, unless every application is labelling every byte with sensitivity levels on the way out, this doesn't seem soluble without doing something like setting up 32 associations as substrate bearers and non-deterministically multiplexing across them, bearer-hopping. And even that is just making it harder, not fixing it. > GnuTLS operates much differently than openssl. Similarly enough that we maintain bindings to both in Exim. :) But yes, OpenSSL has the BIO abstraction, GnuTLS just provides gnutls_record_send() and friends. I know what you mean here, but where in OpenSSL you can use BIO_flush(), in GnuTLS, you could have a similar flush call; or a call which sets a flag in gnutls_session_t which will be cleared with the next send, to coerce the change: on next send, Z_FINISH the current compression block and start a new one. It's that, or add gnutls_record_send_flagged() which takes a 4th parameter. > It's operation is > comparable to unix sockets. You provide data for sending in each > record. That data is then compressed. I'm thinking whether it makes > sense to use Z_FULL_FLUSH on each record boundary, or drop compression > altogether. Given the size of a record, a full flush on every send would probably work out larger than no compression for most workloads, surely? You still need to send the Huffman tree as overhead. And unfortunately, where OpenSSH could just defer compression start until post-authentication by adding a different protocol feature, we don't get that without a re-handshake in TLS. Which might be one approach: applications which know they have a security boundary change they want to protect against need to do a TLS re-handshake. Expensive, but within protocol now, and they could disable compression for the initial H/S and enable it for the second, to avoid the short-lived initial compression block wasting overhead. Without the disable/enable-later compression, this can be done by clients right now with gnutls_rehandshake(), right? So there's an immediate fix _possible_ for those who want to keep using compression? Also, please bear in mind that many uses of TLS do not exchange authentication information inside the stream; for instance, the majority of SMTP/TLS sessions today. Now, admittedly they're not doing verification either so have bigger problems, but there's a draft out to solve that problem and if I have time, I will be adding support for it to Exim before the next release. Emails tend to compress very well, so if you can find a way to keep compression around, that would be appreciated. Making it default off and need explicit enabling might be a reasonable approach, since I suspect that the majority of small programs doing crypto with TLS will be using HTTP over it. -Phil From nmav at gnutls.org Sat Sep 15 12:11:16 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 15 Sep 2012 12:11:16 +0200 Subject: the "crime" attack on TLS In-Reply-To: <20120915003030.GA50788@redoubt.spodhuis.org> References: <20120914040307.GA38063@redoubt.spodhuis.org> <20120915003030.GA50788@redoubt.spodhuis.org> Message-ID: <50545444.7050800@gnutls.org> On 09/15/2012 02:30 AM, Phil Pennock wrote: > But yes, OpenSSL has the BIO abstraction, GnuTLS just provides > gnutls_record_send() and friends. I know what you mean here, but where > in OpenSSL you can use BIO_flush(), in GnuTLS, you could have a similar > flush call; or a call which sets a flag in gnutls_session_t which will > be cleared with the next send, to coerce the change: on next send, > Z_FINISH the current compression block and start a new one. It's that, > or add gnutls_record_send_flagged() which takes a 4th parameter. Is any advantage in having such a fine-tuning? I think a simpler approach of allowing either stateless compression with FULL_FLUSH, and another option that allows SYNC_FLUSH would be sufficient for most uses. >> It's operation is >> comparable to unix sockets. You provide data for sending in each >> record. That data is then compressed. I'm thinking whether it makes >> sense to use Z_FULL_FLUSH on each record boundary, or drop compression >> altogether. > > Given the size of a record, a full flush on every send would probably > work out larger than no compression for most workloads, surely? You > still need to send the Huffman tree as overhead. A preliminary test with the Z_FULL_FLUSH option doesn't show a much larger overhead (packets are typically few bytes larger). regards, Nikos From joke at seiken.de Tue Sep 18 11:34:18 2012 From: joke at seiken.de (Joke de Buhr) Date: Tue, 18 Sep 2012 11:34:18 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() Message-ID: <1623677.UjvJFP0Yb5@oberon> hi, i'm using GnuTLS version 3.1.1. there seems to be a problem within gnutls_certificate_set_openpgp_key(). gnutls_certificate_set_openpgp_key() uses gnutls_privkey_import_openpgp() (flag GNUTLS_PRIVKEY_IMPORT_COPY) to obtain a copy of the passed private key. copying is done calling _gnutls_openpgp_privkey_cpy() with in turn calls gnutls_openpgp_privkey_export() and gnutls_openpgp_privkey_import(). during this copying procedure the key somehow gets messed up and gnutls_openpgp_privkey_import() returns GNUTLS_E_INTERNAL_ERROR. importing the private key with gnutls_openpgp_privkey_import() in the first place to pass the parameter to gnutls_certificate_set_openpgp_key() worked without problem. the pgp-key contains a master-key with flags SCE and a single subkey with flags SEA. using a pgp-key with just a master-key seems to work by the way. if needed i'm can provide a test program and the gpg-key. regards Joke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From joke at seiken.de Tue Sep 18 17:23:32 2012 From: joke at seiken.de (Joke de Buhr) Date: Tue, 18 Sep 2012 17:23:32 +0200 Subject: segfault: setteing openpgp credentials via abstract functions Message-ID: <1429529.cnEMMXOZXP@oberon> hi, i have discovered an problem regarding the openpgp functions. if i try to set openpgp credentials by using the abstract functions gnutls segfaults. gnutls_pcert_st pcert; gnutls_privkey_t pkey; gnutls_privkey_init(&pkey); r = gnutls_pcert_import_openpgp_raw(&pcert, &pub_data, GNUTLS_OPENPGP_FMT_RAW, keyid, 0); r = gnutls_privkey_import_openpgp_raw(pkey, &priv_data, GNUTLS_OPENPGP_FMT_RAW, keyid, nullptr); r = gnutls_certificate_set_key(cre, nullptr, 1, &pcert, 1, pkey); the last function will cause a segfault in cdk_kbnode_walk(). the keyid is specified correctly. the import functions return success. then pgp-key contains a master key and one single subkey. #0 cdk_kbnode_walk() at lib/opencdk/kbnode.c:268 #1 _gnutls_openpgp_find_subkey_idx() at lib/openpgp/pgp.c:763 #2 gnutls_openpgp_privkey_get_subkey_idx() at lib/openpgp/privkey.c:583 #3 gnutls_openpgp_privkey_get_pk_algorithm() at lib/openpgp/privkey.c:269 #4 gnutls_openpgp_privkey_get_pk_algorithm() at lib/openpgp/privkey.c:251 #5 gnutls_privkey_get_pk_algorithm() at lib/gnutls_privkey.c:74 #6 _gnutls_check_key_cert_match() at lib/gnutls_cert.c:831 #7 gnutls_certificate_set_key() at lib/gnutls_x509.c:1102 regards Joke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From joke at seiken.de Tue Sep 18 19:32:45 2012 From: joke at seiken.de (Joke de Buhr) Date: Tue, 18 Sep 2012 19:32:45 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <1623677.UjvJFP0Yb5@oberon> References: <1623677.UjvJFP0Yb5@oberon> Message-ID: <1410140.STqMop1X9x@oberon> well, it seems this error has something to do with the flags of the authentication subkey. if the subkey is marked for authentication and signing gnutls_certificate_set_openpgp_key() will report an internal error. if the subkey is not marked for signing the function reports success. the encryption flags doesn't seem to matter. regards joke On Tuesday 18 September 2012 11:34:18 you wrote: > hi, > > i'm using GnuTLS version 3.1.1. > > there seems to be a problem within gnutls_certificate_set_openpgp_key(). > > gnutls_certificate_set_openpgp_key() uses gnutls_privkey_import_openpgp() > (flag GNUTLS_PRIVKEY_IMPORT_COPY) to obtain a copy of the passed private > key. copying is done calling _gnutls_openpgp_privkey_cpy() with in turn > calls gnutls_openpgp_privkey_export() and gnutls_openpgp_privkey_import(). > > during this copying procedure the key somehow gets messed up and > gnutls_openpgp_privkey_import() returns GNUTLS_E_INTERNAL_ERROR. > > importing the private key with gnutls_openpgp_privkey_import() in the first > place to pass the parameter to gnutls_certificate_set_openpgp_key() worked > without problem. the pgp-key contains a master-key with flags SCE and a > single subkey with flags SEA. using a pgp-key with just a master-key seems > to work by the way. > > if needed i'm can provide a test program and the gpg-key. > > > regards > Joke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From bert at bhack.net Thu Sep 20 02:01:49 2012 From: bert at bhack.net (Bert Van de Poel) Date: Thu, 20 Sep 2012 02:01:49 +0200 Subject: Peer's certificate issuer is unknown while certificates have been added Message-ID: <505A5CED.4000206@bhack.net> Dear mailinglist, I am not sure whether this is a silly question but I have been unable to solve it or find a decent answer online. We, a group of students supplying services to student's assemblies for the local university, are trying to connect to the university's ldap server which uses ssl. We have correct ldap details but gnuTLS considers the connection to be insecure. (I check it could only be tls by allowing insecure ldap transactions for a second). I went on to test things using gnutls-cli: Resolving 'ldap.kuleuven.be'... Connecting to '134.58.127.92:636'... - Certificate type: X.509 - Got a certificate list of 4 certificates. - Certificate[0] info: - subject `C=BE,L=Leuven,O=Katholieke Universiteit Leuven,OU=Competentiecentrum Informatiebeveiliging,CN=ldap.kuleuven.be', issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2012-01-25 00:00:00 UTC', expires `2015-01-24 23:59:59 UTC', SHA-1 fingerprint `9dc847d52b4e478b314dccbbf0382645822062db' - Certificate[1] info: - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-05-18 00:00:00 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d' - Certificate[2] info: - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA1, activated `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e' - Certificate[3] info: - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 2048 bits, signed using RSA-SHA1, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `02faf3e291435468607857694df5e45b68851868' - The hostname in the certificate matches 'ldap.kuleuven.be'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-256-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: Based on this I contacted the IT department and they send me 3 of the 4 mentioned certificates which they told me I should add to our pool. I did this and also added the fourth one which was missing. The certificates were exact to the ones presented when asking for more debugging information from gnutls-cli. The procedure I followed to add the certificates was: I created a directory /usr/share/ca-certificates/ldap.kuleuven.be and added all certificates in seperate files and in one file combined as well. Next I edited /etc/ca-certificates.conf to add all of those files and ran update-ca-certificates. All certificates turned up nicely in /etc/ssl/certs/ I verified that all permission were correct. Our webserver which is doing these connections uses Ubuntu 12.04 Server which uses gnutls 3.0.11 if that is of any use to you. Now I think I've added these certificates correctly and they should be recognised. Am I perhaps adding the wrong files and do I not need certificates but the big CAchains? Am I doing something else wrong? Some help would be of great use to us, especially with the start of the academic year around the corner. If any more information is required please do respond, I will supply any information promptly. Thanks in advance. Kind Regards, Bert Van de Poel. ULYSSIS From dkg at fifthhorseman.net Thu Sep 20 23:55:41 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Sep 2012 17:55:41 -0400 Subject: Peer's certificate issuer is unknown while certificates have been added In-Reply-To: <505A5CED.4000206@bhack.net> References: <505A5CED.4000206@bhack.net> Message-ID: <505B90DD.30405@fifthhorseman.net> Hi Bert-- short version: I suspect you didn't need to do any copying of those files at all; you only need to add the following arguments to your gnutls-cli invocation (should be all on one line): --x509cafile /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt longer version below, since there are a couple things that seem amiss here: On 09/19/2012 08:01 PM, Bert Van de Poel wrote: > We have correct ldap details but gnuTLS considers the connection to be > insecure. (I check it could only be tls by allowing insecure ldap > transactions for a second). > > I went on to test things using gnutls-cli: > Resolving 'ldap.kuleuven.be'... You don't show the exact command line you used above,. It would be helpful to see exactly what you called in order to know what this comes from. For example, when i try connecting to the EFF with gnutls-cli 3.0.22, the first thing i see is: 0 dkg at pip:~$ gnutls-cli www.eff.org Processed 94 CA certificate(s). Resolving 'www.eff.org'... Connecting to '2607:f258:102:2::2:443'... [...] the first line shows me that gnutls-cli has loaded a list of 94 trusted root certificate authorities by default. I think earlier versions of gnutls-cli don't load any root CAs by default, (maybe it was added in 3.0.20 the addition of withgnutls_certificate_set_x509_system_trust?) so you'd have to specify your trusted root CAs explicitly with the --x509cafile option, as described above. carrying on... > Connecting to '134.58.127.92:636'... > - Certificate type: X.509 this server doesn't appear to accept connections from arbitrary public IP addresses (i et "connection timed out") so i assume it's limited to the campus or something. In the discussions below, note that an X.509 certificate has a subject ("who the cert belongs to") and an issuer ("who is doing the certifying") > - Got a certificate list of 4 certificates. > - Certificate[0] info: > - subject `C=BE,L=Leuven,O=Katholieke Universiteit > Leuven,OU=Competentiecentrum Informatiebeveiliging,CN=ldap.kuleuven.be', > issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using > RSA-SHA1, activated `2012-01-25 00:00:00 UTC', expires `2015-01-24 > 23:59:59 UTC', SHA-1 fingerprint `9dc847d52b4e478b314dccbbf0382645822062db' the above (Certificate[0]) is called the "end entity" (EE) certificate, meaning that it is the certificate that belongs to the endpoint itself (your LDAP server). > - Certificate[1] info: > - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt > Lake City,O=The USERTRUST > Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key > 2048 bits, signed using RSA-SHA1, activated `2009-05-18 00:00:00 UTC', > expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint > `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d' Certificate[1] here belongs to an "intermediate certificate authority "(the "TERENA SSL CA"). they issued your LDAP server's EE certificate. In turn, their certificate is issued by: > - Certificate[2] info: > - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST > Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer > `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust > External CA Root', RSA key 2048 bits, signed using RSA-SHA1, activated > `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 > fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e' Certificate[2] belongs to another intermediate CA, and ... > - Certificate[3] info: > - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP > Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust > AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA > key 2048 bits, signed using RSA-SHA1, activated `2000-05-30 10:48:38 > UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint > `02faf3e291435468607857694df5e45b68851868' Based on the sha-1 fingerprint, Certificate[3] here matches the file on my debian system: /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt This is not an intermediate CA, but a "root CA" -- that is, the issuer is the same as the subject. this certificate is widely distributed in several public certificate-verifying tools, like the mozilla firefox web browser. According to the TLS spec, this last certificate does not need to be sent at all, "Under the assumption that the remote end must already possess it in order to validate it in any case." https://tools.ietf.org/html/rfc5246#page-48 If the admins of this LDAP server want to decrease the size of their TLS handshakes, they could remove that certificate from the list they offer on each handshake. > - The hostname in the certificate matches 'ldap.kuleuven.be'. > - Peer's certificate issuer is unknown > - Peer's certificate is NOT trusted So this is why gnutls-cli can't verify it. if gnutls-cli doesn't have *any* trusted root certificate authorities, the ultimate issuer of a cert is always going to be unknown. > The procedure I followed to add the certificates was: I created a > directory /usr/share/ca-certificates/ldap.kuleuven.be and added all > certificates in seperate files and in one file combined as well. Next I > edited /etc/ca-certificates.conf to add all of those files and ran > update-ca-certificates. All certificates turned up nicely in > /etc/ssl/certs/ I don't think you actually want to add the certificates of these intermediate CAs to your list of trusted root stores in the first place -- you just need to give gnutls-cli some indication of where it should look for its trusted CAs. In particular, by adding the intermediate CAs to your trusted root list, you're granting them longstanding independent ability to forge certificates for remote parties, even if the root on which they depend has been revoked or deprecated. And you certainly don't want to place any EE certificates in your list of trusted root authorities, since they should not be certifying anything anyway. That said, if you *do* want to add trusted root CAs to a debian-derived system that aren't already shipped in the ca-certificates package, you probably don't want to tamper with the contents of /usr/share/ca-certificates directly. That part of the filesystem is controlled by the ca-certificates package. Instead, for any CA that you want to add to a system as the admin, you only need to drop a world-readable PEM-encoded file containing the CA's certificate into /usr/share/ca-certificates/, and then re-run "update-ca-certificates" as the superuser. This will create links properly under /etc/ssl/certs, and will include them in /etc/ssl/ca-certificates.crt. This last file is what is used as the default x.509 ca authority list on recent versions of gnutls-cli on debian, and could be specified as --x509cafile if you want to mimic that behavior when running an earlier version. > I verified that all permission were correct. Our webserver which is > doing these connections uses Ubuntu 12.04 Server which uses gnutls > 3.0.11 if that is of any use to you. Thanks! This bit of critical information should always be up front in any problem report so that folks trying to solve it know what they're dealing with! Please let me know if you have any extra questions. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From joke at seiken.de Fri Sep 21 11:37:19 2012 From: joke at seiken.de (Joke de Buhr) Date: Fri, 21 Sep 2012 11:37:19 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <1410140.STqMop1X9x@oberon> References: <1623677.UjvJFP0Yb5@oberon> <1410140.STqMop1X9x@oberon> Message-ID: <1547701.3TFnZd7ukx@oberon> hi, i discovered the internal error seems to be related to the openpgp key size. if the key contains just a single signing subkey with 2048 or more bits gnutls reports the internal error. a signing subkey with 1024 bits will however. moreover the key can contain encryption subkeys up to 4096 bits without problem as long as the encryption subkey isn't marked for signing. the authentication flags doesn't seem to have any effect at all. the problem seems to be related to the key exchange algorithm. the signature flag enables DHE_RSA and ECDHE_RSA whereas the encryption flag enable RSA key exchange. any comments on how to avoid this problem? regards joke On Tuesday 18 September 2012 19:32:45 you wrote: > well, it seems this error has something to do with the flags of the > authentication subkey. > > if the subkey is marked for authentication and signing > gnutls_certificate_set_openpgp_key() will report an internal error. if the > subkey is not marked for signing the function reports success. the > encryption flags doesn't seem to matter. > > > regards > joke > > On Tuesday 18 September 2012 11:34:18 you wrote: > > hi, > > > > i'm using GnuTLS version 3.1.1. > > > > there seems to be a problem within gnutls_certificate_set_openpgp_key(). > > > > gnutls_certificate_set_openpgp_key() uses gnutls_privkey_import_openpgp() > > (flag GNUTLS_PRIVKEY_IMPORT_COPY) to obtain a copy of the passed private > > key. copying is done calling _gnutls_openpgp_privkey_cpy() with in turn > > calls gnutls_openpgp_privkey_export() and gnutls_openpgp_privkey_import(). > > > > during this copying procedure the key somehow gets messed up and > > gnutls_openpgp_privkey_import() returns GNUTLS_E_INTERNAL_ERROR. > > > > importing the private key with gnutls_openpgp_privkey_import() in the > > first > > place to pass the parameter to gnutls_certificate_set_openpgp_key() worked > > without problem. the pgp-key contains a master-key with flags SCE and a > > single subkey with flags SEA. using a pgp-key with just a master-key seems > > to work by the way. > > > > if needed i'm can provide a test program and the gpg-key. > > > > > > regards > > Joke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From dkg at fifthhorseman.net Fri Sep 21 17:14:29 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Sep 2012 11:14:29 -0400 Subject: Peer's certificate issuer is unknown while certificates have been added In-Reply-To: <505B90DD.30405@fifthhorseman.net> References: <505A5CED.4000206@bhack.net> <505B90DD.30405@fifthhorseman.net> Message-ID: <505C8455.3050702@fifthhorseman.net> On 09/20/2012 05:55 PM, Daniel Kahn Gillmor wrote: > That said, if you *do* want to add trusted root CAs to a debian-derived > system that aren't already shipped in the ca-certificates package, you > probably don't want to tamper with the contents of > /usr/share/ca-certificates directly. That part of the filesystem is > controlled by the ca-certificates package. > > Instead, for any CA that you want to add to a system as the admin, you > only need to drop a world-readable PEM-encoded file containing the CA's > certificate into /usr/share/ca-certificates/, and then re-run > "update-ca-certificates" as the superuser. This will create links > properly under /etc/ssl/certs, and will include them in > /etc/ssl/ca-certificates.crt. > gah -- the above is wrong in a very confusing way, apologies! /usr/share/ca-certificates is controlled by the ca-certificates package. But the local system administrator has free reign over: /usr/local/share/ca-certificates note the "/local/", which i sloppily left out of my original next. files in the latter directory are automatically added to the system default list of trusted root authorities whenever update-ca-certificates is run. sorry for adding to the confusion, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Fri Sep 21 18:12:24 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Sep 2012 18:12:24 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <1547701.3TFnZd7ukx@oberon> References: <1623677.UjvJFP0Yb5@oberon> <1410140.STqMop1X9x@oberon> <1547701.3TFnZd7ukx@oberon> Message-ID: <505C91E8.4050802@gnutls.org> On 09/21/2012 11:37 AM, Joke de Buhr wrote: > hi, > > i discovered the internal error seems to be related to the openpgp key size. > if the key contains just a single signing subkey with 2048 or more bits gnutls > reports the internal error. a signing subkey with 1024 bits will however. > > moreover the key can contain encryption subkeys up to 4096 bits without > problem as long as the encryption subkey isn't marked for signing. the > authentication flags doesn't seem to have any effect at all. > > the problem seems to be related to the key exchange algorithm. the signature > flag enables DHE_RSA and ECDHE_RSA whereas the encryption flag enable RSA key > exchange. > any comments on how to avoid this problem? Sorry for the late reply. What you say about the sizes could be because of a static buffer used in gnutls. Could you enable debugging to figure out which place rejects the long keys? About the signing flags, you need them in order to use DHE-RSA and ECDHE-RSA. Those two require RSA signatures. The RSA algorithm requires an RSA encryption key. Does this explain what you notice? regards, Nikos From bert at bhack.net Fri Sep 21 14:13:30 2012 From: bert at bhack.net (Bert Van de Poel) Date: Fri, 21 Sep 2012 14:13:30 +0200 Subject: Peer's certificate issuer is unknown while certificates have been added In-Reply-To: <505B90DD.30405@fifthhorseman.net> References: <505A5CED.4000206@bhack.net> <505B90DD.30405@fifthhorseman.net> Message-ID: <505C59EA.1080608@bhack.net> Thank you DKG, I already thought adding all those certificates was a bit strange. Indeed adding the --x509cafile did the trick. Afterwards we just added the TLS_CACERT information to ldap.conf and everything worked like a charm. We have removed all incorrect information from the system again as we take security rather serious. Your suggestions really saved our project. ULYSSIS is thankful beyond description. Thanks again, Bert. ULYSSIS Op 20-09-12 23:55, Daniel Kahn Gillmor schreef: > Hi Bert-- > > short version: > > I suspect you didn't need to do any copying of those files at all; you > only need to add the following arguments to your gnutls-cli invocation > (should be all on one line): > > --x509cafile /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt > > longer version below, since there are a couple things that seem amiss here: > > On 09/19/2012 08:01 PM, Bert Van de Poel wrote: >> We have correct ldap details but gnuTLS considers the connection to be >> insecure. (I check it could only be tls by allowing insecure ldap >> transactions for a second). >> >> I went on to test things using gnutls-cli: >> Resolving 'ldap.kuleuven.be'... > You don't show the exact command line you used above,. It would be > helpful to see exactly what you called in order to know what this comes > from. > > For example, when i try connecting to the EFF with gnutls-cli 3.0.22, > the first thing i see is: > > 0 dkg at pip:~$ gnutls-cli www.eff.org > Processed 94 CA certificate(s). > Resolving 'www.eff.org'... > Connecting to '2607:f258:102:2::2:443'... > [...] > > the first line shows me that gnutls-cli has loaded a list of 94 trusted > root certificate authorities by default. > > I think earlier versions of gnutls-cli don't load any root CAs by > default, (maybe it was added in 3.0.20 the addition of > withgnutls_certificate_set_x509_system_trust?) so you'd have to specify > your trusted root CAs explicitly with the --x509cafile option, as > described above. > > carrying on... > >> Connecting to '134.58.127.92:636'... >> - Certificate type: X.509 > this server doesn't appear to accept connections from arbitrary public > IP addresses (i et "connection timed out") so i assume it's limited to > the campus or something. > > In the discussions below, note that an X.509 certificate has a subject > ("who the cert belongs to") and an issuer ("who is doing the certifying") > >> - Got a certificate list of 4 certificates. >> - Certificate[0] info: >> - subject `C=BE,L=Leuven,O=Katholieke Universiteit >> Leuven,OU=Competentiecentrum Informatiebeveiliging,CN=ldap.kuleuven.be', >> issuer `C=NL,O=TERENA,CN=TERENA SSL CA', RSA key 2048 bits, signed using >> RSA-SHA1, activated `2012-01-25 00:00:00 UTC', expires `2015-01-24 >> 23:59:59 UTC', SHA-1 fingerprint `9dc847d52b4e478b314dccbbf0382645822062db' > the above (Certificate[0]) is called the "end entity" (EE) certificate, > meaning that it is the certificate that belongs to the endpoint itself > (your LDAP server). > >> - Certificate[1] info: >> - subject `C=NL,O=TERENA,CN=TERENA SSL CA', issuer `C=US,ST=UT,L=Salt >> Lake City,O=The USERTRUST >> Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key >> 2048 bits, signed using RSA-SHA1, activated `2009-05-18 00:00:00 UTC', >> expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint >> `3a881764472b6441ddb3afdd47c6b8b76ee7ba1d' > Certificate[1] here belongs to an "intermediate certificate authority > "(the "TERENA SSL CA"). they issued your LDAP server's EE certificate. > In turn, their certificate is issued by: > >> - Certificate[2] info: >> - subject `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST >> Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', issuer >> `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust >> External CA Root', RSA key 2048 bits, signed using RSA-SHA1, activated >> `2005-06-07 08:09:10 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 >> fingerprint `3d4b2a4c64317143f50258d7e6fd7d3c021a529e' > Certificate[2] belongs to another intermediate CA, and ... > >> - Certificate[3] info: >> - subject `C=SE,O=AddTrust AB,OU=AddTrust External TTP >> Network,CN=AddTrust External CA Root', issuer `C=SE,O=AddTrust >> AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA >> key 2048 bits, signed using RSA-SHA1, activated `2000-05-30 10:48:38 >> UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint >> `02faf3e291435468607857694df5e45b68851868' > > Based on the sha-1 fingerprint, Certificate[3] here matches the file on > my debian system: > > /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt > > This is not an intermediate CA, but a "root CA" -- that is, the issuer > is the same as the subject. this certificate is widely distributed in > several public certificate-verifying tools, like the mozilla firefox web > browser. > > According to the TLS spec, this last certificate does not need to be > sent at all, > > "Under the > assumption that the remote end must already possess it in order to > validate it in any case." > > https://tools.ietf.org/html/rfc5246#page-48 > > If the admins of this LDAP server want to decrease the size of their TLS > handshakes, they could remove that certificate from the list they offer > on each handshake. > >> - The hostname in the certificate matches 'ldap.kuleuven.be'. >> - Peer's certificate issuer is unknown >> - Peer's certificate is NOT trusted > So this is why gnutls-cli can't verify it. if gnutls-cli doesn't have > *any* trusted root certificate authorities, the ultimate issuer of a > cert is always going to be unknown. > >> The procedure I followed to add the certificates was: I created a >> directory /usr/share/ca-certificates/ldap.kuleuven.be and added all >> certificates in seperate files and in one file combined as well. Next I >> edited /etc/ca-certificates.conf to add all of those files and ran >> update-ca-certificates. All certificates turned up nicely in >> /etc/ssl/certs/ > I don't think you actually want to add the certificates of these > intermediate CAs to your list of trusted root stores in the first place > -- you just need to give gnutls-cli some indication of where it should > look for its trusted CAs. > > In particular, by adding the intermediate CAs to your trusted root list, > you're granting them longstanding independent ability to forge > certificates for remote parties, even if the root on which they depend > has been revoked or deprecated. > > And you certainly don't want to place any EE certificates in your list > of trusted root authorities, since they should not be certifying > anything anyway. > > > That said, if you *do* want to add trusted root CAs to a debian-derived > system that aren't already shipped in the ca-certificates package, you > probably don't want to tamper with the contents of > /usr/share/ca-certificates directly. That part of the filesystem is > controlled by the ca-certificates package. > > Instead, for any CA that you want to add to a system as the admin, you > only need to drop a world-readable PEM-encoded file containing the CA's > certificate into /usr/share/ca-certificates/, and then re-run > "update-ca-certificates" as the superuser. This will create links > properly under /etc/ssl/certs, and will include them in > /etc/ssl/ca-certificates.crt. > > This last file is what is used as the default x.509 ca authority list on > recent versions of gnutls-cli on debian, and could be specified as > --x509cafile if you want to mimic that behavior when running an earlier > version. > >> I verified that all permission were correct. Our webserver which is >> doing these connections uses Ubuntu 12.04 Server which uses gnutls >> 3.0.11 if that is of any use to you. > Thanks! This bit of critical information should always be up front in > any problem report so that folks trying to solve it know what they're > dealing with! > > Please let me know if you have any extra questions. > > Regards, > > --dkg > From jnewell at rajant.com Fri Sep 21 17:58:49 2012 From: jnewell at rajant.com (Jim Newell) Date: Fri, 21 Sep 2012 11:58:49 -0400 Subject: the ./configure script doesn't appear to honor --disable-openpgp-authentication Message-ID: If I configure gnutls 3.1.1 using --disable-openpgp-authentication the config.h file is still generated with: /* use openpgp authentication */ /* #undef ENABLE_OPENPGP */ Is there is another flag I'm failing to use to obtain the desired result to disabe the openpgp? Regards, Jim Newell -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnewell at rajant.com Fri Sep 21 20:12:10 2012 From: jnewell at rajant.com (Jim Newell) Date: Fri, 21 Sep 2012 14:12:10 -0400 Subject: the ./configure script doesn't appear to honor --disable-openpgp-authentication In-Reply-To: References: Message-ID: Never mind. The cert_verify() function in src/common.c and a few other places are not surrounding code with the ENABLE_OPENPGP define, and causing linker errors: make[4]: Entering directory `/home/jnewell/work/v11/build-host-debug/build/gnutls-3.1.1/src' CCLD gnutls-serv ../lib/.libs/libgnutls.so: undefined reference to `gnutls_privkey_import_openpgp' ../lib/.libs/libgnutls.so: undefined reference to `gnutls_openpgp_privkey_import' ../lib/.libs/libgnutls.so: undefined reference to `gnutls_openpgp_privkey_set_preferred_key_id' ../lib/.libs/libgnutls.so: undefined reference to `gnutls_openpgp_privkey_init' ../lib/.libs/libgnutls.so: undefined reference to `gnutls_openpgp_privkey_deinit' collect2: error: ld returned 1 exit status Regards, Jim On Fri, Sep 21, 2012 at 11:58 AM, Jim Newell wrote: > If I configure gnutls 3.1.1 using --disable-openpgp-authentication the > config.h file is still generated with: > > /* use openpgp authentication */ > /* #undef ENABLE_OPENPGP */ > > Is there is another flag I'm failing to use to obtain the desired result > to disabe the openpgp? > > Regards, > > Jim Newell > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Sep 21 21:37:29 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Sep 2012 21:37:29 +0200 Subject: the ./configure script doesn't appear to honor --disable-openpgp-authentication In-Reply-To: References: Message-ID: <505CC1F9.30000@gnutls.org> On 09/21/2012 08:12 PM, Jim Newell wrote: > Never mind. The cert_verify() function in src/common.c and a few other > places are not surrounding code with the ENABLE_OPENPGP define, and > causing linker errors: > make[4]: Entering directory > `/home/jnewell/work/v11/build-host-debug/build/gnutls-3.1.1/src' > CCLD gnutls-serv > ../lib/.libs/libgnutls.so: undefined reference to > `gnutls_privkey_import_openpgp' > ../lib/.libs/libgnutls.so: undefined reference to > `gnutls_openpgp_privkey_import' Thanks for reporting that. It'll be fixed in the next release. regards, Nikos From joke at seiken.de Sat Sep 22 20:53:21 2012 From: joke at seiken.de (Joke de Buhr) Date: Sat, 22 Sep 2012 20:53:21 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <505C91E8.4050802@gnutls.org> References: <1623677.UjvJFP0Yb5@oberon> <1547701.3TFnZd7ukx@oberon> <505C91E8.4050802@gnutls.org> Message-ID: <2145252.WIXGYptuk6@oberon> On Friday 21 September 2012 18:12:24 you wrote: > On 09/21/2012 11:37 AM, Joke de Buhr wrote: > > hi, > > > > i discovered the internal error seems to be related to the openpgp key > > size. if the key contains just a single signing subkey with 2048 or more > > bits gnutls reports the internal error. a signing subkey with 1024 bits > > will however. > > > > moreover the key can contain encryption subkeys up to 4096 bits without > > problem as long as the encryption subkey isn't marked for signing. the > > authentication flags doesn't seem to have any effect at all. > > > > the problem seems to be related to the key exchange algorithm. the > > signature flag enables DHE_RSA and ECDHE_RSA whereas the encryption flag > > enable RSA key exchange. > > any comments on how to avoid this problem? > > Sorry for the late reply. What you say about the sizes could be because > of a static buffer used in gnutls. Could you enable debugging to figure > out which place rejects the long keys? gnutls version 3.1.1 the internal error occurs with "lib/openpgp/privkey.c" during reimporting the private key "gnutls_openpgp_privkey_import()" line 111. the key is exported into memory and imported from memory later on. the buffer created for the export is exactly as big as the binary format export from gnupg2. i did a memory dump via gdb and discovered the dumped key and the original gnupg key differ in some places. the differences are locate within the files. gnupg seems to be able to import the dumped key again. i trace the origin of the error value back to read_subpkt() origination from #0 read_subpkt() at opencdk/read-packet.c:609 #1 read_signature() at opencdk/read-packet.c:788 #2 cdk_pkt_read() at opencdk/read-packet.c:1076 #3 cdk_keydb_get_keyblock() at opencdk/keydb.c:1820 #4 cdk_kbnode_read_from_mem() at opencdk/kbnode.c:426 #5 gnutls_openpgp_privkey_import() at openpgp/privkey.c:184 #6 _gnutls_openpgp_privkey_cpy() at openpgp/privkey.c:110 #7 gnutls_privkey_import_openpgp() at gnutls_privkey.c:590 #8 gnutls_certificate_set_openpgp_key() at openpgp/gnutls_openpgp.c:106 #9 main() at /dev/shm/test.c++:61 read_subpkt sets nbytes in "read-paket.c:792". the nbytes is subtracted from size. size = 574 and nbytes = 706. the new value of size is 18446744073709551484. there seems to be a problem with the expected size of the subpaket and the calculated size (nbytes) of the subpaket. why these values differ i do not know. but the functions seem to be doing what they are supposed to be doing. if you need further information i need to know what i should be looking for. > About the signing flags, you need them in order to use DHE-RSA and > ECDHE-RSA. Those two require RSA signatures. The RSA algorithm requires > an RSA encryption key. Does this explain what you notice? rfc6091 and the old rfc5081 both state in section 3.3 state: Key Exchange Algorithm OpenPGP Certificate Type RSA - RSA public key that can be used for encryption. DHE_DSS - DSA public key that can be used for authentication. DHE_RSA - RSA public key that can be used for authentication. i don't know enough of openpgp certificate internals but the rfc doesn't mention anything about a signing capable certificate. the gnutls documentation on the other hand states in section 4 to use DHS_RSA the key must by capable of signing. which capabilities are actually required? is the rfc wrong or didn't i read it carefully enough. to be honest i skimmed it. regards joke > regards, > Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Sun Sep 23 12:23:01 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 Sep 2012 12:23:01 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <2145252.WIXGYptuk6@oberon> References: <1623677.UjvJFP0Yb5@oberon> <1547701.3TFnZd7ukx@oberon> <505C91E8.4050802@gnutls.org> <2145252.WIXGYptuk6@oberon> Message-ID: <505EE305.8090400@gnutls.org> On 09/22/2012 08:53 PM, Joke de Buhr wrote: > the internal error occurs with "lib/openpgp/privkey.c" during reimporting the > private key "gnutls_openpgp_privkey_import()" line 111. > the key is exported into memory and imported from memory later on. the buffer > created for the export is exactly as big as the binary format export from > gnupg2. i did a memory dump via gdb and discovered the dumped key and the > original gnupg key differ in some places. the differences are locate within > the > files. gnupg seems to be able to import the dumped key again. > i trace the origin of the error value back to read_subpkt() origination from > > #0 read_subpkt() at opencdk/read-packet.c:609 > #1 read_signature() at opencdk/read-packet.c:788 > #2 cdk_pkt_read() at opencdk/read-packet.c:1076 > #3 cdk_keydb_get_keyblock() at opencdk/keydb.c:1820 > #4 cdk_kbnode_read_from_mem() at opencdk/kbnode.c:426 > #5 gnutls_openpgp_privkey_import() at openpgp/privkey.c:184 > #6 _gnutls_openpgp_privkey_cpy() at openpgp/privkey.c:110 > #7 gnutls_privkey_import_openpgp() at gnutls_privkey.c:590 > #8 gnutls_certificate_set_openpgp_key() at openpgp/gnutls_openpgp.c:106 > #9 main() at /dev/shm/test.c++:61 > read_subpkt sets nbytes in "read-paket.c:792". the nbytes is subtracted from > size. I see this code expects size to get negative at some point, so if you change the type of size to ssize_t does it help? > if you need further information i need to know what i should be looking for. Could you provide me with a scenario and the certificates needed to reproduce it? >> About the signing flags, you need them in order to use DHE-RSA and >> ECDHE-RSA. Those two require RSA signatures. The RSA algorithm requires >> an RSA encryption key. Does this explain what you notice? > rfc6091 and the old rfc5081 both state in section 3.3 state: Seeing that it seems some unfortunate mix of terminology. RFC4880 says "Authentication via digital signatures", so authentication in this context is signing, and from my discussions with OpenPGP people at that time, I accepted that the term authentication key was used to mean the signing key. There is no big confusion (IMO) because RSA keys can be used for digital signatures or encryption, and DSA keys for digital signatures (there is no separate authentication usage). > i don't know enough of openpgp certificate internals but the rfc doesn't > mention anything about a signing capable certificate. the gnutls documentation > on the other hand states in section 4 to use DHS_RSA the key must by capable > of signing. This is correct. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From joke at seiken.de Sun Sep 23 16:54:39 2012 From: joke at seiken.de (Joke de Buhr) Date: Sun, 23 Sep 2012 16:54:39 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <505EE305.8090400@gnutls.org> References: <1623677.UjvJFP0Yb5@oberon> <2145252.WIXGYptuk6@oberon> <505EE305.8090400@gnutls.org> Message-ID: <4150549.tssaK06Jtp@oberon> On Sunday 23 September 2012 12:23:01 Nikos Mavrogiannopoulos wrote: > On 09/22/2012 08:53 PM, Joke de Buhr wrote: > > the internal error occurs with "lib/openpgp/privkey.c" during reimporting > > the private key "gnutls_openpgp_privkey_import()" line 111. > > the key is exported into memory and imported from memory later on. the > > buffer created for the export is exactly as big as the binary format > > export from gnupg2. i did a memory dump via gdb and discovered the dumped > > key and the original gnupg key differ in some places. the differences are > > locate within the > > files. gnupg seems to be able to import the dumped key again. > > i trace the origin of the error value back to read_subpkt() origination > > from > > > > #0 read_subpkt() at opencdk/read-packet.c:609 > > #1 read_signature() at opencdk/read-packet.c:788 > > #2 cdk_pkt_read() at opencdk/read-packet.c:1076 > > #3 cdk_keydb_get_keyblock() at opencdk/keydb.c:1820 > > #4 cdk_kbnode_read_from_mem() at opencdk/kbnode.c:426 > > #5 gnutls_openpgp_privkey_import() at openpgp/privkey.c:184 > > #6 _gnutls_openpgp_privkey_cpy() at openpgp/privkey.c:110 > > #7 gnutls_privkey_import_openpgp() at gnutls_privkey.c:590 > > #8 gnutls_certificate_set_openpgp_key() at openpgp/gnutls_openpgp.c:106 > > #9 main() at /dev/shm/test.c++:61 > > read_subpkt sets nbytes in "read-paket.c:792". the nbytes is subtracted > > from size. > > I see this code expects size to get negative at some point, > so if you change the type of size to ssize_t does it help? i changed the type of size from size_t to ssize_t. on a quick check the error change from GNUTLS_E_INTERNAL_ERROR to GNUTLS_E_MPI_SCAN_FAILED. fixing the problem doesn't seem to be that simple unfortunately. > > if you need further information i need to know what i should be looking > > for. > Could you provide me with a scenario and the certificates needed to > reproduce it? of cause. if the mailing list doesn't support attachments i can inline them. the example program reads the keys, initializes the structures and sets the credential. it should be calls with public key as first argument and private key as second. both in raw binary format. the key contains a rsa master key usable for certification only and a rsa subkey capable for siging, encryption and authentication. the key was generated with gnupg2 in expert mode to allow custom flags to be set. it was exported with "gpg2 --openpgp --export". > >> About the signing flags, you need them in order to use DHE-RSA and > >> ECDHE-RSA. Those two require RSA signatures. The RSA algorithm requires > >> an RSA encryption key. Does this explain what you notice? > > > > rfc6091 and the old rfc5081 both state in section 3.3 state: > Seeing that it seems some unfortunate mix of terminology. RFC4880 says > "Authentication via digital signatures", so authentication in this > context is signing, and from my discussions with OpenPGP people at that > time, I accepted that the term authentication key was used to mean the > signing key. well the signing (S), encryption (E) and authentication (A) flags can be set individually with gnupg operating in expert mode (--expert). the master key has an additional flags for certification (C). subkeys with authentication flag are used when gpg-agent operates in ssh-agent mode and connects to a ssh server. i'm sure gnupg does the authentication via digital signatures during the sshd handshake. since the actual behavior is a bit unclear i think it would be helpful to mention gnutls requires the signing flag in the gnutls documentation. but i can definitely get your point. > There is no big confusion (IMO) because RSA keys can be used for digital > signatures or encryption, and DSA keys for digital signatures (there is > no separate authentication usage). > > > i don't know enough of openpgp certificate internals but the rfc doesn't > > mention anything about a signing capable certificate. the gnutls > > documentation on the other hand states in section 4 to use DHS_RSA the > > key must by capable of signing. to be precise of cause openpgp certificates can be used for signing but the rfc doesn't mention anything about the need to enable signing flags. > This is correct. > > regards, > Nikos regards joke -------------- next part -------------- A non-text attachment was scrubbed... Name: pub.gpg Type: application/pgp-encrypted Size: 2782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: priv.gpg Type: application/pgp-encrypted Size: 5364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.c Type: text/x-c++src Size: 1317 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 729 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Sun Sep 23 19:09:26 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 Sep 2012 19:09:26 +0200 Subject: Internal error returned from within gnutls_certificate_set_openpgp_key() In-Reply-To: <4150549.tssaK06Jtp@oberon> References: <1623677.UjvJFP0Yb5@oberon> <2145252.WIXGYptuk6@oberon> <505EE305.8090400@gnutls.org> <4150549.tssaK06Jtp@oberon> Message-ID: <505F4246.9030405@gnutls.org> On 09/23/2012 04:54 PM, Joke de Buhr wrote: >> I see this code expects size to get negative at some point, >> so if you change the type of size to ssize_t does it help? > > i changed the type of size from size_t to ssize_t. on a quick check the error > change from GNUTLS_E_INTERNAL_ERROR to GNUTLS_E_MPI_SCAN_FAILED. > fixing the problem doesn't seem to be that simple unfortunately. It seems it was an encoding bug that was triggered by the increase in key size. Thanks for reporting it. The patch below should solve it: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=4366201402fcdecde2331e4d87c05141207e1027 > well the signing (S), encryption (E) and authentication (A) flags can be set > individually with gnupg operating in expert mode (--expert). the master key > has an additional flags for certification (C). > > subkeys with authentication flag are used when gpg-agent operates in ssh-agent > mode and connects to a ssh server. i'm sure gnupg does the authentication via > digital signatures during the sshd handshake. > > since the actual behavior is a bit unclear i think it would be helpful to > mention gnutls requires the signing flag in the gnutls documentation. but i can > definitely get your point. Do you have some suggestion on where this should be mentioned? regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From mrsam at courier-mta.com Mon Sep 24 07:02:46 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 24 Sep 2012 01:02:46 -0400 Subject: C++ classes Message-ID: Earlier this year I mentioned that I was working on C++ classes that used the GnuTLS library. This was not really a dedicated set of C++ classes, but a part of a larger collection of C++ classes and templates. The class library is now in a fairly usable shape: http://www.libcxx.org ? its GnuTLS portion (http://www.libcxx.org/gnutls.html) does not C++ify all parts of the GnuTLS library API, just the bits needed to establish client and server-side TLS session, and certificate management. Also, with one exception libcxx is Linux only; this won't be of much use outside of Linux (and FreeBSD 9, the other platform). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ali.khalfan at gmail.com Mon Sep 24 08:03:54 2012 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Mon, 24 Sep 2012 09:03:54 +0300 Subject: gnutls and handshake issue supported cipher suite Message-ID: <505FF7CA.8080905@gmail.com> I am trying to setup openvas on my machine (ubuntu 12.04.1 32 bit ) and I noticed that the openvas manager is not able to connect due to a handshake problem. I tried simulating the openvas server with gnutls-serv sudo gnutls-serv -d 9 --x509keyfile /usr/local/var/lib/openvas/private/CA/serverkey.pem --x509certfile /usr/local/var/lib/openvas/CA/servercert.pem --x509cafile /usr/local/var/lib/openvas/CA/cacert.pem -p 9393 Set static Diffie-Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). Echo Server listening on IPv4 0.0.0.0 port 9393...done Echo Server listening on IPv6 :: port 9393...bind() failed: Address already in use |<4>| REC[0x9f5c8a0]: Allocating epoch #0 When I tried to connect the openvas manager I get the below problem. Note: I tried simulating the same thing with openssl and I got a handshake. I'm not sure where "Error: Could not negotiate a supported cipher suite." is coming from sudo gnutls-serv -d 9 --x509keyfile /usr/local/var/lib/openvas/private/CA/serverkey.pem --x509certfile /usr/local/var/lib/openvas/CA/servercert.pem --x509cafile /usr/local/var/lib/openvas/CA/cacert.pem -p 9393 Set static Diffie-Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). Echo Server listening on IPv4 0.0.0.0 port 9393...done Echo Server listening on IPv6 :: port 9393...bind() failed: Address already in use |<4>| REC[0x9f5c8a0]: Allocating epoch #0 * Accepted connection from IPv4 127.0.0.1 port 49340 on Mon Sep 24 08:58:42 2012 |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x9f5c8a0]: Allocating epoch #1 |<4>| REC[0x9f5c8a0]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9f5c8a0]: Received Packet[0] Handshake(22) with length: 108 |<4>| REC[0x9f5c8a0]: Decrypted Packet[0] Handshake(22) with length: 108 |<3>| HSK[0x9f5c8a0]: CLIENT HELLO was received [108 bytes] |<3>| HSK[0x9f5c8a0]: Client's version: 3.3 |<2>| ASSERT: gnutls_db.c:326 |<2>| ASSERT: gnutls_db.c:246 |<2>| EXT[0x9f5c8a0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<2>| EXT[0x9f5c8a0]: Parsing extension 'SIGNATURE ALGORITHMS/13' (16 bytes) |<2>| EXT[SIGA]: rcvd signature algo (4.1) RSA-SHA256 |<2>| EXT[SIGA]: rcvd signature algo (4.2) DSA-SHA256 |<2>| EXT[SIGA]: rcvd signature algo (4.3) GOST R 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo (5.1) RSA-SHA384 |<2>| EXT[SIGA]: rcvd signature algo (5.3) GOST R 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo (6.1) RSA-SHA512 |<2>| EXT[SIGA]: rcvd signature algo (6.3) GOST R 34.10-94 |<2>| ASSERT: gnutls_handshake.c:3348 |<1>| Could not find an appropriate certificate: Insufficient credentials for that request. |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9f5c8a0]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 |<2>| ASSERT: gnutls_handshake.c:921 |<2>| ASSERT: gnutls_handshake.c:586 |<2>| ASSERT: gnutls_handshake.c:2358 |<2>| ASSERT: gnutls_handshake.c:2991 Error in handshake Error: Could not negotiate a supported cipher suite. |<4>| REC: Sending Alert[2|40] - Handshake failed |<4>| REC[0x9f5c8a0]: Sending Packet[0] Alert(21) with length: 2 |<4>| REC[0x9f5c8a0]: Sent Packet[1] Alert(21) with length: 7 |<2>| ASSERT: gnutls_record.c:276 |<4>| REC[0x9f5c8a0]: Epoch #0 freed |<4>| REC[0x9f5c8a0]: Epoch #1 freed From n.mavrogiannopoulos at gmail.com Mon Sep 24 21:05:46 2012 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 24 Sep 2012 21:05:46 +0200 Subject: C++ classes In-Reply-To: References: Message-ID: <5060AF0A.3010001@gmail.com> On 09/24/2012 07:02 AM, Sam Varshavchik wrote: > Earlier this year I mentioned that I was working on C++ classes that > used the GnuTLS library. This was not really a dedicated set of C++ > classes, but a part of a larger collection of C++ classes and templates. > > The class library is now in a fairly usable shape: http://www.libcxx.org > ? its GnuTLS portion (http://www.libcxx.org/gnutls.html) does not C++ify > all parts of the GnuTLS library API, just the bits needed to establish > client and server-side TLS session, and certificate management. Thank you. I'll update the web site (savanah seems to be down) to mention that. btw. I notice that you discuss the RSA-EXPORT ciphersuites. Is there any particular reason for that? They are not be used today and I'm not aware of any countries that specifically allow them but not the strong ones. I plan to remove them from gnutls completely in one of the upcoming releases. regards, Nikos From mrsam at courier-mta.com Tue Sep 25 00:35:28 2012 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 24 Sep 2012 18:35:28 -0400 Subject: C++ classes References: <5060AF0A.3010001@gmail.com> Message-ID: Nikos Mavrogiannopoulos writes: > On 09/24/2012 07:02 AM, Sam Varshavchik wrote: > > > Earlier this year I mentioned that I was working on C++ classes that > > used the GnuTLS library. This was not really a dedicated set of C++ > > classes, but a part of a larger collection of C++ classes and templates. > > > > The class library is now in a fairly usable shape: http://www.libcxx.org > > ? its GnuTLS portion (http://www.libcxx.org/gnutls.html) does not C++ify > > all parts of the GnuTLS library API, just the bits needed to establish > > client and server-side TLS session, and certificate management. > > > Thank you. I'll update the web site (savanah seems to be down) to > mention that. > > btw. I notice that you discuss the RSA-EXPORT ciphersuites. Is there any > particular reason for that? They are not be used today and I'm not aware > of any countries that specifically allow them but not the strong ones. I > plan to remove them from gnutls completely in one of the upcoming releases. No particular reason, just that they were always there, so I always had some code that chewed them. As soon as they don't compile any more, I'll get rid of them. Are those functions marked as deprecated? I pay attention to compiler warnings, but I don't recall seeing any warnings about them. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Tue Sep 25 09:47:58 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 25 Sep 2012 09:47:58 +0200 Subject: C++ classes In-Reply-To: References: <5060AF0A.3010001@gmail.com> Message-ID: On Tue, Sep 25, 2012 at 12:35 AM, Sam Varshavchik wrote: >> Thank you. I'll update the web site (savanah seems to be down) to >> mention that. >> btw. I notice that you discuss the RSA-EXPORT ciphersuites. Is there any >> particular reason for that? They are not be used today and I'm not aware >> of any countries that specifically allow them but not the strong ones. I >> plan to remove them from gnutls completely in one of the upcoming >> releases. > No particular reason, just that they were always there, so I always had some > code that chewed them. As soon as they don't compile any more, I'll get rid > of them. > Are those functions marked as deprecated? I pay attention to compiler > warnings, but I don't recall seeing any warnings about them. I think that most functions that are used for RSA-EXPORT are also used for RSA key generation so they will not be deprecated. What will be removed are the priority strings "EXPORT", "RSA-EXPORT" and ARCFOUR-40. regards, Nikos From jnewell at rajant.com Tue Sep 25 17:43:57 2012 From: jnewell at rajant.com (Jim Newell) Date: Tue, 25 Sep 2012 11:43:57 -0400 Subject: disable building docs and tests Message-ID: Hello, Is there a mechanism to disable building the docs and tests directories? Regards, Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Sep 26 20:48:12 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Sep 2012 20:48:12 +0200 Subject: gnutls 3.0.24 Message-ID: <50634DEC.9030809@gnutls.org> Hello, I've just released gnutls 3.0.24. This is a bug-fix release on the old stable branch. * Version 3.0.24 (released 2012-09-26) ** libgnutls: The %COMPAT keyword, if specified, will tolerate key usage violation errors (they are far too common to ignore). ** libgnutls: Corrected bug in OpenPGP subpacket encoding. ** libgnutls: Added X.509 certificate verification flag GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. This flag allows the verification of unsorted certificate chains and is enabled by default for TLS certificate verification (if gnutls_certificate_set_verify_flags() does not override it). ** libgnutls: Correctly restore gnutls_record_recv() in DTLS mode if interrupted during the retrasmition of handshake data. ** libgnutls: Added GNUTLS_STATELESS_COMPRESSION flag to gnutls_init(), which provides a tool to counter compression-related attacks where parts of the data are controlled by the attacker _and_ are placed in separate records (use with care - do not use compression if not sure). ** libgnutls: Depends on libtasn1 2.14 or later. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.24.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.24.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.24.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.24.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.24.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 gnutls.org> uid Nikos Mavrogiannopoulos 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 nmav at gnutls.org Wed Sep 26 20:54:28 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Sep 2012 20:54:28 +0200 Subject: gnutls 3.1.2 Message-ID: <50634F64.6080905@gnutls.org> Hello, I've just released gnutls 3.1.2. This release includes feature updates, notably support for the DTLS heartbeat message, and bug fixes in the current stable branch. * Version 3.1.2 (released 2012-09-26) ** libgnutls: Fixed bug in gnutls_x509_trust_list_add_system_trust() and gnutls_x509_trust_list_add_trust_mem() that prevented the loading of certificates in the windows platform. ** libgnutls: Corrected bug in OpenPGP subpacket encoding. ** libgnutls: Added support for DTLS/TLS heartbeats by Olga Smolenchuk. (the work was done during Google Summer of Code). ** libgnutls: Added X.509 certificate verification flag GNUTLS_VERIFY_ALLOW_UNSORTED_CHAIN. This flag allows the verification of unsorted certificate chains and is enabled by default for TLS certificate verification (if gnutls_certificate_set_verify_flags() does not override it). ** libgnutls: Prints warning on certificates that contain keys of an insecure level. If the %COMPAT priority flag is not specified the TLS connection fails. ** libgnutls: Correctly restore gnutls_record_recv() in DTLS mode if interrupted during the retrasmition of handshake data. ** libgnutls: Better mingw32 support (patch by LRN). ** libgnutls: The %COMPAT keyword, if specified, will tolerate key usage violation errors (they are far too common to ignore). ** libgnutls: Added GNUTLS_STATELESS_COMPRESSION flag to gnutls_init(), which provides a tool to counter compression-related attacks where parts of the data are controlled by the attacker _and_ are placed in separate records (use with care - do not use compression if not sure). ** libgnutls: Depends on libtasn1 2.14 or later. ** certtool: Prints the number of bits of the public key algorithm parameter in a private key. ** API and ABI modifications: gnutls_x509_privkey_get_pk_algorithm2: Added gnutls_heartbeat_ping: Added gnutls_heartbeat_pong: Added gnutls_heartbeat_allowed: Added gnutls_heartbeat_enable: Added gnutls_heartbeat_set_timeouts: Added gnutls_heartbeat_get_timeout: Added GNUTLS_SEC_PARAM_WEAK: Added GNUTLS_SEC_PARAM_INSECURE: Added Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.2.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 gnutls.org> uid Nikos Mavrogiannopoulos 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 ali.khalfan at gmail.com Thu Sep 27 12:58:23 2012 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Thu, 27 Sep 2012 13:58:23 +0300 Subject: insufficient credentials for that request Message-ID: <5064314F.6080007@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have got gnutls-serv running as such : sudo gnutls-serv -d 15 --x509keyfile serverkey.pem --x509certfile servercert.pem --x509cafile cacert.pem -p 9393 I am trying to run another program that connects to port 9393 and I get an insufficient credentials error as shown in the debug message below Can anyone shed some light on this ? * Accepted connection from IPv4 127.0.0.1 port 50607 on Thu Sep 27 13:49:49 2012 |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x9be18a0]: Allocating epoch #1 |<7>| READ: Got 5 bytes from 0x5 |<7>| READ: read 5 bytes from 0x5 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9be18a0]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9be18a0]: Received Packet[0] Handshake(22) with length: 108 |<7>| READ: Got 108 bytes from 0x5 |<7>| READ: read 108 bytes from 0x5 |<7>| RB: Have 5 bytes into buffer. Adding 108 bytes. |<7>| RB: Requested 113 bytes |<4>| REC[0x9be18a0]: Decrypted Packet[0] Handshake(22) with length: 108 |<6>| BUF[HSK]: Inserted 108 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[0x9be18a0]: CLIENT HELLO was received [108 bytes] |<6>| BUF[REC][HD]: Read 104 bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 104 bytes of Data |<3>| HSK[0x9be18a0]: Client's version: 3.3 |<2>| ASSERT: gnutls_db.c:326 |<2>| ASSERT: gnutls_db.c:246 |<2>| EXT[0x9be18a0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<2>| EXT[0x9be18a0]: Parsing extension 'SIGNATURE ALGORITHMS/13' (16 bytes) |<2>| EXT[SIGA]: rcvd signature algo (4.1) RSA-SHA256 |<2>| EXT[SIGA]: rcvd signature algo (4.2) DSA-SHA256 |<2>| EXT[SIGA]: rcvd signature algo (4.3) GOST R 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo (5.1) RSA-SHA384 |<2>| EXT[SIGA]: rcvd signature algo (5.3) GOST R 34.10-94 |<2>| EXT[SIGA]: rcvd signature algo (6.1) RSA-SHA512 |<2>| EXT[SIGA]: rcvd signature algo (6.3) GOST R 34.10-94 |<2>| ASSERT: gnutls_handshake.c:3348 |<1>| Could not find an appropriate certificate: Insufficient credentials for that request. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBCgAGBQJQZDFJAAoJEF9xp9NDNF0koHMQAKXYJCIicg9ikhCm4Zr9ebBC CazLirREEb+3hTQMA28YHdqO7HvQXyNm/LnTaNpa6GRZShEszJEMzI0zIqS6DB6G DyE9PH82ffMQoaS+TgdxtiNEV2r7rnMP6W+aSmTxyshNkO4bVktMQhFlDSbPk7+2 GKGgWA7DlZmEiyQGfEfwch7KD/YuP8ttlHeGmk5WiJW2A0b2LxPwyS/sMgz9dIK7 OAdXEn4SqKF6l6DqFIIUdlo0CD2Hou1CG3tVxKaqcPiLSSanGUQVHXpaMNRcLpkf NPnAHjjxJTLlRJTVd8F/as/gReR/n3Vkcts7fLT97pUTGF7GdBmULp1QO4YO9j3i Z5rC1sy88rEO204KnokMrVVlvOf40zR4kSQ9JAbgD4AJLVvgs+xyrTvMZMu48DXs OXTMn+Irp2bEzGZKEUHDWxTXkTdnmQAkik9/XWrTwaEL31dGJSx+wGJGcR8Z5tU1 GdwCT6Y12DE3Byv5WijXa/d4jtJUfe80j9j7axL/W6F5YB00dbirSFnc6yBE9D+0 pS7NXchL6WQSuKjFbA+O8I9fHrAs9Q/ar8DVK98I6kR2KKN2o98o0iYrHr+AMEUg Xr09DRx04/8h2oLgH+Ph6x+hRiTJHg9j+6d+9vTC1zA/EwqsIeSMw2FHMQbELGFP 6vGwB5jUSaptB9CXpD5g =84Y0 -----END PGP SIGNATURE-----