From nmav at gnutls.org Fri May 6 17:45:47 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 06 May 2011 17:45:47 +0200 Subject: gnutls 2.12.4 Message-ID: <4DC417AB.9070902@gnutls.org> Hello, I've just released gnutls 2.12.4. What's New ========== ** libgnutls: Added gnutls_certificate_get_issuer() to compensate for the deprecated gnutls_certificate_get_x509_cas(). ** libgnutls: Limited allowed wildcards to gnutls_x509_crt_check_hostname() to prevent denial of service attacks. Reported by Kalle Olavi Niemitalo. ** guile: Fix tests to match the `exit' behavior introduced in Guile 2.0.1. This fix makes tests behave correctly wrt. to the Guile bug fix at . ** API and ABI modifications: gnutls_certificate_get_issuer: ADDED Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.4.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.4.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.4.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.4.tar.bz2.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 Sat May 14 11:26:06 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 14 May 2011 11:26:06 +0200 Subject: gnutls 2.12.5 Message-ID: <4DCE4AAE.6030407@gnutls.org> Hello, I've just released gnutls 2.12.5. What's New ========== ** certtool: Can now load private keys and public keys from PKCS #11 tokens via URLs. ** libgnutls: PKCS #11 URLs conform to the latest draft being http://tools.ietf.org/html/draft-pechanec-pkcs11uri-04. ** libgnutls: gnutls_pkcs11_privkey_import_url() will now correctly read the public key algorithm of the key. ** libgnutls: Added gnutls_x509_crq_verify() to allow verification of the self signature in a certificate request. This allows verifying whether the owner of the private key is the generator of the request. ** libgnutls: gnutls_x509_crt_set_crq() implicitly verifies the self signature of the request. ** API and ABI modifications: gnutls_x509_crq_verify: ADDED Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From and a list of GnuTLS mirrors can be found at . Here are the BZIP2 compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.5.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.5.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.5.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.5.tar.bz2.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 gallowaymd at ornl.gov Mon May 16 21:37:11 2011 From: gallowaymd at ornl.gov (Galloway, Michael D.) Date: Mon, 16 May 2011 15:37:11 -0400 Subject: building 2.12.5 on SLES11 problems Message-ID: Good day all, I'm trying to build 2.12.5 on SLES11 system and getting this build problem from the libgcrypt module: Making all in gcrypt make[4]: Entering directory `/usr/local/gnutls-2.12.5/lib/gcrypt' CC pk.lo CC mpi.lo CC mac.lo CC cipher.lo CC rnd.lo CC init.lo init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a function) make[4]: *** [init.lo] Error 1 make[4]: Leaving directory `/usr/local/gnutls-2.12.5/lib/gcrypt' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/local/gnutls-2.12.5/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/gnutls-2.12.5/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/gnutls-2.12.5' make: *** [all] Error 2 configure was simple: ./configure --with-libgcrypt ... configure: summary of build options: version: 2.12.5 shared 46:0:20 Host type: x86_64-unknown-linux-gnu Install prefix: /usr/local Compiler: gcc -std=gnu99 Warning flags: errors: warnings: Library types: Shared=yes, Static=yes Valgrind: no Guile wrappers: yes C++ library: yes OpenSSL library: yes /dev/crypto: no Crypto library: libgcrypt Gcrypt version is: libgcrypt-devel-1.4.1-6.7 libgcrypt11-1.4.1-6.7 libgcrypt11-32bit-1.4.1-6.7 Any help appreciated. Thanks! ---- michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon May 16 21:58:09 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 May 2011 21:58:09 +0200 Subject: building 2.12.5 on SLES11 problems In-Reply-To: References: Message-ID: <4DD181D1.8060700@gnutls.org> On 05/16/2011 09:37 PM, Galloway, Michael D. wrote: > > Good day all, > > I'm trying to build 2.12.5 on SLES11 system and getting this build problem from the libgcrypt module: > Making all in gcrypt > make[4]: Entering directory `/usr/local/gnutls-2.12.5/lib/gcrypt' > CC pk.lo > CC mpi.lo > CC mac.lo > CC cipher.lo > CC rnd.lo > CC init.lo > init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a function) > make[4]: *** [init.lo] Error 1 > make[4]: Leaving directory `/usr/local/gnutls-2.12.5/lib/gcrypt' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/local/gnutls-2.12.5/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/local/gnutls-2.12.5/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/gnutls-2.12.5' > make: *** [all] Error 2 Hello, Could you try a newer version of libgcrypt (1.4.4 or so?). As it seems 1.4.1 does not contain that definition. Out of curiosity what is SLES11? regards, Nikos From gallowaymd at ornl.gov Mon May 16 22:35:29 2011 From: gallowaymd at ornl.gov (Galloway, Michael D.) Date: Mon, 16 May 2011 16:35:29 -0400 Subject: building 2.12.5 on SLES11 problems In-Reply-To: <4DD181D1.8060700@gnutls.org> References: <4DD181D1.8060700@gnutls.org> Message-ID: -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Monday, May 16, 2011 3:58 PM To: Galloway, Michael D. Cc: 'help-gnutls at gnu.org' Subject: Re: building 2.12.5 on SLES11 problems On 05/16/2011 09:37 PM, Galloway, Michael D. wrote: > > Good day all, > > I'm trying to build 2.12.5 on SLES11 system and getting this build problem from the libgcrypt module: > Making all in gcrypt > make[4]: Entering directory `/usr/local/gnutls-2.12.5/lib/gcrypt' > CC pk.lo > CC mpi.lo > CC mac.lo > CC cipher.lo > CC rnd.lo > CC init.lo > init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a function) > make[4]: *** [init.lo] Error 1 > make[4]: Leaving directory `/usr/local/gnutls-2.12.5/lib/gcrypt' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory `/usr/local/gnutls-2.12.5/lib' > make[2]: *** [all] Error 2 > make[2]: Leaving directory `/usr/local/gnutls-2.12.5/lib' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/usr/local/gnutls-2.12.5' > make: *** [all] Error 2 Hello, Could you try a newer version of libgcrypt (1.4.4 or so?). As it seems 1.4.1 does not contain that definition. Out of curiosity what is SLES11? regards, Nikos Yup, upgrading to libgcrypt 1.4.6 resolved the problem, make check passed all tests. Thanks! ---- michael From thouraya.andolsi at gmail.com Fri May 20 18:47:27 2011 From: thouraya.andolsi at gmail.com (thouraya andolsi) Date: Fri, 20 May 2011 17:47:27 +0100 Subject: cross compile gnutls1.10.0 Message-ID: Hello, Trying to cross compile gnutls, I had the following error: checking for libgcrypt... no using the --with-libgcrypt-prefix option specifying the path where to find libs and include files in the target, it's trying to link with the host. how can'I use libgcrypt-config file to link against the target libs? Regards, Thouraya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri May 20 23:09:58 2011 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 May 2011 23:09:58 +0200 Subject: cross compile gnutls1.10.0 In-Reply-To: (thouraya andolsi's message of "Fri, 20 May 2011 17:47:27 +0100") References: Message-ID: <87d3jdm63d.fsf@latte.josefsson.org> thouraya andolsi writes: > Hello, > > Trying to cross compile gnutls, I had the following error: checking for > libgcrypt... no > > > using the --with-libgcrypt-prefix option specifying the path where to find > libs and include files in the target, it's trying to link with the host. > > how can'I use libgcrypt-config file to link against the target libs? Which version are you using? What's in your suggest, 1.10.0, sounds really old. /Simon From admin at dash.za.net Mon May 23 04:38:47 2011 From: admin at dash.za.net (Dash Shendy) Date: Mon, 23 May 2011 04:38:47 +0200 Subject: GnuTLS Re-Handshake Fails Message-ID: <4DD9C8B7.5030808@dash.za.net> Machine Spec.: ============================================================ Fedora Core 14 Dual PIII Katmai CPU @500Mhz 1002 MB DIMM PC133 RAM 16 GB SCSI HDD GnuTLS 2.12.5 mod_gnutls 0.5.9 Apache 2.2.18 ============================================================ # gnutls-cli -e -V dash.za.net Resolving 'dash.za.net'... Connecting to '192.168.0.254:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 2048 bits - Secret key: 2046 bits - Peer's public key: 2048 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - X.509 Certificate Information: Version: 3 Serial Number (hex): 07 Issuer: C=ZA,O=Technical Advisory Group,OU=Certificate Authority,CN=TAG Certificate Authority,UID=0 Validity: Not Before: Sun Apr 24 11:07:01 UTC 2011 Not After: Mon Apr 23 11:07:04 UTC 2012 Subject: C=ZA,O=Dash Shendy,OU=Curriculum Vitae,L=Cape Town,ST=WP,CN=dash.za.net,UID=7 Subject Public Key Algorithm: RSA Certificate Security Level: Normal Modulus (bits 2432): 00:c4:fd:51:16:52:62:27:c1:71:3c:06:ee:22:a0:25 fc:d7:73:9e:af:dd:e5:e8:8f:0a:d3:18:93:dd:54:e3 a7:39:9e:87:84:44:f8:cf:12:db:dc:d1:58:de:de:dd 23:15:0e:81:ca:e6:f1:82:1f:ea:f7:31:bf:8a:de:24 33:4c:d2:79:83:9f:9f:1c:25:57:48:33:a6:de:99:b0 b0:b9:44:53:70:ee:bc:1d:0b:de:ee:6d:2a:06:1c:d9 d7:9e:01:04:bd:96:4e:1a:03:07:e8:21:3e:4e:d8:62 83:ea:d8:04:f2:ef:6f:b6:d2:bc:bf:cc:68:19:b5:74 78:82:b3:52:96:9d:e6:ef:f6:6e:c8:77:b4:5a:e9:04 47:55:03:b7:e8:a8:e1:41:a9:58:48:70:40:d6:76:62 10:41:b8:7d:d9:28:24:4b:05:16:1c:4a:0c:b0:37:2c e0:d9:e5:a3:3f:5f:37:a1:30:7b:b3:3d:d0:75:3e:db fa:b8:4c:17:30:62:52:a0:07:0f:4c:4c:ce:bc:2f:52 38:b6:d6:4e:b3:ef:ad:88:9a:41:6c:d4:01:1a:89:a8 d8:a0:a5:c1:98:b6:77:53:6c:c9:24:bd:0f:d2:0e:c4 16:19:ec:73:e8:85:97:88:a7:52:09:53:3b:83:b3:a3 af:42:0a:6c:ce:09:cf:b7:75:51:15:68:9c:1a:11:ea 8c:d4:26:38:e5:53:4d:8c:21:2d:a8:84:90:c7:72:eb 81:dc:69:04:06:9d:1c:94:a2:bd:9c:40:9e:87:44:09 97 Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Purpose (not critical): TLS WWW Server. Key Usage (critical): Digital signature. Key encipherment. Subject Key Identifier (not critical): e3fc11752c6e51303b269e36d283c5aadc33a5cc Authority Key Identifier (not critical): af16d0a14f4cf894f51e7ed33cfa3b369de65223 CRL Distribution points (not critical): URI: tag.za.net/crl Signature Algorithm: RSA-SHA256 Signature: 30:03:1d:ed:05:96:b7:70:71:95:57:b1:d6:98:fc:3a a8:08:a6:be:97:20:dd:38:61:f7:ea:46:2f:4c:92:d3 a2:44:e1:02:6a:6c:15:ff:2a:1f:2e:44:b6:96:5a:61 3d:8f:a9:86:c9:48:4b:ad:6c:d7:1e:88:a8:50:9c:38 0c:6a:96:1f:d9:df:55:cb:92:34:20:d3:52:af:50:f8 96:49:68:16:f7:19:d3:f3:ce:20:fd:7d:4b:6d:0f:88 3f:dc:8d:5d:b4:66:08:bf:41:84:e2:45:e6:7b:fe:08 93:85:62:ed:55:ab:7e:df:ec:95:61:c1:bb:c1:8e:40 9f:d0:63:01:aa:d0:bf:40:c2:5c:5e:49:06:ab:39:c8 1b:b8:fc:07:89:a9:b8:7a:d5:3e:68:9d:99:5f:05:c7 04:c9:44:34:74:51:e7:cb:d3:4f:81:aa:ba:ac:51:39 46:6e:7f:75:e4:09:af:50:e1:0e:42:0f:b6:0d:e0:fe 45:fd:46:b9:3f:0f:ea:e3:5c:35:c6:f6:58:0b:9e:56 b2:95:78:13:63:dc:16:5c:c5:71:d3:86:ad:1d:8e:14 ae:0f:56:54:13:60:c5:c4:f0:29:eb:69:a4:91:4b:79 45:5b:9a:9d:54:8c:26:3c:18:69:b8:2c:01:4d:fa:ec fa:17:5e:fa:c7:0c:de:68:59:33:07:3a:c4:41:80:91 3f:f4:d0:d7:f1:9f:5d:f3:f2:e2:3c:c3:c5:b4:62:0c 66:58:67:21:b3:e0:5d:81:f4:70:b4:f7:b1:6b:27:58 Other Information: MD5 fingerprint: c9b7fe299eda11755b7d398aeed16013 SHA-1 fingerprint: 70c40367368fd39f3b0b0f5fa519f8d2e9bda22d Public Key Id: e3fc11752c6e51303b269e36d283c5aadc33a5cc - The hostname in the certificate matches 'dash.za.net'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Session ID: 6E:34:B9:7E:A3:0A:E0:6E:6D:58:04:02:67:5F:AE:94:12:FA:B7:EC:99:11:64:31:24:B9:77:EB:27:EF:76:93 - Channel binding 'tls-unique': deb8b928402edf74283cdf9c - Handshake was completed - Simple Client Mode: *** Fatal error: A TLS packet with unexpected length was received. *** ReHandshake has failed GnuTLS error: A TLS packet with unexpected length was received. ============================================================ Any Help/Info would be appreciated. Thank you, Hacker Emblem *Dash Shendy* Coder/Pentester Security Analyst/Consultant URL : http://dash.za.net/ SMTP: admin at dash.za.net VOIP: dashula2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2Q== Type: image/gif Size: 6184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 292 bytes Desc: OpenPGP digital signature URL: From thouraya.andolsi at gmail.com Mon May 23 10:45:22 2011 From: thouraya.andolsi at gmail.com (thouraya andolsi) Date: Mon, 23 May 2011 09:45:22 +0100 Subject: cross compile gnutls1.10.0 In-Reply-To: <87d3jdm63d.fsf@latte.josefsson.org> References: <87d3jdm63d.fsf@latte.josefsson.org> Message-ID: Hello, I'm cross compiling gnutls2.10.0. Regards, Thouraya. 2011/5/20 Simon Josefsson > thouraya andolsi writes: > > > Hello, > > > > Trying to cross compile gnutls, I had the following error: checking for > > libgcrypt... no > > > > > > using the --with-libgcrypt-prefix option specifying the path where to > find > > libs and include files in the target, it's trying to link with the host. > > > > how can'I use libgcrypt-config file to link against the target libs? > > Which version are you using? What's in your suggest, 1.10.0, sounds > really old. > > /Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at dash.za.net Mon May 23 04:37:20 2011 From: admin at dash.za.net (Dash Shendy) Date: Mon, 23 May 2011 04:37:20 +0200 Subject: Weird TLS Compression Error Message-ID: <4DD9C860.500@dash.za.net> Please see attached screen-shot. GnuTLS 2.12.5 mod_gnutls 0.5.9 Apache 2.2.18 Hacker Emblem *Dash Shendy* Coder/Pentester Security Analyst/Consultant URL : http://dash.za.net/ SMTP: admin at dash.za.net VOIP: dashula2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2Q== Type: image/gif Size: 6184 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compression_overlap.PNG Type: image/png Size: 53456 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 292 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Mon May 23 17:27:01 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 May 2011 17:27:01 +0200 Subject: Weird TLS Compression Error In-Reply-To: <4DD9C860.500@dash.za.net> References: <4DD9C860.500@dash.za.net> Message-ID: <4DDA7CC5.4070102@gnutls.org> On 05/23/2011 04:37 AM, Dash Shendy wrote: > Please see attached screen-shot. Most probably you have set a priority string to the server that does not include any compression algorithms. If this is not the case then explain what your problem is and what you have done. regards, Nikos From nmav at gnutls.org Mon May 23 17:28:20 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 May 2011 17:28:20 +0200 Subject: GnuTLS Re-Handshake Fails In-Reply-To: <4DD9C8B7.5030808@dash.za.net> References: <4DD9C8B7.5030808@dash.za.net> Message-ID: <4DDA7D14.7020000@gnutls.org> On 05/23/2011 04:38 AM, Dash Shendy wrote: > - Simple Client Mode: > > *** Fatal error: A TLS packet with unexpected length was received. > *** ReHandshake has failed > GnuTLS error: A TLS packet with unexpected length was received. > ============================================================ > Any Help/Info would be appreciated. Also from here. What is the actual problem? What are you trying to do? regards, Nikos From admin at dash.za.net Mon May 23 18:42:05 2011 From: admin at dash.za.net (Dash Shendy) Date: Mon, 23 May 2011 18:42:05 +0200 Subject: GnuTLS Re-Handshake Fails In-Reply-To: References: Message-ID: <4DDA8E5D.5060009@dash.za.net> I was just testing with gnu-cli using the -e flag, in my case the 2nd handshake always fails (seems to result in a Record overflow). Here's some debugging information: $ gnutls-cli -d 11 -V -e dash.za.net Resolving 'dash.za.net'... Connecting to '192.168.0.254:443'... |<4>| REC[0x9381858]: Allocating epoch #0 |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x9381858]: Allocating epoch #1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<2>| EXT[0x9381858]: Sending extension CERT TYPE (3 bytes) |<2>| EXT[0x9381858]: Sending extension SERVER NAME (16 bytes) |<2>| EXT[0x9381858]: Sending extension SAFE RENEGOTIATION (1 bytes) |<2>| EXT[0x9381858]: Sending extension SESSION TICKET (0 bytes) |<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256 |<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256 |<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1 |<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1 |<2>| EXT[0x9381858]: Sending extension SIGNATURE ALGORITHMS (10 bytes) |<3>| HSK[0x9381858]: CLIENT HELLO was sent [143 bytes] |<6>| BUF[HSK]: Inserted 143 bytes of Data |<7>| HWRITE: enqueued 143. Total 143 bytes. |<7>| HWRITE FLUSH: 143 bytes in buffer. |<4>| REC[0x9381858]: Sending Packet[0] Handshake(22) with length: 143 |<7>| WRITE: enqueued 148 bytes for 0x4. Total 148 bytes. |<4>| REC[0x9381858]: Sent Packet[1] Handshake(22) with length: 148 |<7>| HWRITE: wrote 143 bytes, 0 bytes left. |<7>| WRITE FLUSH: 148 bytes in buffer. |<7>| WRITE: wrote 148 bytes, 0 bytes left. |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[0] Handshake(22) with length: 85 |<7>| READ: Got 85 bytes from 0x4 |<7>| READ: read 85 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 85 bytes. |<7>| RB: Requested 90 bytes |<4>| REC[0x9381858]: Decrypted Packet[0] Handshake(22) with length: 85 |<6>| BUF[HSK]: Inserted 85 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[0x9381858]: SERVER HELLO was received [85 bytes] |<6>| BUF[REC][HD]: Read 81 bytes of Data(22) |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 81 bytes of Data |<3>| HSK[0x9381858]: Server's version: 3.2 |<3>| HSK[0x9381858]: SessionID length: 32 |<3>| HSK[0x9381858]: SessionID: 68155d5cdde893492eccac47a3d4bd1edd7baf70e56e969eaf98fc7c79353230 |<3>| HSK[0x9381858]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1 |<2>| EXT[0x9381858]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<2>| EXT[0x9381858]: Parsing extension 'SESSION TICKET/35' (0 bytes) |<3>| HSK[0x9381858]: Safe renegotiation succeeded |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[1] Handshake(22) with length: 1171 |<7>| READ: Got 1171 bytes from 0x4 |<7>| READ: read 1171 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 1171 bytes. |<7>| RB: Requested 1176 bytes |<4>| REC[0x9381858]: Decrypted Packet[1] Handshake(22) with length: 1171 |<6>| BUF[HSK]: Inserted 1171 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[0x9381858]: CERTIFICATE was received [1171 bytes] |<6>| BUF[REC][HD]: Read 1167 bytes of Data(22) |<6>| BUF[HSK]: Peeked 228 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 1167 bytes of Data |<2>| ASSERT: ext_signature.c:386 |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[2] Handshake(22) with length: 829 |<7>| READ: Got 829 bytes from 0x4 |<7>| READ: read 829 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 829 bytes. |<7>| RB: Requested 834 bytes |<4>| REC[0x9381858]: Decrypted Packet[2] Handshake(22) with length: 829 |<6>| BUF[HSK]: Inserted 829 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[0x9381858]: SERVER KEY EXCHANGE was received [829 bytes] |<6>| BUF[REC][HD]: Read 825 bytes of Data(22) |<6>| BUF[HSK]: Peeked 1171 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 825 bytes of Data |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[3] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[3] Handshake(22) with length: 4 |<7>| READ: Got 4 bytes from 0x4 |<7>| READ: read 4 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 4 bytes. |<7>| RB: Requested 9 bytes |<4>| REC[0x9381858]: Decrypted Packet[3] Handshake(22) with length: 4 |<6>| BUF[HSK]: Inserted 4 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[0x9381858]: SERVER HELLO DONE was received [4 bytes] |<2>| ASSERT: gnutls_handshake.c:1368 |<6>| BUF[HSK]: Peeked 829 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<3>| HSK[0x9381858]: CLIENT KEY EXCHANGE was sent [262 bytes] |<6>| BUF[HSK]: Peeked 4 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<7>| HWRITE: enqueued 262. Total 262 bytes. |<7>| HWRITE FLUSH: 262 bytes in buffer. |<4>| REC[0x9381858]: Sending Packet[1] Handshake(22) with length: 262 |<7>| WRITE: enqueued 267 bytes for 0x4. Total 267 bytes. |<4>| REC[0x9381858]: Sent Packet[2] Handshake(22) with length: 267 |<7>| HWRITE: wrote 262 bytes, 0 bytes left. |<7>| WRITE FLUSH: 267 bytes in buffer. |<7>| WRITE: wrote 267 bytes, 0 bytes left. |<3>| REC[0x9381858]: Sent ChangeCipherSpec |<4>| REC[0x9381858]: Sending Packet[2] Change Cipher Spec(20) with length: 1 |<7>| WRITE: enqueued 6 bytes for 0x4. Total 6 bytes. |<7>| WRITE FLUSH: 6 bytes in buffer. |<7>| WRITE: wrote 6 bytes, 0 bytes left. |<4>| REC[0x9381858]: Sent Packet[3] Change Cipher Spec(20) with length: 6 |<9>| INT: PREMASTER SECRET[256]: 5548178270322700eb7f6b0eb3fdc1ff7506526cefc38c4eda3a0caec8d8f5c17233de35097629b6952de4aeaac823ce0978c9373ca12c9ad37c9c341726f93bd62521a33f330e82acb83298674bd425ab8cc634d15957db85db46acb1fa516ee79ddbb0e3bc2b5dd907bc2b729bd6c0494a0e6e2abc4f292e20051c04f5ef7258efb1219a25f5b36a95f6b40a9070382afbc0778cb338a477adf844f6dec1013bf6390add96211cc9aa6348b0cb01b278ba3cb27c1a4122f3f31389f86cf59a3c7226c221a67848c748d55737c61af7b5af07472013504f5a99c109cf77e9eab0c8908292b5de7d82631b78ef750110e55b78f9531c25f044896af6eeb241 |<9>| INT: CLIENT RANDOM[32]: 4dda89d842131c80d7528f0f7d71fd3e8668365f56bdb183b8f1ff18e425c5e5 |<9>| INT: SERVER RANDOM[32]: 4dda89d815dd318cf051de63dd404e95bb1b822f6c7f5cfbc992226d362fa9d6 |<9>| INT: MASTER SECRET: 11f0c744f7759588483dfc1354d3224dba491329f5f2ea60221218f9fc2d95a96fbe2ed9897de125defa4a730dc8d60a |<4>| REC[0x9381858]: Initializing epoch #1 |<9>| INT: KEY BLOCK[104]: 598c4669b59fea02459caa89228da3aa3dca8bfd25489e0e5f4b89a127e1a404 |<9>| INT: CLIENT WRITE KEY [16]: dba23bd53ee772bb199133b0604090cc |<9>| INT: SERVER WRITE KEY [16]: 11762639065158692b78425a70dc906b |<4>| REC[0x9381858]: Epoch #1 ready |<3>| HSK[0x9381858]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Initializing internal [write] cipher sessions |<4>| REC[0x9381858]: Start of epoch cleanup |<4>| REC[0x9381858]: End of epoch cleanup |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<3>| HSK[0x9381858]: recording tls-unique CB (send) |<3>| HSK[0x9381858]: FINISHED was sent [16 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<7>| HWRITE: enqueued 16. Total 16 bytes. |<7>| HWRITE FLUSH: 16 bytes in buffer. |<4>| REC[0x9381858]: Sending Packet[0] Handshake(22) with length: 16 |<7>| WRITE: enqueued 85 bytes for 0x4. Total 85 bytes. |<4>| REC[0x9381858]: Sent Packet[1] Handshake(22) with length: 85 |<7>| HWRITE: wrote 16 bytes, 0 bytes left. |<7>| WRITE FLUSH: 85 bytes in buffer. |<7>| WRITE: wrote 85 bytes, 0 bytes left. |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[4] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[4] Handshake(22) with length: 892 |<7>| READ: Got 892 bytes from 0x4 |<7>| READ: read 892 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 892 bytes. |<7>| RB: Requested 897 bytes |<4>| REC[0x9381858]: Decrypted Packet[4] Handshake(22) with length: 892 |<6>| BUF[HSK]: Inserted 892 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[0x9381858]: NEW SESSION TICKET was received [892 bytes] |<6>| BUF[REC][HD]: Read 888 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 888 bytes of Data |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[5] Change Cipher Spec(20) with length: 1 |<4>| REC[0x9381858]: Received Packet[5] Change Cipher Spec(20) with length: 1 |<7>| READ: Got 1 bytes from 0x4 |<7>| READ: read 1 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. |<7>| RB: Requested 6 bytes |<4>| REC[0x9381858]: ChangeCipherSpec Packet was received |<3>| HSK[0x9381858]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1 |<4>| REC[0x9381858]: Start of epoch cleanup |<4>| REC[0x9381858]: Epoch #0 freed |<4>| REC[0x9381858]: End of epoch cleanup |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[0] Handshake(22) with length: 112 |<7>| READ: Got 112 bytes from 0x4 |<7>| READ: read 112 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 112 bytes. |<7>| RB: Requested 117 bytes |<4>| REC[0x9381858]: Decrypted Packet[0] Handshake(22) with length: 16 |<6>| BUF[HSK]: Inserted 16 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[0x9381858]: FINISHED was received [16 bytes] |<6>| BUF[REC][HD]: Read 12 bytes of Data(22) |<6>| BUF[HSK]: Peeked 892 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 12 bytes of Data |<6>| BUF[HSK]: Cleared Data from buffer |<6>| BUF[HSK]: Cleared Data from buffer |<2>| ASSERT: ext_server_name.c:300 - Ephemeral Diffie-Hellman parameters - Using prime: 2048 bits - Secret key: 2047 bits - Peer's public key: 2045 bits - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: |<2>| ASSERT: dn.c:305 |<2>| ASSERT: dn.c:305 |<2>| ASSERT: common.c:921 |<2>| ASSERT: common.c:921 |<2>| ASSERT: mpi.c:609 |<2>| ASSERT: x509.c:2895 - X.509 Certificate Information: Version: 3 Serial Number (hex): 07 Issuer: C=ZA,O=Technical Advisory Group,OU=Certificate Authority,CN=TAG Certificate Authority,UID=0 Validity: Not Before: Sun Apr 24 11:07:01 UTC 2011 Not After: Mon Apr 23 11:07:04 UTC 2012 Subject: C=ZA,O=Dash Shendy,OU=Curriculum Vitae,L=Cape Town,ST=WP,CN=dash.za.net,UID=7 Subject Public Key Algorithm: RSA Certificate Security Level: Normal Modulus (bits 2432): 00:c4:fd:51:16:52:62:27:c1:71:3c:06:ee:22:a0:25 fc:d7:73:9e:af:dd:e5:e8:8f:0a:d3:18:93:dd:54:e3 a7:39:9e:87:84:44:f8:cf:12:db:dc:d1:58:de:de:dd 23:15:0e:81:ca:e6:f1:82:1f:ea:f7:31:bf:8a:de:24 33:4c:d2:79:83:9f:9f:1c:25:57:48:33:a6:de:99:b0 b0:b9:44:53:70:ee:bc:1d:0b:de:ee:6d:2a:06:1c:d9 d7:9e:01:04:bd:96:4e:1a:03:07:e8:21:3e:4e:d8:62 83:ea:d8:04:f2:ef:6f:b6:d2:bc:bf:cc:68:19:b5:74 78:82:b3:52:96:9d:e6:ef:f6:6e:c8:77:b4:5a:e9:04 47:55:03:b7:e8:a8:e1:41:a9:58:48:70:40:d6:76:62 10:41:b8:7d:d9:28:24:4b:05:16:1c:4a:0c:b0:37:2c e0:d9:e5:a3:3f:5f:37:a1:30:7b:b3:3d:d0:75:3e:db fa:b8:4c:17:30:62:52:a0:07:0f:4c:4c:ce:bc:2f:52 38:b6:d6:4e:b3:ef:ad:88:9a:41:6c:d4:01:1a:89:a8 d8:a0:a5:c1:98:b6:77:53:6c:c9:24:bd:0f:d2:0e:c4 16:19:ec:73:e8:85:97:88:a7:52:09:53:3b:83:b3:a3 af:42:0a:6c:ce:09:cf:b7:75:51:15:68:9c:1a:11:ea 8c:d4:26:38:e5:53:4d:8c:21:2d:a8:84:90:c7:72:eb 81:dc:69:04:06:9d:1c:94:a2:bd:9c:40:9e:87:44:09 97 Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): FALSE Key Purpose (not critical): TLS WWW Server. Key Usage (critical): Digital signature. Key encipherment. Subject Key Identifier (not critical): e3fc11752c6e51303b269e36d283c5aadc33a5cc Authority Key Identifier (not critical): af16d0a14f4cf894f51e7ed33cfa3b369de65223 CRL Distribution points (not critical): URI: tag.za.net/crl Signature Algorithm: RSA-SHA256 Signature: 30:03:1d:ed:05:96:b7:70:71:95:57:b1:d6:98:fc:3a a8:08:a6:be:97:20:dd:38:61:f7:ea:46:2f:4c:92:d3 a2:44:e1:02:6a:6c:15:ff:2a:1f:2e:44:b6:96:5a:61 3d:8f:a9:86:c9:48:4b:ad:6c:d7:1e:88:a8:50:9c:38 0c:6a:96:1f:d9:df:55:cb:92:34:20:d3:52:af:50:f8 96:49:68:16:f7:19:d3:f3:ce:20:fd:7d:4b:6d:0f:88 3f:dc:8d:5d:b4:66:08:bf:41:84:e2:45:e6:7b:fe:08 93:85:62:ed:55:ab:7e:df:ec:95:61:c1:bb:c1:8e:40 9f:d0:63:01:aa:d0:bf:40:c2:5c:5e:49:06:ab:39:c8 1b:b8:fc:07:89:a9:b8:7a:d5:3e:68:9d:99:5f:05:c7 04:c9:44:34:74:51:e7:cb:d3:4f:81:aa:ba:ac:51:39 46:6e:7f:75:e4:09:af:50:e1:0e:42:0f:b6:0d:e0:fe 45:fd:46:b9:3f:0f:ea:e3:5c:35:c6:f6:58:0b:9e:56 b2:95:78:13:63:dc:16:5c:c5:71:d3:86:ad:1d:8e:14 ae:0f:56:54:13:60:c5:c4:f0:29:eb:69:a4:91:4b:79 45:5b:9a:9d:54:8c:26:3c:18:69:b8:2c:01:4d:fa:ec fa:17:5e:fa:c7:0c:de:68:59:33:07:3a:c4:41:80:91 3f:f4:d0:d7:f1:9f:5d:f3:f2:e2:3c:c3:c5:b4:62:0c 66:58:67:21:b3:e0:5d:81:f4:70:b4:f7:b1:6b:27:58 Other Information: MD5 fingerprint: c9b7fe299eda11755b7d398aeed16013 SHA-1 fingerprint: 70c40367368fd39f3b0b0f5fa519f8d2e9bda22d Public Key Id: e3fc11752c6e51303b269e36d283c5aadc33a5cc - The hostname in the certificate matches 'dash.za.net'. |<2>| ASSERT: verify.c:311 |<2>| ASSERT: verify.c:552 - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.1 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Session ID: 59:54:32:2E:AF:50:65:E9:3A:FF:96:7A:AC:A5:20:05:60:70:C9:5A:CA:1C:EF:13:7A:F4:30:13:D1:57:7F:F1 - Channel binding 'tls-unique': 93209a06329df4e7f829c218 - Handshake was completed - Simple Client Mode: |<2>| ASSERT: gnutls_constate.c:695 |<4>| REC[0x9381858]: Allocating epoch #2 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x9381858]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<2>| EXT[0x9381858]: Sending extension CERT TYPE (3 bytes) |<2>| EXT[0x9381858]: Sending extension SERVER NAME (16 bytes) |<2>| EXT[0x9381858]: Sending extension SAFE RENEGOTIATION (13 bytes) |<2>| EXT[0x9381858]: Sending extension SESSION TICKET (0 bytes) |<3>| HSK[0x9381858]: CLIENT HELLO was sent [129 bytes] |<6>| BUF[HSK]: Inserted 129 bytes of Data |<7>| HWRITE: enqueued 129. Total 129 bytes. |<7>| HWRITE FLUSH: 129 bytes in buffer. |<4>| REC[0x9381858]: Sending Packet[1] Handshake(22) with length: 129 |<7>| WRITE: enqueued 261 bytes for 0x4. Total 261 bytes. |<4>| REC[0x9381858]: Sent Packet[2] Handshake(22) with length: 261 |<7>| HWRITE: wrote 129 bytes, 0 bytes left. |<7>| WRITE FLUSH: 261 bytes in buffer. |<7>| WRITE: wrote 261 bytes, 0 bytes left. |<7>| READ: Got 5 bytes from 0x4 |<7>| READ: read 5 bytes from 0x4 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x9381858]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[0x9381858]: Received Packet[1] Alert(21) with length: 192 |<7>| READ: Got 192 bytes from 0x4 |<7>| READ: read 192 bytes from 0x4 |<7>| RB: Have 5 bytes into buffer. Adding 192 bytes. |<7>| RB: Requested 197 bytes |<4>| REC[0x9381858]: Decrypted Packet[1] Alert(21) with length: 2 |<4>| REC[0x9381858]: Alert[1|0] - Close notify - was received |<2>| ASSERT: gnutls_handshake.c:1296 |<2>| ASSERT: gnutls_handshake.c:2761 |<6>| BUF[HSK]: Cleared Data from buffer *** Fatal error: A TLS packet with unexpected length was received. |<4>| REC: Sending Alert[2|22] - Record overflow |<4>| REC[0x9381858]: Sending Packet[2] Alert(21) with length: 2 |<7>| WRITE: enqueued 85 bytes for 0x4. Total 85 bytes. |<7>| WRITE FLUSH: 85 bytes in buffer. |<7>| WRITE: wrote 85 bytes, 0 bytes left. |<4>| REC[0x9381858]: Sent Packet[3] Alert(21) with length: 85 *** ReHandshake has failed GnuTLS error: A TLS packet with unexpected length was received. |<6>| BUF[HSK]: Cleared Data from buffer |<4>| REC[0x9381858]: Epoch #1 freed |<4>| REC[0x9381858]: Epoch #2 freed From nmav at gnutls.org Mon May 23 18:55:54 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 May 2011 18:55:54 +0200 Subject: GnuTLS Re-Handshake Fails In-Reply-To: <4DDA8E5D.5060009@dash.za.net> References: <4DDA8E5D.5060009@dash.za.net> Message-ID: <4DDA919A.1080000@gnutls.org> On 05/23/2011 06:42 PM, Dash Shendy wrote: > I was just testing with gnu-cli using the -e flag, in my case the 2nd > handshake always fails (seems to result in a Record overflow). > Here's some debugging information: I need first to know your setup and what you are trying to do. What is your server and what options do you have? Why do you do rehandshake in the first place? > |<4>| REC[0x9381858]: Decrypted Packet[1] Alert(21) with length: 2 > |<4>| REC[0x9381858]: Alert[1|0] - Close notify - was received The server closed the session for some reason. Your server log might have more information. But don't just post logs, explain what you are doing. regards, Nikos From admin at dash.za.net Mon May 23 19:00:46 2011 From: admin at dash.za.net (Dash Shendy) Date: Mon, 23 May 2011 19:00:46 +0200 Subject: Weird TLS Compression Error Message-ID: <4DDA92BE.3020806@dash.za.net> Here's my Virtual host setup: GnuTLSCache memcache "127.0.0.1" GnuTLSCacheTimeout 600 Listen 192.168.0.254:443 NameVirtualHost 192.168.0.254:443 GnuTLSEnable on GnuTLSPriorities NONE:+VERS-TLS1.1:+VERS-TLS1.0:+VERS-SSL3.0:+COMP-NULL:+SHA1:+MD5:+RSA:+DHE-RSA:+CAMELLIA-128-CBC:+ARCFOUR-128:+AES-128-CBC:+3DES-CBC DocumentRoot /xxx/xxx/xxx/dash.za.net/docroot ServerName dash.za.net:443 GnuTLSCertificateFile /xxx/xxx/xxx/dash.za.net/cert.pem GnuTLSKeyFile /xxx/xxx/xxx/dash.za.net/key.pem LogLevel debug ErrorLog /xxx/xxx/xxx/dash.za.net-ssl_error_log CustomLog /xxx/xxx/xxx/dash.za.net-ssl_access_log combined I have tried with various Priorities to no avail. This started happening after upgrading both GnuTLS (2.12.x) n mod_gnuTLS (was 0.5.5). As far as I understand the error message "no compression overlap" is similar to "no cypher overlap". That is, there's no common encryption/compression algorithm. I have switched off apache's mod_deflate, as well as php's output buffering and zlib.compression which I thought might be causing this. u can actually try this for yourself at either https://dash.za.net/mail or https://scms.za.net/login. I am using self-signed certificates, but I doubt that this could be causing the issue? Thank you so much for your time and help, it is greatly appreciated. P.S. I heard you mention that you are quite busy with GnuTLS development and can not afford the time to maintain mod_gnutls, and unless you find someone to maintain it, this module is unmaintained. I would love to get involved and contribute, please let me know what I can do to help (I do know how to code in C but I do not believe I have the Mathematical background required, and do not want to introduce bugs or weaken the security as it happened with Debian's implementation of OpenSSL a while back, but please do let me know if I can get involved somehow). Regards, Dash Shendy From admin at dash.za.net Mon May 23 19:24:37 2011 From: admin at dash.za.net (Dash Shendy) Date: Mon, 23 May 2011 19:24:37 +0200 Subject: GnuTLS Re-Handshake Fails Message-ID: <4DDA9855.2010503@dash.za.net> I need first to know your setup and what you are trying to do. >>> My Setup is as follows: >>> Fedora Core 14 Dual Katmai PIII 500Mhz CPU 1002MB RAM >>> Apache 2.2.18 Prefork MPM with PHP 5.3.4+suhosin, GnuTLS 2.2.15 using gpgme 1.3.0 & libassuan 2.0.1 & libgcrypt 1.4.6 & libtasn 1-2.9 & lzo 2.05 & libgpg-error 1.10, mod_gnutls 0.5.9 with apr_memcache 0.7.0, >>> LibGnuTLS was compiled thus: ./configure --prefix=/usr --enable-cryptodev --enable-shared --enable-valgrind-tests --enable-dependency-tracking --with-libgcrypt --with-libgcrypt-prefix=/usr/local --without-libnettle-prefix --with-libtasn1-prefix=/usr --with-included-libcfg --with-lzo >>> # ldd /usr/lib/libgnutls.so.26.20.0 linux-gate.so.1 => (0x0013a000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00d3e000) libgcrypt.so.11 => /usr/local/lib/libgcrypt.so.11 (0x0098c000) libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x00dc2000) libz.so.1 => /lib/libz.so.1 (0x007de000) libdl.so.2 => /lib/libdl.so.2 (0x00511000) libpthread.so.0 => /lib/libpthread.so.0 (0x007a8000) libc.so.6 => /lib/libc.so.6 (0x001ed000) /lib/ld-linux.so.2 (0x00944000) >>> mod_gnutls was compiled thus: ./configure --enable-static=no --with-apxs=/usr/local/apache2/bin/apxs --with-libgnutls-prefix=/usr --with-apr-memcache-prefix=/usr --with-apr-memcache-libs=/usr/lib --with-apr-memcache-includes=/usr/include >>> # ldd /usr/local/apache2/modules/mod_gnutls.so linux-gate.so.1 => (0x0080b000) libapr_memcache.so.0 => /usr/lib/libapr_memcache.so.0 (0x00751000) libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00a22000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00ec0000) libpthread.so.0 => /lib/libpthread.so.0 (0x00110000) libc.so.6 => /lib/libc.so.6 (0x0012b000) libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x002b5000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x0081a000) libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x006a4000) libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0x0030a000) liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x00d72000) libexpat.so.1 => /lib/libexpat.so.1 (0x00599000) libdb-4.8.so => /usr/lib/libdb-4.8.so (0x00356000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0x00e8a000) libgcrypt.so.11 => /usr/local/lib/libgcrypt.so.11 (0x004d8000) libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0x002d9000) libz.so.1 => /usr/lib/libz.so.1 (0x002dd000) libdl.so.2 => /lib/libdl.so.2 (0x00e22000) libm.so.6 => /lib/libm.so.6 (0x0054c000) /lib/ld-linux.so.2 (0x00944000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0076b000) libuuid.so.1 => /lib/libuuid.so.1 (0x002f2000) libfreebl3.so => /usr/lib/libfreebl3.so (0x00d8e000) libresolv.so.2 => /lib/libresolv.so.2 (0x00c06000) libssl3.so => /usr/lib/libssl3.so (0x005c1000) libsmime3.so => /usr/lib/libsmime3.so (0x005f7000) libnss3.so => /usr/lib/libnss3.so (0x00c20000) libnssutil3.so => /usr/lib/libnssutil3.so (0x00576000) libplds4.so => /lib/libplds4.so (0x002f7000) libplc4.so => /lib/libplc4.so (0x00591000) libnspr4.so => /lib/libnspr4.so (0x00620000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x0065c000) What is your server and what options do you have? Why do you do rehandshake in the first place? >>> I was just testing the re-handshaking, that's all really, is that the way you test it? do I need an extra flag? The server closed the session for some reason. Your server log might have more information. But don't just post logs, explain what you are doing. >>> I was just testing to see that everything works and I thought I'd let you know about this error, just being a good netizen. >>> My main issue is actually that weird compression error, I've been tearing my hair-out re-compiling my lamp stack trying to fix it:) Regards, Dash -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon May 23 21:44:55 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 May 2011 21:44:55 +0200 Subject: Weird TLS Compression Error In-Reply-To: <4DDA92BE.3020806@dash.za.net> References: <4DDA92BE.3020806@dash.za.net> Message-ID: <4DDAB937.7000709@gnutls.org> On 05/23/2011 07:00 PM, Dash Shendy wrote: > Here's my Virtual host setup: > GnuTLSPriorities > NONE:+VERS-TLS1.1:+VERS-TLS1.0:+VERS-SSL3.0:+COMP-NULL:+SHA1:+MD5:+RSA:+DHE-RSA:+CAMELLIA-128-CBC:+ARCFOUR-128:+AES-128-CBC:+3DES-CBC If you exchange that string for "NORMAL" does it make any difference? (or adding %COMPAT?) > As far as I understand the error message "no compression overlap" is > similar to "no cypher overlap". That is, there's no common > encryption/compression algorithm. TLS can negotiate apart from cipher a compression algorithm. In your case your priority string specifies the COMP-NULL thus there is an option both parties can negotiate (no compression). I don't know why your browser fails. I connected with firefox 3.6 to the site you mentioned and had no issues. Which browser did you try? Could it be buggy? Did you try others? What could help debugging that would be a capture of the handshake with wireshark. > P.S. I heard you mention that you are quite busy with GnuTLS > development and can not afford the time to maintain mod_gnutls, and > unless you find someone to maintain it, this module is unmaintained. > I would love to get involved and contribute, please let me know what > I can do to help (I do know how to code in C but I do not believe I > have the Mathematical background required, and do not want to > introduce bugs or weaken the security as it happened with Debian's > implementation of OpenSSL a while back, but please do let me know if > I can get involved somehow). mod_gnutls doesn't really require a mathematical background, just basic knowledge of cryptography. It is the internals of apache it requires that I had no time into digging into. If you are interested the open issues (some of them have patches to be reviewed) are at: http://issues.outoforder.cc/view_all_bug_page.php and some fixes are sent to the mailing list at: http://lists.outoforder.cc/pipermail/modules/ (last two or three months). It would be nice if you or someone could test them and include them to the main branch. regards, Nikos From nmav at gnutls.org Mon May 23 21:51:24 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 May 2011 21:51:24 +0200 Subject: GnuTLS Re-Handshake Fails In-Reply-To: <4DDA9855.2010503@dash.za.net> References: <4DDA9855.2010503@dash.za.net> Message-ID: <4DDABABC.7090006@gnutls.org> On 05/23/2011 07:24 PM, Dash Shendy wrote: > What is your server and what options do you have? Why do you do > rehandshake in the first place? >>>> I was just testing the re-handshaking, that's all really, is >>>> that the way you test it? do I need an extra flag? > The server closed the session for some reason. Your server log might > have more information. But don't just post logs, explain what you are > doing. >>>> I was just testing to see that everything works and I thought >>>> I'd let you know about this error, just being a good netizen. >>>> My main issue is actually that weird compression error, I've >>>> been tearing my hair-out re-compiling my lamp stack trying to >>>> fix it:) Ok, so did you modify gnutls-cli to perform a rehandshake? Is that the case? HTTPS servers do not really support re-handshake (there is no real reason to), except for when they initiate it. mod_gnutls at least should behave like that. That is because the prominent reason to initiate a rehandshake is to upgrade credentials (i.e. require the client to send his certificate). So what you see is actually mod_gnutls closing your session because you asked for rehandshake. If you request a URL that requires client authentication is would ask for rehandshake by itself. regards, Nikos From chris.osborn at sitelier.com Mon May 23 23:42:26 2011 From: chris.osborn at sitelier.com (Christopher Osborn) Date: Mon, 23 May 2011 17:42:26 -0400 Subject: OpenPGP-related test failures on OS X Message-ID: <81060059-6E18-4F10-8FF2-7F082A62FD4F@sitelier.com> Hi, While trying to build GnuTLS 2.12.5 on OS X 10.6.7, I encountered the following test failures: ./openpgp-auth server handshake Error in the push function. (-53) (after this error output the program hangs) ./openpgpself client: Handshake 0 failed server: Handshake 0 has failed (Error in the push function.) GnuTLS error: A TLS packet with unexpected length was received. Self test `/Users/csosborn/Downloads/gnutls-2.12.5/tests/.libs/openpgpself' finished with 1 errors Self test `/Users/csosborn/Downloads/gnutls-2.12.5/tests/.libs/openpgpself' finished with 1 errors I configured gnutls using --with-libgcrypt (of which I have 1.4.6) but otherwise there are no changes. I tried an identical build on a Debian 5 machine and all tests passed without issue. I haven't had a chance to debug it yet, but if there is anything you would like me to try, let me know. Thanks! From david at wmol.com Tue May 24 00:02:58 2011 From: david at wmol.com (David Hill) Date: Mon, 23 May 2011 18:02:58 -0400 Subject: SSL Handshake errors Message-ID: <20110523220258.GB32112@olive.mindcry.lan> Using the xxxterm browser (webkit/gnutls), I see the following with 2.12.3 and 2.12.5 versions of gnutls in my Apache logs. [Mon May 23 16:02:23 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:24 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:24 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:25 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:25 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:26 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) [Mon May 23 16:02:28 2011] [error] mod_ssl: SSL handshake timed out (client 192.168.1.2, server www.example.com:443) If I disable TLSv1 in my apache config, the error is: [Mon May 23 15:53:42 2011] [error] mod_ssl: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!] (System error follows) [Mon May 23 15:53:42 2011] [error] System: Connection reset by peer (errno: 54) These errors do not show up using Firefox. My apache config is: SSLProtocol -ALL +SSLv3 +TLSv1 SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP I have also tried without TLS. I have also tried with: SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP No change.. just tons of SSL handshake timed out errors. Thoughts? - David From nmav at gnutls.org Tue May 24 08:58:09 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 May 2011 08:58:09 +0200 Subject: SSL Handshake errors In-Reply-To: <20110523220258.GB32112@olive.mindcry.lan> References: <20110523220258.GB32112@olive.mindcry.lan> Message-ID: On Tue, May 24, 2011 at 12:02 AM, David Hill wrote: > Using the xxxterm browser (webkit/gnutls), I see the following with > 2.12.3 and 2.12.5 versions of gnutls in my Apache logs. That's a long shot because you show server logs for a client error. A long shot would be, could it be related with: https://savannah.gnu.org/support/?107660 If it is that it might require some action by the xxxterm author to use gnutls 2.12.x. regards, Nikos From nmav at gnutls.org Tue May 24 08:59:22 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 May 2011 08:59:22 +0200 Subject: OpenPGP-related test failures on OS X In-Reply-To: <81060059-6E18-4F10-8FF2-7F082A62FD4F@sitelier.com> References: <81060059-6E18-4F10-8FF2-7F082A62FD4F@sitelier.com> Message-ID: On Mon, May 23, 2011 at 11:42 PM, Christopher Osborn wrote: > Hi, > While trying to build GnuTLS 2.12.5 on OS X 10.6.7, I encountered the following test failures: [...] > I configured gnutls using --with-libgcrypt (of which I have 1.4.6) but otherwise there are no changes. I tried an identical build on a Debian 5 machine and all tests passed without issue. I haven't had a chance to debug it yet, but if there is anything you would like me to try, let me know. Thanks! Hello, Could you try running the failed tests with -v? regards, Nikos From simon at josefsson.org Tue May 24 15:51:00 2011 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 24 May 2011 15:51:00 +0200 Subject: cross compile gnutls1.10.0 In-Reply-To: (thouraya andolsi's message of "Mon, 23 May 2011 09:45:22 +0100") References: <87d3jdm63d.fsf@latte.josefsson.org> Message-ID: <87pqn89ph7.fsf@latte.josefsson.org> thouraya andolsi writes: > Hello, > > I'm cross compiling gnutls2.10.0. First try with the latest stable version. Then if it doesn't work, show us the commands you are using, and the output from ./configure, and the contents of config.log after that. /Simon > Regards, > Thouraya. > > 2011/5/20 Simon Josefsson > >> thouraya andolsi writes: >> >> > Hello, >> > >> > Trying to cross compile gnutls, I had the following error: checking for >> > libgcrypt... no >> > >> > >> > using the --with-libgcrypt-prefix option specifying the path where to >> find >> > libs and include files in the target, it's trying to link with the host. >> > >> > how can'I use libgcrypt-config file to link against the target libs? >> >> Which version are you using? What's in your suggest, 1.10.0, sounds >> really old. >> >> /Simon >> From mrsam at courier-mta.com Thu May 26 17:56:03 2011 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 26 May 2011 11:56:03 -0400 Subject: gnutls 2.10 won't negotiate TLS 1.2 if priority is set to =?UTF-8?Q?=22SECURE256=22?= Message-ID: I rebuilt a client/server against gnutls 2.10, from 2.8 before. I give "SECURE256:-CTYPE-OPENPGP" to gnutls_priority_set_direct() on both the client and the server side. After updating to 2.10, TLS negotiation fails a GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM. Stumbling my way through the debugger, and stepping through, I see that both sides are going for TLS 1.2. Adding "-VERS-TLS1.2" to the priority string gets everything working. I'm wondering what I'm missing. I was using RSA-SHA1 certs. I regenerated them as RSA-SHA256 certs, that still doesn't work. I generate my own certs, here's how one looks like: X.509 Certificate Information: Version: 3 Serial Number (hex): 01 Issuer: O=libx library,OU=GnuTLS wrapper,CN=example.com Validity: Not Before: Thu May 26 15:51:45 UTC 2011 Not After: Fri Jun 29 15:51:45 UTC 2012 Subject: O=libx library,OU=GnuTLS wrapper,CN=example.com Subject Public Key Algorithm: RSA Modulus (bits 1024): bd:76:c7:26:19:46:5c:a4:99:ed:12:8a:ef:3d:f6:8b 16:26:c7:33:fd:09:b2:05:5a:ae:af:eb:e4:37:39:c6 69:76:5a:aa:ac:6a:5b:3b:8a:02:c4:a8:13:31:e1:f7 e0:fd:34:c8:87:f4:e7:82:ef:f5:52:34:fe:46:14:56 d6:da:4c:43:61:be:50:67:0a:20:c6:ac:eb:ef:2f:32 c6:9a:74:aa:22:cb:75:8e:ce:a3:77:c4:23:f4:71:e8 37:1e:6e:ab:16:43:ad:94:17:34:8d:58:5e:9a:87:23 54:27:41:32:ec:d4:4a:4a:e9:b0:45:8a:81:e7:b9:69 Exponent (bits 24): 01:00:01 Extensions: Basic Constraints (critical): Certificate Authority (CA): TRUE Key Usage (critical): Digital signature. Non repudiation. Key encipherment. Key agreement. Certificate signing. CRL signing. Key Purpose (not critical): TLS WWW Server. Code signing. Email protection. Subject Alternative Name (not critical): DNSname: example.com Subject Key Identifier (not critical): 06b4ea4797850dd103c88f17f291ca5be54f424b Signature Algorithm: RSA-SHA512 Signature: 6b:a8:93:2a:ad:b3:6b:82:fb:d8:7f:fa:24:06:b5:63 c5:0c:bb:23:90:92:59:9b:d7:9c:0c:d4:83:20:76:af fe:18:3e:d1:af:1b:60:d1:b7:ac:0e:85:e8:46:35:8a 74:e3:83:b5:06:d5:6c:82:2c:be:d6:7d:a4:fe:e2:4e 4c:f8:ee:68:fd:a8:55:46:85:48:2e:12:39:d8:e8:6a 66:be:f6:f9:9a:87:bf:98:a5:11:27:24:28:0c:92:ad ea:11:62:7c:d2:74:cf:64:c9:10:b4:60:9c:77:28:86 20:fc:be:90:8f:db:a8:84:06:53:2a:c4:e1:20:17:9c Other Information: MD5 fingerprint: 0a805cfad3c2d7355c2b9496833997ce SHA-1 fingerprint: 9cac002d6bd19cd855d46d89ae46b55d2f4df24a Public Key Id: 06b4ea4797850dd103c88f17f291ca5be54f424b From nmav at gnutls.org Thu May 26 19:05:43 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 May 2011 19:05:43 +0200 Subject: gnutls 2.99.2 Message-ID: <4DDE8867.6050102@gnutls.org> Hello, I've just released gnutls 2.99.2. It's main addition is the experimental support for Elliptic curves (ECDH and ECDSA). The GnuTLS 2.99.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. The changes since the development release are: * Version 2.99.2 (released 2011-05-26) ** libgnutls: Added Elliptic curve support. This is not enabled by default. Requires priority strings: +CURVE-ALL: to add all supported curves +ECDHE-RSA: to add ephemeral ECDHE with an RSA-signed certificate +ECDHE-ECDSA: to add ephemeral ECDHE with an ECDSA-signed certificate +ANON-ECDHE: to add anonymous ECDH ** libgnutls: PKCS #11 URLs conform to the latest draft being http://tools.ietf.org/html/draft-pechanec-pkcs11uri-04. ** certtool: Can now load private keys and public keys from PKCS #11 tokens via URLs. ** libgnutls: Added gnutls_global_set_audit_log_function() that allows to get important auditing information including the corresponding session. That might be useful to block DoS or other attacker from specific IPs. ** libgnutls: gnutls_pkcs11_privkey_import_url() will now correctly read the public key algorithm of the key. ** libgnutls: Added gnutls_certificate_get_issuer() and gnutls_x509_trust_list_get_issuer() to compensate for the missing gnutls_certificate_get_x509_cas(). ** libgnutls: Added gnutls_x509_crq_verify() to allow verification of the self signature in a certificate request. This allows verifying whether the owner of the private key is the generator of the request. ** libgnutls: gnutls_x509_crt_set_crq() implicitly verifies the self signature of the request. ** API and ABI modifications: gnutls_certificate_get_issuer: ADDED gnutls_x509_trust_list_get_issuer: ADDED gnutls_x509_crq_verify: ADDED gnutls_global_set_audit_log_function: ADDED gnutls_ecc_curve_get_name: ADDED gnutls_ecc_curve_get_size: ADDED gnutls_x509_privkey_import_ecc_raw: ADDED gnutls_x509_privkey_export_ecc_raw: ADDED gnutls_global_set_time_function: ADDED GNUTLS_E_ECC_NO_SUPPORTED_CURVES: New error code GNUTLS_E_ECC_UNSUPPORTED_CURVE: New error code GNUTLS_KX_ECDHE_RSA: New key exchange method GNUTLS_KX_ECDHE_ECDSA: New key exchange method GNUTLS_KX_ANON_ECDH: New key exchange method GNUTLS_PK_ECC: New public key algorithm GNUTLS_SIGN_ECDSA_SHA1: New signature algorithm GNUTLS_SIGN_ECDSA_SHA256: New signature algorithm GNUTLS_SIGN_ECDSA_SHA384: New signature algorithm GNUTLS_SIGN_ECDSA_SHA512: New signature algorithm GNUTLS_SIGN_ECDSA_SHA224: New signature algorithm GNUTLS_ECC_CURVE_INVALID: New curve definition GNUTLS_ECC_CURVE_SECP224R1: New curve definition GNUTLS_ECC_CURVE_SECP256R1: New curve definition GNUTLS_ECC_CURVE_SECP384R1: New curve definition GNUTLS_ECC_CURVE_SECP521R1: New curve definition Here are the compressed sources: ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.2.tar.bz2 ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.2.tar.bz2 Here is the OpenPGP signature: ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.2.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.2.tar.bz2.sig regards, Nikos From nmav at gnutls.org Thu May 26 19:13:27 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 May 2011 19:13:27 +0200 Subject: gnutls 2.10 won't negotiate TLS 1.2 if priority is set to "SECURE256" In-Reply-To: References: Message-ID: <4DDE8A37.4080008@gnutls.org> On 05/26/2011 05:56 PM, Sam Varshavchik wrote: > I rebuilt a client/server against gnutls 2.10, from 2.8 before. I > give "SECURE256:-CTYPE-OPENPGP" to gnutls_priority_set_direct() on > both the client and the server side. After updating to 2.10, TLS > negotiation fails a GNUTLS_E_UNSUPPORTED_SIGNATURE_ALGORITHM. Thanks for reporting that. Confirmed. SECURE256 requires SHA-512 but gnutls will not use SHA-512 for its handshake process (only SHA-1 and SHA-256). To work-around that don't use SECURE256. The weakest link in TLS handshake provides security of 96-bits. So by using SECURE256 you are not increasing the security, you are just using bigger keys. regards, Nikos From nmav at gnutls.org Thu May 26 19:14:46 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 May 2011 19:14:46 +0200 Subject: gnutls 2.99.2 In-Reply-To: <4DDE8867.6050102@gnutls.org> References: <4DDE8867.6050102@gnutls.org> Message-ID: <4DDE8A86.1090508@gnutls.org> On 05/26/2011 07:05 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 2.99.2. It's main addition is the > experimental support for Elliptic curves (ECDH and ECDSA). This version also drops support for libgcrypt. regards, Nikos From admin at dash.za.net Sat May 28 07:12:41 2011 From: admin at dash.za.net (Dash Shendy) Date: Sat, 28 May 2011 07:12:41 +0200 Subject: No Compression Overlap Error In-Reply-To: <4DE07F6C.3000500@dash.za.net> References: <4DE07F6C.3000500@dash.za.net> Message-ID: <4DE08449.7040102@dash.za.net> Looking at the RFCs for TLS Compression: FROM RFC3749: http://www.ietf.org/rfc/rfc3749.txt <---SNIP---> 2. Compression Methods TLS [2] includes the following compression method structure in sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6: enum { null(0), (255) } CompressionMethod; which allows for later specification of up to 256 different compression methods. This definition is updated to segregate the range of allowable values into three zones: 1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols. 2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods. 3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use. Additional information describing the role of the IANA in the allocation of compression method identifiers is described in Section 5. In addition, this definition is updated to include assignment of an identifier for the DEFLATE compression method: enum { null(0), DEFLATE(1), (255) } CompressionMethod; <---SNIP---> Wonder why mod_gnutls would send the reserved for private use value of 255? I have tried several priority strings, including +COMP-NULL to no avail:( Any Ideas? Regards, Dash Shendy From nmav at gnutls.org Sat May 28 09:54:41 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 May 2011 09:54:41 +0200 Subject: No Compression Overlap Error In-Reply-To: <4DE08449.7040102@dash.za.net> References: <4DE07F6C.3000500@dash.za.net> <4DE08449.7040102@dash.za.net> Message-ID: <4DE0AA41.7060001@gnutls.org> On 05/28/2011 07:12 AM, Dash Shendy wrote: > Looking at the RFCs for TLS Compression: > Wonder why mod_gnutls would send the reserved for private use value of 255? It shouldn't. How did you see that it sends the 255 value? regards, Nikos From admin at dash.za.net Sat May 28 22:21:21 2011 From: admin at dash.za.net (Dash Shendy) Date: Sat, 28 May 2011 22:21:21 +0200 Subject: No Compression Overlap Error Message-ID: <4DE15941.3080407@dash.za.net> Hi, I get the compression method as 255 in the server hello packet when using IE8. Please have a look at the attached packet-capture. Thanks, Dash Shendy -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown_compression_method.pcap Type: application/octet-stream Size: 2449 bytes Desc: not available URL: From nmav at gnutls.org Sat May 28 23:23:11 2011 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 May 2011 23:23:11 +0200 Subject: No Compression Overlap Error In-Reply-To: <4DE15941.3080407@dash.za.net> References: <4DE15941.3080407@dash.za.net> Message-ID: <4DE167BF.10308@gnutls.org> On 05/28/2011 10:21 PM, Dash Shendy wrote: > Hi, > > I get the compression method as 255 in the server hello packet when > using IE8. > > Please have a look at the attached packet-capture. Nice catch. The problem is on resumed sessions. Does the attached patch fix the issue for you? regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch2.txt URL: From admin at dash.za.net Sun May 29 01:24:07 2011 From: admin at dash.za.net (Dash Shendy) Date: Sun, 29 May 2011 01:24:07 +0200 Subject: No Compression Overlap Error Message-ID: <4DE18417.40408@dash.za.net> Yup! That seems to do the trick:) Thank you very much, am very happy that we have resolved the issue and in so doin' improved GnuTLS (every little bit counts:) Much kudos to Nikos for providing the patch