From nmav at gnutls.org Sun Nov 2 13:35:07 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 02 Nov 2008 14:35:07 +0200 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490A37DA.6090400@digium.com> References: <490A37DA.6090400@digium.com> Message-ID: <490D9E7B.7070507@gnutls.org> Kevin P. Fleming wrote: > I'm fighting the same problem other Subversion users have been the past > few months, with the switch to Subversion on Ubuntu being built against > GNUTLS instead of OpenSSL, users cannot connect to our server. > > I've rebuilt the server's cert with the X509v3 Key Usage set to 'Digital > Signature' and 'Key Encipherment', but that has not solved the problem. > > Can someone please connect to https://origsvn.digium.com and tell me why > GNUTLS won't accept the server's cert? Thanks. Hello, Could you (or some of your users that have problem) please send me the output you get with the gnutls client if you issue a similar command as below[0]. With gnutls-cli from 2.6.x I connected normally[1]. regards, Nikos [0]: ./gnutls-cli origsvn.digium.com -d 2 --x509keyfile key --x509certfile cert (the files cert and key are attached) [1]: $ ./gnutls-cli origsvn.digium.com --x509keyfile key --x509certfile cert Processed 1 client certificates... Processed 1 client X.509 certificates... Resolving 'origsvn.digium.com'... Connecting to '216.207.245.42:443'... - Ephemeral Diffie-Hellman parameters - Using prime: 1032 bits - Secret key: 1023 bits - Peer's public key: 1032 bits - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: # The hostname in the certificate matches 'origsvn.digium.com'. # valid since: Fri Oct 31 16:58:00 EET 2008 # expires at: Wed Nov 4 16:58:00 EET 2015 # fingerprint: 18:0D:03:38:59:B7:EA:86:48:84:E6:E6:98:F5:6A:D6 # Subject's DN: C=US,ST=Alabama,L=Huntsville,O=Digium,OU=Asterisk Development Team,CN=origsvn.digium.com,EMAIL=asteriskteam at digium.com # Issuer's DN: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com - Certificate[1] info: # valid since: Sat Nov 26 01:31:47 EET 2005 # expires at: Tue Nov 24 01:31:47 EET 2015 # fingerprint: 33:1E:53:E8:4E:11:05:C9:DC:27:C3:AC:DD:FF:A9:53 # Subject's DN: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com # Issuer's DN: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.0 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: GET / HTTP/1.0 HTTP/1.1 404 Not Found Date: Sun, 02 Nov 2008 12:23:55 GMT Server: Apache Content-Length: 267 Connection: close Content-Type: text/html; charset=iso-8859-1 404 Not Found

Not Found

The requested URL / was not found on this server.


Apache Server at origsvn.digium.com Port 443
- Peer has closed the GNUTLS connection -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: key URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cert URL: From martin.knappe at gmail.com Mon Nov 3 13:33:11 2008 From: martin.knappe at gmail.com (Martin Knappe) Date: Mon, 3 Nov 2008 13:33:11 +0100 Subject: [Help-gnutls] Diffie Hellman Message-ID: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> hi i have a question i have seen source code where the server makes a call to gnutls_dh_set_prime_bits the way i understand it, this doesnt really make sense: the server suggests these parameters to the client, and the client only uses this function to determine whether the parameters offered by the server are acceptable, right? is there any point in calling gnutls_dh_set_prime_bits on the server side? many thanks martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart at scopeport.org Mon Nov 3 14:02:14 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Mon, 3 Nov 2008 14:02:14 +0100 Subject: [Help-gnutls] Diffie Hellman In-Reply-To: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> References: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> Message-ID: <200811031402.14399.lennart@scopeport.org> On Monday 03 November 2008 13:33:11 Martin Knappe wrote: > is there any point in calling gnutls_dh_set_prime_bits on the server side? > many thanks Yes. On the server side you set the number of DH prime bits the server offers in maximum. You will notice that your GnuTLS initialization process will take longer the higher you set the DH prime bits because generation takes longer. You should regularly re-call gnutls_dh_set_prime_bits for security reasons. So long Lennart Koopmann From lennart at scopeport.org Mon Nov 3 14:26:43 2008 From: lennart at scopeport.org (Lennart Koopmann) Date: Mon, 3 Nov 2008 14:26:43 +0100 Subject: [Help-gnutls] Diffie Hellman In-Reply-To: <1918c28b0811030514k25846d0dn5f35a0b41f7dc443@mail.gmail.com> References: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> <200811031402.14399.lennart@scopeport.org> <1918c28b0811030514k25846d0dn5f35a0b41f7dc443@mail.gmail.com> Message-ID: <200811031426.44089.lennart@scopeport.org> On Monday 03 November 2008 14:14:11 you wrote: > I don't see how all this makes sense: > > The number of DH prime bits is established on a call to > gnutls_dh_params_generate2 (dh_params, DH_BITS); > This is when the prime and generator are generated. That's true. Sorry my reply was quite unspecific about that. But as far as I understand gnutls_dh_params_generate2() generates the pair of prime and generator, while gnutls_dh_set_prime_bits() sets a minimum DH size for a conversation. I did not test it, but this might enable you to allow different DH sizes in different conversations. I am handing over to the GnuTLS experts! ;) From kpfleming at digium.com Mon Nov 3 14:40:36 2008 From: kpfleming at digium.com (Kevin P. Fleming) Date: Mon, 03 Nov 2008 07:40:36 -0600 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490D9E7B.7070507@gnutls.org> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> Message-ID: <490EFF54.80106@digium.com> Nikos Mavrogiannopoulos wrote: > Could you (or some of your users that have problem) please send me the > output you get with the gnutls client if you issue a similar command as > below[0]. With gnutls-cli from 2.6.x I connected normally[1]. OK, this is bizarre. Using gnutls-cli from Ubuntu's gnutls-bin 2.4.1-1build1 (which uses libgnutls.so.26 from libgnutls-2.4.1-1build1 (strange version numbering)), the connection works fine; the output is the same as you posted. Does this mean that the real problem is that something in the way libneon is using GNUTLS is really causing the issue, or that gnutls-cli is not requiring the same validity checks that libneon is asking for? -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) From nmav at gnutls.org Mon Nov 3 16:46:19 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 3 Nov 2008 17:46:19 +0200 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490EFF54.80106@digium.com> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> Message-ID: >> Could you (or some of your users that have problem) please send me the >> output you get with the gnutls client if you issue a similar command as >> below[0]. With gnutls-cli from 2.6.x I connected normally[1]. > > OK, this is bizarre. Using gnutls-cli from Ubuntu's gnutls-bin > 2.4.1-1build1 (which uses libgnutls.so.26 from libgnutls-2.4.1-1build1 > (strange version numbering)), the connection works fine; the output is > the same as you posted. > > Does this mean that the real problem is that something in the way > libneon is using GNUTLS is really causing the issue, or that gnutls-cli > is not requiring the same validity checks that libneon is asking for? I don't think this can be the case, but cannot be sure. Does libneon can be run with gnutls debugging on? regards, Nikos From martin.knappe at gmail.com Mon Nov 3 16:48:41 2008 From: martin.knappe at gmail.com (Martin Knappe) Date: Mon, 3 Nov 2008 16:48:41 +0100 Subject: [Help-gnutls] Diffie Hellman In-Reply-To: <200811031426.44089.lennart@scopeport.org> References: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> <200811031402.14399.lennart@scopeport.org> <1918c28b0811030514k25846d0dn5f35a0b41f7dc443@mail.gmail.com> <200811031426.44089.lennart@scopeport.org> Message-ID: <1918c28b0811030748j225b4a90w202c8053b7f53f1f@mail.gmail.com> Yeah, you see that explanation doesnt really make sense. The parameters are generated when gnutls_dh_params_generate2 is called, and this function also has a DH_BITS, so I don't see the point in specifying the parameter width again in a separate function. On Mon, Nov 3, 2008 at 2:26 PM, Lennart Koopmann wrote: > On Monday 03 November 2008 14:14:11 you wrote: > > I don't see how all this makes sense: > > > > The number of DH prime bits is established on a call to > > gnutls_dh_params_generate2 (dh_params, DH_BITS); > > This is when the prime and generator are generated. > > That's true. Sorry my reply was quite unspecific about that. > But as far as I understand gnutls_dh_params_generate2() generates the pair > of > prime and generator, while gnutls_dh_set_prime_bits() sets a minimum DH > size > for a conversation. I did not test it, but this might enable you to allow > different DH sizes in different conversations. > > I am handing over to the GnuTLS experts! ;) > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.knappe at gmail.com Mon Nov 3 17:39:26 2008 From: martin.knappe at gmail.com (Martin Knappe) Date: Mon, 3 Nov 2008 17:39:26 +0100 Subject: [Help-gnutls] handshake Message-ID: <1918c28b0811030839j528a6381w32e466f68bae0498@mail.gmail.com> hi im having a problem with making a handshake between client and server the problem is that my client seems to "think" it is really a server, because instead of sending a client hello. it does a receive when initiating the handshake (i checked with strace) could someone have a look at this snippet and tell me why this client might think it is a server: if (gnutls_init(&session, GNUTLS_CLIENT) != 0) { return E_GNUTLS_INIT; } if (gnutls_set_default_priority(session) != 0) { return E_GNUTLS_SET_DEFAULT_PRIORITY; } if (gnutls_kx_set_priority(session, (const int[]) {GNUTLS_KX_DHE_PSK, 0})) { return E_GNUTLS_KX_SET_PRIORITY; } if (gnutls_credentials_set (session, GNUTLS_CRD_PSK, psk_cred) != 0) { return E_GNUTLS_CREDENTIALS_SET; } gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t) sockfd); printf("BEFORE HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n"); if (gnutls_handshake(session) < 0) { return E_HANDSHAKE; } printf("AFTER HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n"); return E_SUCCESS; when i execute this, I get the message "BEFORE HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!", and then my client blocks! many thanks martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpfleming at digium.com Mon Nov 3 18:58:21 2008 From: kpfleming at digium.com (Kevin P. Fleming) Date: Mon, 03 Nov 2008 11:58:21 -0600 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> Message-ID: <490F3BBD.5060603@digium.com> Nikos Mavrogiannopoulos wrote: > I don't think this can be the case, but cannot be sure. Does libneon > can be run with gnutls debugging on? Thanks very much for your help! I've built Subversion 1.5.4 with libneon 0.28.2 (both from source, but gnutls using the Ubuntu packages) configured to force the gnutls global debug level to 4711, and here's the output from a failed connection attempt: |<2>| ASSERT: dn.c:444 |<2>| ASSERT: dn.c:374 |<2>| ASSERT: dn.c:492 ah_create, for WWW-Authenticate Running pre_send hooks compress: Initialization. Sending request headers: OPTIONS /svn/asterisk HTTP/1.1 Host: origsvn.digium.com User-Agent: SVN/1.5.4 (r33841) neon/0.28.2 Keep-Alive: Connection: TE, Keep-Alive TE: trailers DAV: http://subversion.tigris.org/xmlns/dav/svn/depth DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops Accept-Encoding: gzip Sending request-line and headers: Doing DNS lookup on origsvn.digium.com... Connecting to 10.19.29.201 Negotiating SSL connection. |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[11ea380]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[11ea380]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[11ea380]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<2>| EXT[11ea380]: Sending extension CERT_TYPE |<2>| EXT[11ea380]: Sending extension SERVER_NAME |<3>| HSK[11ea380]: CLIENT HELLO was send [115 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[11ea380]: Sending Packet[0] Handshake(22) with length: 115 |<2>| ASSERT: gnutls_cipher.c:205 |<7>| WRITE: Will write 120 bytes to 5. |<7>| WRITE: wrote 120 bytes to 5. Left 0 bytes. Total 120 bytes. |<7>| 0000 - 16 03 02 00 73 01 00 00 6f 03 02 49 0f 3b 13 28 |<7>| 0001 - 48 2f 40 67 f3 dd 20 4e f9 bc 5b 85 87 43 27 79 |<7>| 0002 - fa 20 6a 58 a3 26 4c 29 38 aa 78 00 00 24 00 33 |<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87 |<7>| 0004 - 00 13 00 66 00 2f 00 41 00 35 00 84 00 0a 00 05 |<7>| 0005 - 00 04 01 00 00 22 00 09 00 03 02 00 01 00 00 00 |<7>| 0006 - 17 00 15 00 00 12 6f 72 69 67 73 76 6e 2e 64 69 |<7>| 0007 - 67 69 75 6d 2e 63 6f 6d |<4>| REC[11ea380]: Sent Packet[1] Handshake(22) with length: 120 |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 4a |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[11ea380]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[11ea380]: Received Packet[0] Handshake(22) with length: 74 |<7>| READ: Got 74 bytes from 5 |<7>| READ: read 74 bytes from 5 |<7>| 0000 - 02 00 00 46 03 01 49 0f 3b 18 a0 df 9f e4 70 f5 |<7>| 0001 - 46 1e f4 06 7f 04 15 3f 7e a6 ab 55 8c d6 0b fc |<7>| 0002 - 8c 37 24 8d 79 a1 20 25 44 5d 3e 03 f2 4b 38 e1 |<7>| 0003 - 5a c7 1e ba 1c 63 4c 93 ef 1c 9d b7 04 23 cd 5b |<7>| 0004 - 59 d1 58 70 ea 65 6c 00 33 00 |<7>| RB: Have 5 bytes into buffer. Adding 74 bytes. |<7>| RB: Requested 79 bytes |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[11ea380]: Decrypted Packet[0] Handshake(22) with length: 74 |<6>| BUF[HSK]: Inserted 74 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[11ea380]: SERVER HELLO was received [74 bytes] |<6>| BUF[REC][HD]: Read 70 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 70 bytes of Data |<3>| HSK[11ea380]: Server's version: 3.1 |<3>| HSK[11ea380]: SessionID length: 32 |<3>| HSK[11ea380]: SessionID: 25445d3e03f24b38e15ac71eba1c634c93ef1c9db70423cd5b59d15870ea656c |<3>| HSK[11ea380]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1 |<2>| ASSERT: gnutls_extensions.c:165 |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 0b 1e |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[11ea380]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[11ea380]: Received Packet[1] Handshake(22) with length: 2846 |<7>| READ: Got 2846 bytes from 5 |<7>| READ: read 2846 bytes from 5 |<7>| 0000 - 0b 00 0b 1a 00 0b 17 00 05 8e 30 82 05 8a 30 82 |<7>| 0001 - 04 72 a0 03 02 01 02 02 02 00 fe 30 0d 06 09 2a |<7>| 0002 - 86 48 86 f7 0d 01 01 04 05 00 30 81 af 31 0b 30 |<7>| 0003 - 09 06 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 |<7>| 0004 - 55 04 08 13 07 41 6c 61 62 61 6d 61 31 13 30 11 |<7>| 0005 - 06 03 55 04 07 13 0a 48 75 6e 74 73 76 69 6c 6c |<7>| 0006 - 65 31 15 30 13 06 03 55 04 0a 13 0c 44 69 67 69 |<7>| 0007 - 75 6d 2c 20 49 6e 63 2e 31 22 30 20 06 03 55 04 |<7>| 0008 - 0b 13 19 41 73 74 65 72 69 73 6b 20 44 65 76 65 |<7>| 0009 - 6c 6f 70 6d 65 6e 74 20 54 65 61 6d 31 16 30 14 |<7>| 000a - 06 03 55 04 03 13 0d 44 69 67 69 75 6d 20 53 56 |<7>| 000b - 4e 20 43 41 31 26 30 24 06 09 2a 86 48 86 f7 0d |<7>| 000c - 01 09 01 16 17 61 73 74 65 72 69 73 6b 74 65 61 |<7>| 000d - 6d 40 64 69 67 69 75 6d 2e 63 6f 6d 30 1e 17 0d |<7>| 000e - 30 38 31 30 33 31 31 34 35 38 30 30 5a 17 0d 31 |<7>| 000f - 35 31 31 30 34 31 34 35 38 30 30 5a 30 81 ae 31 |<7>| 0010 - 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 0e |<7>| 0011 - 06 03 55 04 08 13 07 41 6c 61 62 61 6d 61 31 13 |<7>| 0012 - 30 11 06 03 55 04 07 13 0a 48 75 6e 74 73 76 69 |<7>| 0013 - 6c 6c 65 31 0f 30 0d 06 03 55 04 0a 13 06 44 69 |<7>| 0014 - 67 69 75 6d 31 22 30 20 06 03 55 04 0b 13 19 41 |<7>| 0015 - 73 74 65 72 69 73 6b 20 44 65 76 65 6c 6f 70 6d |<7>| 0016 - 65 6e 74 20 54 65 61 6d 31 1b 30 19 06 03 55 04 |<7>| 0017 - 03 13 12 6f 72 69 67 73 76 6e 2e 64 69 67 69 75 |<7>| 0018 - 6d 2e 63 6f 6d 31 26 30 24 06 09 2a 86 48 86 f7 |<7>| 0019 - 0d 01 09 01 16 17 61 73 74 65 72 69 73 6b 74 65 |<7>| 001a - 61 6d 40 64 69 67 69 75 6d 2e 63 6f 6d 30 82 01 |<7>| 001b - 22 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 |<7>| 001c - 03 82 01 0f 00 30 82 01 0a 02 82 01 01 00 c4 2a |<7>| 001d - 9a 2d a4 3e 36 91 ba 99 b8 22 6a 7d 0a 10 fd 6b |<7>| 001e - dd 7c 86 00 53 56 b0 e0 de 5d 14 68 b5 b6 ee 09 |<7>| 001f - 13 e6 14 b0 12 b4 f8 5f b5 6d 70 1d 55 82 bd 0e |<7>| 0020 - 46 01 d2 03 2c 94 67 a8 a1 4a d2 3a 5d 5c d2 8a |<7>| 0021 - 1f f6 f9 bd 9a ec 50 cd f8 13 e1 4e b3 87 91 bc |<7>| 0022 - 6c 47 6d 59 0e b0 7d 89 5c 12 ac 3a fb cb 4f c1 |<7>| 0023 - 43 9e a3 b7 4c e4 60 88 f7 4f 7d c7 6a 01 36 03 |<7>| 0024 - 50 e9 ad 6e b7 1a 32 dc 70 54 d0 65 8d 0b d9 77 |<7>| 0025 - c4 5a 5b 2d 85 b9 9b 21 17 e4 13 d8 a3 ea 58 ce |<7>| 0026 - 78 27 ff 78 22 07 5f a5 96 79 fb 3e 7d ed c0 b7 |<7>| 0027 - 2d c8 85 28 c7 03 b6 85 59 f2 4e 24 0d 69 d0 60 |<7>| 0028 - ea 77 68 73 de 69 91 c8 f0 9a eb 21 d2 5f 29 a6 |<7>| 0029 - 40 73 ef 8b 09 5f 5e 32 dd bd 9f ba 98 4c 11 72 |<7>| 002a - 5d 20 1b 37 dc cd 3c d2 63 11 bb bd ce 4a d2 ab |<7>| 002b - b9 1f 41 c2 eb 0e 1a 2e a1 0f 3e 4a ad 1d 68 8f |<7>| 002c - 94 1b 18 8c 49 66 31 65 0c 63 8d 40 7f 83 02 03 |<7>| 002d - 01 00 01 a3 82 01 ad 30 82 01 a9 30 09 06 03 55 |<7>| 002e - 1d 13 04 02 30 00 30 11 06 09 60 86 48 01 86 f8 |<7>| 002f - 42 01 01 04 04 03 02 06 40 30 2b 06 09 60 86 48 |<7>| 0030 - 01 86 f8 42 01 0d 04 1e 16 1c 54 69 6e 79 43 41 |<7>| 0031 - 20 47 65 6e 65 72 61 74 65 64 20 43 65 72 74 69 |<7>| 0032 - 66 69 63 61 74 65 30 1d 06 03 55 1d 0e 04 16 04 |<7>| 0033 - 14 cb 95 0f de 61 ca a3 08 95 bc 6c 6a 9e d7 bf |<7>| 0034 - ae 64 bd c8 cd 30 81 e4 06 03 55 1d 23 04 81 dc |<7>| 0035 - 30 81 d9 80 14 50 d3 ee fd 08 95 06 26 16 49 04 |<7>| 0036 - 90 bf 35 02 11 30 92 bd 27 a1 81 b5 a4 81 b2 30 |<7>| 0037 - 81 af 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 |<7>| 0038 - 10 30 0e 06 03 55 04 08 13 07 41 6c 61 62 61 6d |<7>| 0039 - 61 31 13 30 11 06 03 55 04 07 13 0a 48 75 6e 74 |<7>| 003a - 73 76 69 6c 6c 65 31 15 30 13 06 03 55 04 0a 13 |<7>| 003b - 0c 44 69 67 69 75 6d 2c 20 49 6e 63 2e 31 22 30 |<7>| 003c - 20 06 03 55 04 0b 13 19 41 73 74 65 72 69 73 6b |<7>| 003d - 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 54 65 61 |<7>| 003e - 6d 31 16 30 14 06 03 55 04 03 13 0d 44 69 67 69 |<7>| 003f - 75 6d 20 53 56 4e 20 43 41 31 26 30 24 06 09 2a |<7>| 0040 - 86 48 86 f7 0d 01 09 01 16 17 61 73 74 65 72 69 |<7>| 0041 - 73 6b 74 65 61 6d 40 64 69 67 69 75 6d 2e 63 6f |<7>| 0042 - 6d 82 09 00 c5 45 59 56 d9 a7 ac 12 30 22 06 03 |<7>| 0043 - 55 1d 12 04 1b 30 19 81 17 61 73 74 65 72 69 73 |<7>| 0044 - 6b 74 65 61 6d 40 64 69 67 69 75 6d 2e 63 6f 6d |<7>| 0045 - 30 22 06 03 55 1d 11 04 1b 30 19 81 17 61 73 74 |<7>| 0046 - 65 72 69 73 6b 74 65 61 6d 40 64 69 67 69 75 6d |<7>| 0047 - 2e 63 6f 6d 30 0e 06 03 55 1d 0f 01 01 ff 04 04 |<7>| 0048 - 03 02 05 a0 30 0d 06 09 2a 86 48 86 f7 0d 01 01 |<7>| 0049 - 04 05 00 03 82 01 01 00 d7 ad d4 0c ed 93 74 af |<7>| 004a - 9b b1 3e 3b ae 7f a7 32 9e f6 fc c3 6a ef 6a 71 |<7>| 004b - 16 bd 37 4e 24 f4 b5 46 ec 0c f5 eb 6f 8e b5 b5 |<7>| 004c - a4 ae 94 50 c5 f2 06 3d 26 06 6c fb 8a dc 67 16 |<7>| 004d - 67 c6 0c 72 b3 7b 72 04 e4 f9 0c 37 e0 4b 1c 53 |<7>| 004e - ea c6 01 52 9d 13 f5 ca 98 a4 da 93 ea b0 a9 21 |<7>| 004f - c6 32 7f 19 35 61 b9 db 74 b5 49 00 27 3e 40 37 |<7>| 0050 - e3 ec 20 b0 75 08 a0 f5 9e 8e ac 69 31 7c 0d 45 |<7>| 0051 - 17 3b f4 77 81 f6 d5 b8 80 0a cf ec 66 b6 16 89 |<7>| 0052 - 01 b3 2b 02 e7 1b 0b 88 de bc b2 77 76 4d 7e 4c |<7>| 0053 - 72 75 d4 18 c7 f7 20 7e 92 97 25 33 90 85 c7 ad |<7>| 0054 - e0 94 16 b6 27 4a d5 1b 37 e3 44 d0 6a 9a fa 1d |<7>| 0055 - 54 87 d7 c6 81 d9 1d 38 e0 c2 69 03 38 99 d6 ae |<7>| 0056 - 7f 68 59 9d aa 18 22 de 62 81 17 f0 1e 31 c1 af |<7>| 0057 - d5 8b e0 23 95 0c fd 06 9b 8f 55 79 93 f8 d3 69 |<7>| 0058 - 06 15 42 02 ef ff 13 cb 31 f0 c0 3d e7 2f 03 f0 |<7>| 0059 - db 18 25 5c fe ad 21 94 00 05 83 30 82 05 7f 30 |<7>| 005a - 82 04 67 a0 03 02 01 02 02 09 00 c5 45 59 56 d9 |<7>| 005b - a7 ac 12 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 |<7>| 005c - 05 00 30 81 af 31 0b 30 09 06 03 55 04 06 13 02 |<7>| 005d - 55 53 31 10 30 0e 06 03 55 04 08 13 07 41 6c 61 |<7>| 005e - 62 61 6d 61 31 13 30 11 06 03 55 04 07 13 0a 48 |<7>| 005f - 75 6e 74 73 76 69 6c 6c 65 31 15 30 13 06 03 55 |<7>| 0060 - 04 0a 13 0c 44 69 67 69 75 6d 2c 20 49 6e 63 2e |<7>| 0061 - 31 22 30 20 06 03 55 04 0b 13 19 41 73 74 65 72 |<7>| 0062 - 69 73 6b 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 |<7>| 0063 - 54 65 61 6d 31 16 30 14 06 03 55 04 03 13 0d 44 |<7>| 0064 - 69 67 69 75 6d 20 53 56 4e 20 43 41 31 26 30 24 |<7>| 0065 - 06 09 2a 86 48 86 f7 0d 01 09 01 16 17 61 73 74 |<7>| 0066 - 65 72 69 73 6b 74 65 61 6d 40 64 69 67 69 75 6d |<7>| 0067 - 2e 63 6f 6d 30 1e 17 0d 30 35 31 31 32 35 32 33 |<7>| 0068 - 33 31 34 37 5a 17 0d 31 35 31 31 32 33 32 33 33 |<7>| 0069 - 31 34 37 5a 30 81 af 31 0b 30 09 06 03 55 04 06 |<7>| 006a - 13 02 55 53 31 10 30 0e 06 03 55 04 08 13 07 41 |<7>| 006b - 6c 61 62 61 6d 61 31 13 30 11 06 03 55 04 07 13 |<7>| 006c - 0a 48 75 6e 74 73 76 69 6c 6c 65 31 15 30 13 06 |<7>| 006d - 03 55 04 0a 13 0c 44 69 67 69 75 6d 2c 20 49 6e |<7>| 006e - 63 2e 31 22 30 20 06 03 55 04 0b 13 19 41 73 74 |<7>| 006f - 65 72 69 73 6b 20 44 65 76 65 6c 6f 70 6d 65 6e |<7>| 0070 - 74 20 54 65 61 6d 31 16 30 14 06 03 55 04 03 13 |<7>| 0071 - 0d 44 69 67 69 75 6d 20 53 56 4e 20 43 41 31 26 |<7>| 0072 - 30 24 06 09 2a 86 48 86 f7 0d 01 09 01 16 17 61 |<7>| 0073 - 73 74 65 72 69 73 6b 74 65 61 6d 40 64 69 67 69 |<7>| 0074 - 75 6d 2e 63 6f 6d 30 82 01 22 30 0d 06 09 2a 86 |<7>| 0075 - 48 86 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 |<7>| 0076 - 01 0a 02 82 01 01 00 e1 98 dd 86 39 24 bf 1a f6 |<7>| 0077 - 2b d4 c3 e4 c4 26 69 e8 2c da bc 11 38 03 66 8a |<7>| 0078 - e6 3c 37 2d 1c 4a a7 4b 4f 4a 72 3e e0 80 08 f1 |<7>| 0079 - c2 17 9a b5 d5 f1 a6 d8 64 f3 cc d1 1b 04 cb b0 |<7>| 007a - 7d 75 87 52 9a 7a ea ab f2 64 f1 0e d4 95 fa 60 |<7>| 007b - a5 1e fa d6 5d 8a 55 a8 38 98 4d a7 04 29 4c ad |<7>| 007c - 2d 21 27 d5 87 b6 88 93 e2 fc 15 82 6e b5 cc 7c |<7>| 007d - 45 a5 88 0c 5d 71 29 f2 9d 95 ea 9c ff 01 55 7b |<7>| 007e - c7 de 8d 79 24 49 00 02 69 a9 ac fa 39 e5 37 5d |<7>| 007f - 49 f1 40 a7 62 c0 9e a2 21 d9 c5 21 a2 a9 83 99 |<7>| 0080 - 65 82 8e 73 61 89 8c 1d 18 2f 38 29 63 19 20 6a |<7>| 0081 - 42 a3 22 4c 08 73 8a 56 fd 0d a8 a7 10 e8 ba e9 |<7>| 0082 - eb 90 ae 48 10 63 5a 33 13 bd 22 b8 50 a6 0d 18 |<7>| 0083 - 4b d1 81 d2 60 27 7d 38 c6 f2 b5 2e ce ef 5a e1 |<7>| 0084 - 86 33 ce 0d df 80 e9 b7 84 f3 f6 d1 cf e1 b8 aa |<7>| 0085 - ad 9f 23 eb 04 58 0f c6 68 5f 3b e5 f1 7c 9b 2c |<7>| 0086 - 63 bb 8b fa fd d5 25 02 03 01 00 01 a3 82 01 9a |<7>| 0087 - 30 82 01 96 30 1d 06 03 55 1d 0e 04 16 04 14 50 |<7>| 0088 - d3 ee fd 08 95 06 26 16 49 04 90 bf 35 02 11 30 |<7>| 0089 - 92 bd 27 30 81 e4 06 03 55 1d 23 04 81 dc 30 81 |<7>| 008a - d9 80 14 50 d3 ee fd 08 95 06 26 16 49 04 90 bf |<7>| 008b - 35 02 11 30 92 bd 27 a1 81 b5 a4 81 b2 30 81 af |<7>| 008c - 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 |<7>| 008d - 0e 06 03 55 04 08 13 07 41 6c 61 62 61 6d 61 31 |<7>| 008e - 13 30 11 06 03 55 04 07 13 0a 48 75 6e 74 73 76 |<7>| 008f - 69 6c 6c 65 31 15 30 13 06 03 55 04 0a 13 0c 44 |<7>| 0090 - 69 67 69 75 6d 2c 20 49 6e 63 2e 31 22 30 20 06 |<7>| 0091 - 03 55 04 0b 13 19 41 73 74 65 72 69 73 6b 20 44 |<7>| 0092 - 65 76 65 6c 6f 70 6d 65 6e 74 20 54 65 61 6d 31 |<7>| 0093 - 16 30 14 06 03 55 04 03 13 0d 44 69 67 69 75 6d |<7>| 0094 - 20 53 56 4e 20 43 41 31 26 30 24 06 09 2a 86 48 |<7>| 0095 - 86 f7 0d 01 09 01 16 17 61 73 74 65 72 69 73 6b |<7>| 0096 - 74 65 61 6d 40 64 69 67 69 75 6d 2e 63 6f 6d 82 |<7>| 0097 - 09 00 c5 45 59 56 d9 a7 ac 12 30 0f 06 03 55 1d |<7>| 0098 - 13 01 01 ff 04 05 30 03 01 01 ff 30 11 06 09 60 |<7>| 0099 - 86 48 01 86 f8 42 01 01 04 04 03 02 01 06 30 09 |<7>| 009a - 06 03 55 1d 12 04 02 30 00 30 2b 06 09 60 86 48 |<7>| 009b - 01 86 f8 42 01 0d 04 1e 16 1c 54 69 6e 79 43 41 |<7>| 009c - 20 47 65 6e 65 72 61 74 65 64 20 43 65 72 74 69 |<7>| 009d - 66 69 63 61 74 65 30 22 06 03 55 1d 11 04 1b 30 |<7>| 009e - 19 81 17 61 73 74 65 72 69 73 6b 74 65 61 6d 40 |<7>| 009f - 64 69 67 69 75 6d 2e 63 6f 6d 30 0e 06 03 55 1d |<7>| 00a0 - 0f 01 01 ff 04 04 03 02 01 06 30 0d 06 09 2a 86 |<7>| 00a1 - 48 86 f7 0d 01 01 04 05 00 03 82 01 01 00 59 1f |<7>| 00a2 - 70 32 9d c6 b4 2d 27 02 66 38 d8 66 c3 e6 5e be |<7>| 00a3 - ef bd 24 3c c3 b9 05 76 ed f6 3c 0b 64 da 6b cd |<7>| 00a4 - ff 0e 8a be 26 68 4d 89 ff 33 ce 08 e9 1f 42 80 |<7>| 00a5 - 05 cf d0 f6 33 a4 82 99 c0 f0 45 7f ba 96 e6 f5 |<7>| 00a6 - ae f3 d1 e9 bb 75 8b 69 2a 32 b2 44 0f f5 0d fb |<7>| 00a7 - b3 f7 5f e8 50 1e 1f db dd f4 06 43 71 cc 1f 57 |<7>| 00a8 - dd 5a e3 4c 0e a0 76 79 0a 93 bc 42 aa f5 b0 bc |<7>| 00a9 - 59 e2 f0 63 8f 03 9e 51 97 d6 21 90 14 e4 96 c1 |<7>| 00aa - d6 d7 9a 61 76 f3 7c 48 ee 3b 57 23 cb cd 76 fb |<7>| 00ab - dc 84 11 99 c7 fe 4c 36 6e 10 27 3c 38 39 b9 32 |<7>| 00ac - fc f3 75 b8 d8 72 7c c2 4b 85 3f e8 a0 dc 02 bb |<7>| 00ad - a0 81 90 d7 82 0a c7 e1 5d a1 99 9e 87 16 28 50 |<7>| 00ae - 5e 47 32 34 c6 9d 2b 1a 06 74 89 61 97 99 7b 86 |<7>| 00af - 68 a3 ef 1f 3a 58 c6 69 2a 89 75 ff 82 75 52 d6 |<7>| 00b0 - f6 9d d5 0a 42 2d 65 5d a4 39 d6 4c da bd 76 6f |<7>| 00b1 - af 9d c3 2b 72 80 c3 68 79 c6 4e 0b 4b 6a |<7>| RB: Have 5 bytes into buffer. Adding 2846 bytes. |<7>| RB: Requested 2851 bytes |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[11ea380]: Decrypted Packet[1] Handshake(22) with length: 2846 |<6>| BUF[HSK]: Inserted 2846 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[11ea380]: CERTIFICATE was received [2846 bytes] |<6>| BUF[REC][HD]: Read 2842 bytes of Data(22) |<6>| BUF[HSK]: Peeked 74 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 2842 bytes of Data |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 02 0d |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[11ea380]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[11ea380]: Received Packet[2] Handshake(22) with length: 525 |<7>| READ: Got 525 bytes from 5 |<7>| READ: read 525 bytes from 5 |<7>| 0000 - 0c 00 02 09 00 80 e6 96 9d 3d 49 5b e3 2c 7c f1 |<7>| 0001 - 80 c3 bd d4 79 8e 91 b7 81 82 51 bb 05 5e 2a 20 |<7>| 0002 - 64 90 4a 79 a7 70 fa 15 a2 59 cb d5 23 a6 a6 ef |<7>| 0003 - 09 c4 30 48 d5 a2 2f 97 1f 3c 20 12 9b 48 00 0e |<7>| 0004 - 6e dd 06 1c bc 05 3e 37 1d 79 4e 53 27 df 61 1e |<7>| 0005 - bb be 1b ac 9b 5c 60 44 cf 02 3d 76 e0 5e ea 9b |<7>| 0006 - ad 99 1b 13 a6 3c 97 4e 9e f1 83 9e b5 db 12 51 |<7>| 0007 - 36 f7 26 2e 56 a8 87 15 38 df d8 23 c6 50 50 85 |<7>| 0008 - e2 1f 0d d5 c8 6b 00 01 02 00 80 1d 78 2e 66 4a |<7>| 0009 - 1f 22 5a 0d 43 a2 2f c5 be b9 18 ed fa 5b 12 f4 |<7>| 000a - 2b f7 b4 19 3d 3e 9b 40 b5 87 a8 5a 2a bd 9f fc |<7>| 000b - cf f1 ef 56 13 6c b7 55 2e 4f ac 0b 4e 56 9a 94 |<7>| 000c - 2a 53 67 ae 10 56 ff 80 a0 48 4d 87 18 ce 8d 48 |<7>| 000d - 1f bd 47 6f 70 92 3c 0c d7 a5 eb 90 a0 b4 84 7a |<7>| 000e - 83 64 32 41 47 00 ba 0b d3 78 fe 32 8d a2 4f 93 |<7>| 000f - 20 3b d7 36 5d 5c f9 eb 86 a1 17 5a 4e a4 7b 2f |<7>| 0010 - 81 c6 b6 42 2e 74 ca db cc 57 e3 01 00 3c 84 29 |<7>| 0011 - 2e a6 fd 5b 9b f5 c4 71 49 98 6e 1d 99 e6 43 f3 |<7>| 0012 - 7c 40 de 60 28 00 a5 a5 5c d8 25 62 07 4a 00 4a |<7>| 0013 - a0 4c 10 d6 93 99 bb c6 f5 a6 0c 93 8c 4a 65 34 |<7>| 0014 - 91 99 12 ca 61 e4 83 ef a5 c3 36 1b 2e 02 7e 9b |<7>| 0015 - 91 25 bd a7 cd 40 ab ff 2c 2d c5 ca ee 1b cc 69 |<7>| 0016 - a7 40 89 33 9c 4f 4c dd 3c 97 5d a4 fc 77 eb 07 |<7>| 0017 - 5c 36 95 1d d2 8f 94 ea d4 02 35 5c cf f5 9d 21 |<7>| 0018 - d8 db f7 92 30 30 fc 3f 27 61 c3 44 70 ca fc ff |<7>| 0019 - b6 e9 80 47 bc c7 ec d0 82 25 73 1c 61 52 ed d6 |<7>| 001a - a9 e6 e9 07 47 6c 1b 22 34 cc bd 7e 6b 89 7f ff |<7>| 001b - fc 0c 64 b1 1b d7 24 f2 de e6 df 4a 60 83 e2 97 |<7>| 001c - f9 32 86 61 88 91 31 b4 62 66 9a 9e bc 67 33 c4 |<7>| 001d - 2a da 67 8a ec 0e 95 22 6b e1 12 05 1f 48 94 ad |<7>| 001e - a4 e7 82 17 a0 5f 1b 24 38 ad 66 50 39 dc e9 43 |<7>| 001f - ef 21 9d 8c c2 28 90 6b d8 f3 83 f4 aa 6b d7 9c |<7>| 0020 - c0 ff 53 b6 5b 9e 1a d6 79 c9 92 f9 b0 |<7>| RB: Have 5 bytes into buffer. Adding 525 bytes. |<7>| RB: Requested 530 bytes |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[11ea380]: Decrypted Packet[2] Handshake(22) with length: 525 |<6>| BUF[HSK]: Inserted 525 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[11ea380]: SERVER KEY EXCHANGE was received [525 bytes] |<6>| BUF[REC][HD]: Read 521 bytes of Data(22) |<6>| BUF[HSK]: Peeked 2846 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 521 bytes of Data |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 c3 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[11ea380]: Expected Packet[3] Handshake(22) with length: 1 |<4>| REC[11ea380]: Received Packet[3] Handshake(22) with length: 195 |<7>| READ: Got 195 bytes from 5 |<7>| READ: read 195 bytes from 5 |<7>| 0000 - 0d 00 00 bb 04 03 04 01 02 00 b4 00 b2 30 81 af |<7>| 0001 - 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 10 30 |<7>| 0002 - 0e 06 03 55 04 08 13 07 41 6c 61 62 61 6d 61 31 |<7>| 0003 - 13 30 11 06 03 55 04 07 13 0a 48 75 6e 74 73 76 |<7>| 0004 - 69 6c 6c 65 31 15 30 13 06 03 55 04 0a 13 0c 44 |<7>| 0005 - 69 67 69 75 6d 2c 20 49 6e 63 2e 31 22 30 20 06 |<7>| 0006 - 03 55 04 0b 13 19 41 73 74 65 72 69 73 6b 20 44 |<7>| 0007 - 65 76 65 6c 6f 70 6d 65 6e 74 20 54 65 61 6d 31 |<7>| 0008 - 16 30 14 06 03 55 04 03 13 0d 44 69 67 69 75 6d |<7>| 0009 - 20 53 56 4e 20 43 41 31 26 30 24 06 09 2a 86 48 |<7>| 000a - 86 f7 0d 01 09 01 16 17 61 73 74 65 72 69 73 6b |<7>| 000b - 74 65 61 6d 40 64 69 67 69 75 6d 2e 63 6f 6d 0e |<7>| 000c - 00 00 00 |<7>| RB: Have 5 bytes into buffer. Adding 195 bytes. |<7>| RB: Requested 200 bytes |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[11ea380]: Decrypted Packet[3] Handshake(22) with length: 195 |<6>| BUF[HSK]: Inserted 195 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[11ea380]: CERTIFICATE REQUEST was received [191 bytes] |<6>| BUF[REC][HD]: Read 187 bytes of Data(22) |<6>| BUF[HSK]: Peeked 525 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 187 bytes of Data |<2>| ASSERT: pkcs12.c:1082 |<9>| salt.size: 8 |<9>| iterationCount: 2048 |<2>| ASSERT: pkcs12_bag.c:646 |<9>| salt.size: 8 |<9>| iterationCount: 2048 |<2>| ASSERT: dn.c:444 |<2>| ASSERT: dn.c:374 |<2>| ASSERT: dn.c:492 |<2>| ASSERT: dn.c:444 |<2>| ASSERT: dn.c:374 |<2>| ASSERT: dn.c:492 In client cert provider callback. Supplying client certificate. |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[11ea380]: SERVER HELLO DONE was received [4 bytes] |<6>| BUF[HSK]: Peeked 191 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<3>| HSK[11ea380]: CERTIFICATE was send [1421 bytes] |<6>| BUF[HSK]: Peeked 4 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[11ea380]: Sending Packet[1] Handshake(22) with length: 1421 |<2>| ASSERT: gnutls_cipher.c:205 |<7>| WRITE: Will write 1426 bytes to 5. |<7>| WRITE: wrote 1426 bytes to 5. Left 0 bytes. Total 1426 bytes. |<7>| 0000 - 16 03 01 05 8d 0b 00 05 89 00 05 86 00 05 83 30 |<7>| 0001 - 82 05 7f 30 82 04 67 a0 03 02 01 02 02 09 00 c5 |<7>| 0002 - 45 59 56 d9 a7 ac 12 30 0d 06 09 2a 86 48 86 f7 |<7>| 0003 - 0d 01 01 04 05 00 30 81 af 31 0b 30 09 06 03 55 |<7>| 0004 - 04 06 13 02 55 53 31 10 30 0e 06 03 55 04 08 13 |<7>| 0005 - 07 41 6c 61 62 61 6d 61 31 13 30 11 06 03 55 04 |<7>| 0006 - 07 13 0a 48 75 6e 74 73 76 69 6c 6c 65 31 15 30 |<7>| 0007 - 13 06 03 55 04 0a 13 0c 44 69 67 69 75 6d 2c 20 |<7>| 0008 - 49 6e 63 2e 31 22 30 20 06 03 55 04 0b 13 19 41 |<7>| 0009 - 73 74 65 72 69 73 6b 20 44 65 76 65 6c 6f 70 6d |<7>| 000a - 65 6e 74 20 54 65 61 6d 31 16 30 14 06 03 55 04 |<7>| 000b - 03 13 0d 44 69 67 69 75 6d 20 53 56 4e 20 43 41 |<7>| 000c - 31 26 30 24 06 09 2a 86 48 86 f7 0d 01 09 01 16 |<7>| 000d - 17 61 73 74 65 72 69 73 6b 74 65 61 6d 40 64 69 |<7>| 000e - 67 69 75 6d 2e 63 6f 6d 30 1e 17 0d 30 35 31 31 |<7>| 000f - 32 35 32 33 33 31 34 37 5a 17 0d 31 35 31 31 32 |<7>| 0010 - 33 32 33 33 31 34 37 5a 30 81 af 31 0b 30 09 06 |<7>| 0011 - 03 55 04 06 13 02 55 53 31 10 30 0e 06 03 55 04 |<7>| 0012 - 08 13 07 41 6c 61 62 61 6d 61 31 13 30 11 06 03 |<7>| 0013 - 55 04 07 13 0a 48 75 6e 74 73 76 69 6c 6c 65 31 |<7>| 0014 - 15 30 13 06 03 55 04 0a 13 0c 44 69 67 69 75 6d |<7>| 0015 - 2c 20 49 6e 63 2e 31 22 30 20 06 03 55 04 0b 13 |<7>| 0016 - 19 41 73 74 65 72 69 73 6b 20 44 65 76 65 6c 6f |<7>| 0017 - 70 6d 65 6e 74 20 54 65 61 6d 31 16 30 14 06 03 |<7>| 0018 - 55 04 03 13 0d 44 69 67 69 75 6d 20 53 56 4e 20 |<7>| 0019 - 43 41 31 26 30 24 06 09 2a 86 48 86 f7 0d 01 09 |<7>| 001a - 01 16 17 61 73 74 65 72 69 73 6b 74 65 61 6d 40 |<7>| 001b - 64 69 67 69 75 6d 2e 63 6f 6d 30 82 01 22 30 0d |<7>| 001c - 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 |<7>| 001d - 0f 00 30 82 01 0a 02 82 01 01 00 e1 98 dd 86 39 |<7>| 001e - 24 bf 1a f6 2b d4 c3 e4 c4 26 69 e8 2c da bc 11 |<7>| 001f - 38 03 66 8a e6 3c 37 2d 1c 4a a7 4b 4f 4a 72 3e |<7>| 0020 - e0 80 08 f1 c2 17 9a b5 d5 f1 a6 d8 64 f3 cc d1 |<7>| 0021 - 1b 04 cb b0 7d 75 87 52 9a 7a ea ab f2 64 f1 0e |<7>| 0022 - d4 95 fa 60 a5 1e fa d6 5d 8a 55 a8 38 98 4d a7 |<7>| 0023 - 04 29 4c ad 2d 21 27 d5 87 b6 88 93 e2 fc 15 82 |<7>| 0024 - 6e b5 cc 7c 45 a5 88 0c 5d 71 29 f2 9d 95 ea 9c |<7>| 0025 - ff 01 55 7b c7 de 8d 79 24 49 00 02 69 a9 ac fa |<7>| 0026 - 39 e5 37 5d 49 f1 40 a7 62 c0 9e a2 21 d9 c5 21 |<7>| 0027 - a2 a9 83 99 65 82 8e 73 61 89 8c 1d 18 2f 38 29 |<7>| 0028 - 63 19 20 6a 42 a3 22 4c 08 73 8a 56 fd 0d a8 a7 |<7>| 0029 - 10 e8 ba e9 eb 90 ae 48 10 63 5a 33 13 bd 22 b8 |<7>| 002a - 50 a6 0d 18 4b d1 81 d2 60 27 7d 38 c6 f2 b5 2e |<7>| 002b - ce ef 5a e1 86 33 ce 0d df 80 e9 b7 84 f3 f6 d1 |<7>| 002c - cf e1 b8 aa ad 9f 23 eb 04 58 0f c6 68 5f 3b e5 |<7>| 002d - f1 7c 9b 2c 63 bb 8b fa fd d5 25 02 03 01 00 01 |<7>| 002e - a3 82 01 9a 30 82 01 96 30 1d 06 03 55 1d 0e 04 |<7>| 002f - 16 04 14 50 d3 ee fd 08 95 06 26 16 49 04 90 bf |<7>| 0030 - 35 02 11 30 92 bd 27 30 81 e4 06 03 55 1d 23 04 |<7>| 0031 - 81 dc 30 81 d9 80 14 50 d3 ee fd 08 95 06 26 16 |<7>| 0032 - 49 04 90 bf 35 02 11 30 92 bd 27 a1 81 b5 a4 81 |<7>| 0033 - b2 30 81 af 31 0b 30 09 06 03 55 04 06 13 02 55 |<7>| 0034 - 53 31 10 30 0e 06 03 55 04 08 13 07 41 6c 61 62 |<7>| 0035 - 61 6d 61 31 13 30 11 06 03 55 04 07 13 0a 48 75 |<7>| 0036 - 6e 74 73 76 69 6c 6c 65 31 15 30 13 06 03 55 04 |<7>| 0037 - 0a 13 0c 44 69 67 69 75 6d 2c 20 49 6e 63 2e 31 |<7>| 0038 - 22 30 20 06 03 55 04 0b 13 19 41 73 74 65 72 69 |<7>| 0039 - 73 6b 20 44 65 76 65 6c 6f 70 6d 65 6e 74 20 54 |<7>| 003a - 65 61 6d 31 16 30 14 06 03 55 04 03 13 0d 44 69 |<7>| 003b - 67 69 75 6d 20 53 56 4e 20 43 41 31 26 30 24 06 |<7>| 003c - 09 2a 86 48 86 f7 0d 01 09 01 16 17 61 73 74 65 |<7>| 003d - 72 69 73 6b 74 65 61 6d 40 64 69 67 69 75 6d 2e |<7>| 003e - 63 6f 6d 82 09 00 c5 45 59 56 d9 a7 ac 12 30 0f |<7>| 003f - 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 |<7>| 0040 - 11 06 09 60 86 48 01 86 f8 42 01 01 04 04 03 02 |<7>| 0041 - 01 06 30 09 06 03 55 1d 12 04 02 30 00 30 2b 06 |<7>| 0042 - 09 60 86 48 01 86 f8 42 01 0d 04 1e 16 1c 54 69 |<7>| 0043 - 6e 79 43 41 20 47 65 6e 65 72 61 74 65 64 20 43 |<7>| 0044 - 65 72 74 69 66 69 63 61 74 65 30 22 06 03 55 1d |<7>| 0045 - 11 04 1b 30 19 81 17 61 73 74 65 72 69 73 6b 74 |<7>| 0046 - 65 61 6d 40 64 69 67 69 75 6d 2e 63 6f 6d 30 0e |<7>| 0047 - 06 03 55 1d 0f 01 01 ff 04 04 03 02 01 06 30 0d |<7>| 0048 - 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 03 82 01 |<7>| 0049 - 01 00 59 1f 70 32 9d c6 b4 2d 27 02 66 38 d8 66 |<7>| 004a - c3 e6 5e be ef bd 24 3c c3 b9 05 76 ed f6 3c 0b |<7>| 004b - 64 da 6b cd ff 0e 8a be 26 68 4d 89 ff 33 ce 08 |<7>| 004c - e9 1f 42 80 05 cf d0 f6 33 a4 82 99 c0 f0 45 7f |<7>| 004d - ba 96 e6 f5 ae f3 d1 e9 bb 75 8b 69 2a 32 b2 44 |<7>| 004e - 0f f5 0d fb b3 f7 5f e8 50 1e 1f db dd f4 06 43 |<7>| 004f - 71 cc 1f 57 dd 5a e3 4c 0e a0 76 79 0a 93 bc 42 |<7>| 0050 - aa f5 b0 bc 59 e2 f0 63 8f 03 9e 51 97 d6 21 90 |<7>| 0051 - 14 e4 96 c1 d6 d7 9a 61 76 f3 7c 48 ee 3b 57 23 |<7>| 0052 - cb cd 76 fb dc 84 11 99 c7 fe 4c 36 6e 10 27 3c |<7>| 0053 - 38 39 b9 32 fc f3 75 b8 d8 72 7c c2 4b 85 3f e8 |<7>| 0054 - a0 dc 02 bb a0 81 90 d7 82 0a c7 e1 5d a1 99 9e |<7>| 0055 - 87 16 28 50 5e 47 32 34 c6 9d 2b 1a 06 74 89 61 |<7>| 0056 - 97 99 7b 86 68 a3 ef 1f 3a 58 c6 69 2a 89 75 ff |<7>| 0057 - 82 75 52 d6 f6 9d d5 0a 42 2d 65 5d a4 39 d6 4c |<7>| 0058 - da bd 76 6f af 9d c3 2b 72 80 c3 68 79 c6 4e 0b |<7>| 0059 - 4b 6a |<4>| REC[11ea380]: Sent Packet[2] Handshake(22) with length: 1426 |<3>| HSK[11ea380]: CLIENT KEY EXCHANGE was send [134 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[11ea380]: Sending Packet[2] Handshake(22) with length: 134 |<2>| ASSERT: gnutls_cipher.c:205 |<7>| WRITE: Will write 139 bytes to 5. |<7>| WRITE: wrote 139 bytes to 5. Left 0 bytes. Total 139 bytes. |<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 7a 6f 3b eb 5b |<7>| 0001 - 36 5c ed 9b 77 53 d5 be ec af 56 32 9c fa 37 f9 |<7>| 0002 - e0 d4 31 90 a4 9e 31 43 6d ed e6 39 83 26 b1 6c |<7>| 0003 - f2 3f 7d 1d a5 55 e1 8e bd 17 42 3e b2 4d e8 15 |<7>| 0004 - be 10 16 0f 98 49 0f 84 a2 08 41 0d 15 9c ab f2 |<7>| 0005 - f2 7f c8 dc d6 c1 d6 75 a8 d5 a5 78 d1 af 9e e7 |<7>| 0006 - 85 e5 40 c2 72 aa df 94 df 03 bf be 19 c2 94 10 |<7>| 0007 - 22 80 2c 04 36 cf e1 a1 8d b3 cd 6b 3b aa 52 25 |<7>| 0008 - bd 68 c8 2a b9 df 13 53 4f 27 81 |<4>| REC[11ea380]: Sent Packet[3] Handshake(22) with length: 139 |<2>| ASSERT: gnutls_sig.c:275 |<2>| ASSERT: gnutls_sig.c:117 |<2>| ASSERT: auth_cert.c:1405 |<2>| ASSERT: gnutls_kx.c:355 |<2>| ASSERT: gnutls_handshake.c:2402 |<6>| BUF[HSK]: Cleared Data from buffer sess: Closing connection. |<2>| ASSERT: gnutls_record.c:262 sess: Connection closed. Request ends, status 0 class 0xx, error line: SSL negotiation failed: SSL error: Key usage violation in certificate has been detected. Running destroy hooks. Request ends. svn: OPTIONS of 'https://origsvn.digium.com/svn/asterisk': SSL negotiation failed: SSL error: Key usage violation in certificate has been detected. (https://origsvn.digium.com) sess: Destroying session. sess: Destroying session. -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) From nmav at gnutls.org Mon Nov 3 20:43:10 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2008 21:43:10 +0200 Subject: [Help-gnutls] Diffie Hellman In-Reply-To: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> References: <1918c28b0811030433l604a607oe5013d33c63cd41b@mail.gmail.com> Message-ID: <490F544E.4090109@gnutls.org> Martin Knappe wrote: > hi > > i have a question > > i have seen source code where the server makes a call to > gnutls_dh_set_prime_bits > the way i understand it, this doesnt really make sense: the server suggests > these parameters to the client, and the client only uses this function to > determine whether the parameters offered by the server are acceptable, > right? > is there any point in calling gnutls_dh_set_prime_bits on the server side? No, there is no point. regards, Nikos From nmav at gnutls.org Mon Nov 3 21:03:01 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2008 22:03:01 +0200 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490F3BBD.5060603@digium.com> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> <490F3BBD.5060603@digium.com> Message-ID: <490F58F5.7090706@gnutls.org> Kevin P. Fleming wrote: > Nikos Mavrogiannopoulos wrote: > >> I don't think this can be the case, but cannot be sure. Does libneon >> can be run with gnutls debugging on? > > Thanks very much for your help! > > I've built Subversion 1.5.4 with libneon 0.28.2 (both from source, but > gnutls using the Ubuntu packages) configured to force the gnutls global > debug level to 4711, and here's the output from a failed connection attempt: It seems gnutls fails because the (client) certificate it uses for authentication it doesn't support signing (and TLS client certificates must support it). Check (with certtool -i) if the client certificate contains the following lines: Key Usage (critical): Digital signature. (the one I used for testing contained them). regards, Nikos From kpfleming at digium.com Tue Nov 4 01:58:45 2008 From: kpfleming at digium.com (Kevin P. Fleming) Date: Mon, 03 Nov 2008 18:58:45 -0600 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490F58F5.7090706@gnutls.org> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> <490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org> Message-ID: <490F9E45.5080300@digium.com> Nikos Mavrogiannopoulos wrote: > It seems gnutls fails because the (client) certificate it uses for > authentication it doesn't support signing (and TLS client certificates > must support it). > > Check (with certtool -i) if the client certificate contains the > following lines: > > Key Usage (critical): > Digital signature. Yes, I used openssl's pkcs12 command to extract the cert from the .p12 file that it lives in, then used 'certtool -i --infile cert.pem', and this is the output: X.509 Certificate Information: Version: 3 Serial Number (hex): 00c9 Issuer: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com Validity: Not Before: Sun May 18 06:10:53 UTC 2008 Not After: Tue Mar 08 06:10:53 UTC 2011 Subject: C=US,ST=Alabama,L=Huntsville,O=Digium,OU=Asterisk Development Team,CN=Kevin P. Fleming,EMAIL=kpfleming Subject Public Key Algorithm: RSA Modulus (bits 4096): 9a:cb:78:a3:4e:4c:cc:b0:ce:0c:b4:15:fb:08:ab:04 c5:37:6a:3c:82:5b:ac:f8:52:21:44:c8:67:e9:24:a7 d6:fb:63:34:20:0c:1b:f3:27:2c:3a:bc:c8:94:93:78 a1:86:a5:a4:52:64:35:e5:25:89:c2:75:46:48:d9:4a 2c:d7:80:d9:c0:57:b7:5d:9c:1b:fa:a1:27:e7:b8:b6 e1:e0:6f:4b:ad:80:43:19:15:df:31:8f:97:53:54:80 4a:f9:ed:3f:82:c7:98:3e:7d:5c:6c:02:9e:bc:e7:d5 93:b2:ae:74:2d:71:99:75:c8:ea:c9:4b:e6:5f:6a:e5 96:a7:1f:51:f5:8b:88:9c:59:75:dd:eb:04:aa:3f:81 b3:8a:08:94:54:ac:ad:c9:c0:3c:31:e4:96:4c:92:34 76:42:b7:08:e7:e4:2f:f0:0b:96:49:62:57:8f:31:6f 16:92:04:62:46:47:0b:fe:14:97:2b:a7:72:c5:e2:97 6c:22:8f:01:e9:ab:1c:0f:9c:99:84:85:03:76:39:75 d6:29:f5:c8:c3:27:b0:26:63:f5:2a:7d:a3:ed:40:4e ba:42:4d:56:c3:ac:20:62:7f:23:e0:bc:1c:2e:4e:b5 f4:42:8a:d6:07:1e:57:cc:30:1f:5a:24:3c:a1:49:29 d1:15:51:50:17:13:21:1d:52:d6:f5:81:01:eb:e9:5f 6a:c0:69:06:96:19:c9:fc:bc:56:af:ee:c1:19:22:c6 51:21:aa:3c:a6:f4:93:07:8e:94:9c:1c:64:08:95:07 67:c8:36:d7:2b:0c:97:48:f5:31:2d:06:51:5d:fa:5e 36:2c:ce:d3:07:54:13:fa:33:1e:28:9c:3b:0f:4e:51 d0:66:33:a8:83:93:b9:22:03:0b:a0:3b:a7:60:f0:15 71:b1:47:d0:b6:13:f8:96:66:92:d7:20:54:39:37:06 a9:24:5a:09:36:30:be:06:ba:71:f3:e2:49:b1:54:fb a2:3a:bc:66:69:61:f9:e6:4f:2c:21:f5:d9:ad:15:e0 1d:ca:5f:28:bc:cc:1b:61:ce:9b:1f:7f:d9:f2:15:39 62:92:ad:7d:7d:1a:02:d2:76:29:2e:4f:7e:d7:28:c3 1a:44:41:68:a0:65:d3:9f:94:08:e4:05:0b:69:97:d3 9c:bc:23:e1:2e:e4:5b:95:fc:9e:d0:fc:2c:bd:d9:07 07:dd:33:36:24:57:f7:9e:65:da:f2:5c:34:86:7f:11 18:e6:e4:b0:86:72:5d:24:14:7f:71:89:68:03:bc:db 1b:8d:56:cf:a3:61:34:87:cd:59:ce:5d:ae:04:20:d5 Exponent: 01:00:01 Extensions: Basic Constraints (not critical): Certificate Authority (CA): FALSE Unknown extension 2.16.840.1.113730.1.1 (not critical): ASCII: .... Hexdump: 030204b0 Unknown extension 2.16.840.1.113730.1.13 (not critical): ASCII: ..TinyCA Generated Certificate Hexdump: 161c54696e7943412047656e657261746564204365727469666963617465 Subject Key Identifier (not critical): e43fc9b24e312ac01a20ea00c25c67b52931ebbf Authority Key Identifier (not critical): 50d3eefd0895062616490490bf3502113092bd27 Unknown extension 2.5.29.18 (not critical): ASCII: 0...asteriskteam at digium.com Hexdump: 30198117617374657269736b7465616d4064696769756d2e636f6d Subject Alternative Name (not critical): RFC822name: kpfleming Key Usage (critical): Digital signature. Key encipherment. Signature Algorithm: RSA-SHA Signature: 7a:0e:ea:96:f0:b4:17:61:ef:67:3d:a8:8d:dc:77:0b 4c:55:93:a5:d3:7f:90:bd:95:1c:71:7f:95:17:2e:30 df:f2:e2:b6:43:fa:28:44:9a:0d:3e:ca:3a:01:14:09 c5:49:a1:58:d2:63:b6:6a:d1:90:8d:81:e1:b0:c4:30 d7:ad:9e:5b:2d:20:ac:64:4d:8b:24:ab:1b:27:ab:38 74:8a:f3:fe:2b:81:91:bd:e7:a8:31:01:24:b6:65:ec d6:4f:e9:14:13:4a:2e:b3:70:79:66:26:6a:cb:f4:ee 04:ec:32:be:17:08:16:8c:d0:5e:ad:e6:40:82:68:62 11:fa:c4:b6:65:6a:af:b3:77:56:41:cc:c6:e6:59:6b 3f:e4:ce:00:ae:0f:ca:30:9e:0f:12:ab:9f:24:6d:d6 98:bd:9b:07:71:5f:9b:75:0d:c6:bc:98:c2:d8:04:4f a7:14:db:13:95:d5:06:f8:06:cd:2a:8e:84:ac:d1:8d 16:b7:64:de:75:c2:95:3b:ad:b6:94:ad:25:b6:fa:e8 f7:1f:29:2d:bf:90:1a:cb:2a:3c:7b:c8:95:41:2c:c4 af:8a:64:60:f9:3f:cb:c6:f1:d4:5a:02:f0:6f:bd:4c ee:08:87:47:b7:41:1c:6a:eb:e5:34:ef:0c:90:94:69 Other Information: MD5 fingerprint: 1c848e7867c95a05ba91488c60c5be80 SHA-1 fingerprint: 8d4c78bab2b4b982676d2c8ecfd62740a2ac8a9f Public Key Id: 03f0a358652c75d0a87207a7a3ef362f81bcd04c -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) From nmav at gnutls.org Tue Nov 4 07:25:50 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Nov 2008 08:25:50 +0200 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <490F9E45.5080300@digium.com> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> <490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org> <490F9E45.5080300@digium.com> Message-ID: <490FEAEE.9070106@gnutls.org> Kevin P. Fleming wrote: > Nikos Mavrogiannopoulos wrote: > >> It seems gnutls fails because the (client) certificate it uses for >> authentication it doesn't support signing (and TLS client certificates >> must support it). >> >> Check (with certtool -i) if the client certificate contains the >> following lines: >> >> Key Usage (critical): >> Digital signature. > > Yes, I used openssl's pkcs12 command to extract the cert from the .p12 > file that it lives in, then used 'certtool -i --infile cert.pem', and > this is the output: Could it be then that libneon selected a wrong certificate from the pkcs12 file? Does it use gnutls_certificate_set_x509_simple_pkcs12_file()? I quick glimpsed gnutls_certificate_set_x509_simple_pkcs12_file() and looks very simple thus might add the first certificate no matter if it corresponds to the key. In that case it is a gnutls bug and will be fixed. (workaround: use a single certificate in the pkcs12 file). regards, Nikos From martin.knappe at gmail.com Tue Nov 4 09:19:47 2008 From: martin.knappe at gmail.com (Martin Knappe) Date: Tue, 4 Nov 2008 09:19:47 +0100 Subject: [Help-gnutls] Re: handshake In-Reply-To: <1918c28b0811030839j528a6381w32e466f68bae0498@mail.gmail.com> References: <1918c28b0811030839j528a6381w32e466f68bae0498@mail.gmail.com> Message-ID: <1918c28b0811040019h544eb7fcu11ad34d91c2834cd@mail.gmail.com> I'll also post the output of strace; I really don't understand what's going on here... write(1, "BEFORE HANDSHAKE\n", 14BEFORE HANDSHAKE ) = 14 gettimeofday({1225793748, 165856}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 664041}, ru_stime={0, 0}, ...}) = 0 time(NULL) = 1225793748 times({tms_utime=66, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1845603364 gettimeofday({1225793748, 167291}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 664041}, ru_stime={0, 0}, ...}) = 0 time(NULL) = 1225793748 times({tms_utime=66, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1845603364 recv(5, here the client blocks, when it has to do a send instead of a receive! On Mon, Nov 3, 2008 at 5:39 PM, Martin Knappe wrote: > hi > > im having a problem with making a handshake between client and server > the problem is that my client seems to "think" it is really a server, > because instead of sending a client hello. it does a receive when initiating > the handshake (i checked with strace) > could someone have a look at this snippet and tell me why this client might > think it is a server: > > if (gnutls_init(&session, GNUTLS_CLIENT) != 0) { > return E_GNUTLS_INIT; > } > if (gnutls_set_default_priority(session) != 0) { > return E_GNUTLS_SET_DEFAULT_PRIORITY; > } > if (gnutls_kx_set_priority(session, (const int[]) {GNUTLS_KX_DHE_PSK, > 0})) { > return E_GNUTLS_KX_SET_PRIORITY; > } > if (gnutls_credentials_set (session, GNUTLS_CRD_PSK, psk_cred) != 0) { > return E_GNUTLS_CREDENTIALS_SET; > } > gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t) sockfd); > printf("BEFORE > HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n"); > if (gnutls_handshake(session) < 0) { > return E_HANDSHAKE; > } > printf("AFTER > HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\n"); > return E_SUCCESS; > > when i execute this, I get the message "BEFORE > HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!", and then my > client blocks! > > many thanks > > martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristian.martens at freenet.de Tue Nov 4 10:17:45 2008 From: kristian.martens at freenet.de (kristian.martens at freenet.de) Date: Tue, 04 Nov 2008 10:17:45 +0100 Subject: [Help-gnutls] Re: handshake Message-ID: <09a50f33fe9e7fa6fe71173b27e67df5@email.freenet.de> Maybe you were missing (see gnutls manual) .... int sd; /* connect to the peer */ sd = tcp_connect (); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); .... -----Urspr?ngliche Nachricht----- Von: \"Martin Knappe\" [martin.knappe at gmail.com] Gesendet: Di. 04.11.08 (09:19) An: help-gnutls at gnu.org Betreff: [Help-gnutls] Re: handshake I\'ll also post the output of strace; I really don\'t understand what\'s going on here... write(1, \"BEFORE HANDSHAKEn\", 14BEFORE HANDSHAKE ) = 14 gettimeofday({1225793748, 165856}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 664041}, ru_stime={0, 0}, ...}) = 0 time(NULL) = 1225793748 times({tms_utime=66, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1845603364 gettimeofday({1225793748, 167291}, NULL) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 664041}, ru_stime={0, 0}, ...}) = 0 time(NULL) = 1225793748 times({tms_utime=66, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1845603364 recv(5, here the client blocks, when it has to do a send instead of a receive! On Mon, Nov 3, 2008 at 5:39 PM, Martin Knappe wrote: hi im having a problem with making a handshake between client and server the problem is that my client seems to \"think\" it is really a server, because instead of sending a client hello. it does a receive when initiating the handshake (i checked with strace) could someone have a look at this snippet and tell me why this client might think it is a server: if (gnutls_init(&session, GNUTLS_CLIENT) != 0) { return E_GNUTLS_INIT; } if (gnutls_set_default_priority(session) != 0) { return E_GNUTLS_SET_DEFAULT_PRIORITY; } if (gnutls_kx_set_priority(session, (const int[]) {GNUTLS_KX_DHE_PSK, 0})) { return E_GNUTLS_KX_SET_PRIORITY; } if (gnutls_credentials_set (session, GNUTLS_CRD_PSK, psk_cred) != 0) { return E_GNUTLS_CREDENTIALS_SET; } gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t) sockfd); printf(\"BEFORE HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!n\"); if (gnutls_handshake(session) < 0) { return E_HANDSHAKE; } printf(\"AFTER HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!n\"); return E_SUCCESS; when i execute this, I get the message \"BEFORE HANDSHAKE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\", and then my client blocks! many thanks martin -----Urspr?ngliche Nachricht Ende----- #adBox3 {display:none;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From kpfleming at digium.com Tue Nov 4 18:26:13 2008 From: kpfleming at digium.com (Kevin P. Fleming) Date: Tue, 04 Nov 2008 11:26:13 -0600 Subject: [Help-gnutls] Key usage violation in certificate In-Reply-To: <20081104092509.GA30869@manyfish.co.uk> References: <490A37DA.6090400@digium.com> <490D9E7B.7070507@gnutls.org> <490EFF54.80106@digium.com> <490F3BBD.5060603@digium.com> <490F58F5.7090706@gnutls.org> <490F9E45.5080300@digium.com> <490FEAEE.9070106@gnutls.org> <20081104092509.GA30869@manyfish.co.uk> Message-ID: <491085B5.1070002@digium.com> Joe Orton wrote: >> Could it be then that libneon selected a wrong certificate from the >> pkcs12 file? > > I'm missing some context here, but current neon releases can indeed do > that, this is a known neon bug, see: > > http://lists.manyfish.co.uk/pipermail/neon/2008-October/000086.html > >> Does it use gnutls_certificate_set_x509_simple_pkcs12_file()? > > Just for the record - neon doesn't use that function, no. OK, on the basis of this note (and yes, our client cert pkcs12 files usually contain the CA cert as well), I regenerated the pkcs12 file for my cert without the CA cert in it, and the problem has been worked around. We don't really need the CA cert to be in the pkcs12 files, so this will work for us. Thanks to everyone who helped solve this problem :-) -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) From rogge at fgan.de Wed Nov 5 09:31:33 2008 From: rogge at fgan.de (Henning Rogge) Date: Wed, 5 Nov 2008 09:31:33 +0100 Subject: [Help-gnutls] Reusing gcry_md_hd_t ? Message-ID: <200811050931.38255.rogge@fgan.de> Hello, I have to calculate multiple HMACs with the same key of different data packages. Is it possible to reuse an initialized gcry_md_hd_t structure, so I don't have to allocate it for every package ? Henning ************************************************* Diplom-Informatiker Henning Rogge Forschungsgesellschaft f?r Angewandte Naturwissenschaften e. V. (FGAN) Neuenahrer Str. 20, 53343 Wachtberg, Germany Tel.: 0049 (0)228 9435-961 Fax: 0049 (0)228 9435-685 E-Mail: rogge at fgan.de Web: www.fgan.de ************************************************ Sitz der Gesellschaft: Bonn Registergericht: Amtsgericht Bonn VR 2530 Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender (Stellv.) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From simon at josefsson.org Wed Nov 5 10:50:59 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Nov 2008 10:50:59 +0100 Subject: [Help-gnutls] Re: Reusing gcry_md_hd_t ? In-Reply-To: <200811050931.38255.rogge@fgan.de> (Henning Rogge's message of "Wed, 5 Nov 2008 09:31:33 +0100") References: <200811050931.38255.rogge@fgan.de> Message-ID: <87od0uwlfg.fsf@mocca.josefsson.org> Henning Rogge writes: > Hello, > > I have to calculate multiple HMACs with the same key of different data > packages. Is it possible to reuse an initialized gcry_md_hd_t structure, so I > don't have to allocate it for every package ? Try the libgcrypt mailing list instead: gcrypt-devel at gnupg.org /Simon From simon at josefsson.org Wed Nov 5 14:49:24 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Nov 2008 14:49:24 +0100 Subject: [Help-gnutls] Preparing libtasn1 2.0 Message-ID: <87skq6cmfv.fsf@mocca.josefsson.org> All, I plan to release libtasn1 v2.0 in a few days. Please test this daily build for problems: http://daily.josefsson.org/libtasn1/libtasn1-20081105.tar.gz btw, I've created a Redmine instance to track bugs, plan releases, wiki pages, and more, see: http://redmine.josefsson.org/wiki/libtasn1 /Simon From sschaeffner at hotmail.com Thu Nov 6 13:38:28 2008 From: sschaeffner at hotmail.com (Scott Schaeffner) Date: Thu, 6 Nov 2008 12:38:28 +0000 Subject: [Help-gnutls] Is gnutls using the shell model or the chain model for a certificate validation Message-ID: Hello, gnupgp contains a parameter to determine which of these two certificate validation models (shell or chain - --validation-model) shall be used (http://gnupg.org/documentation/manuals/gnupg/Certificate-Options.html). I was looking into the gnutls manual and did not find a statement concerning the validation model that is being used. So which one of the two is currently being used? Thanks, Scott _________________________________________________________________ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Nov 6 20:18:20 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 06 Nov 2008 14:18:20 -0500 Subject: [Help-gnutls] Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: (Scott Schaeffner's message of "Thu\, 6 Nov 2008 12\:38\:28 +0000") References: Message-ID: <8763n0u0hv.fsf@squeak.fifthhorseman.net> On Thu 2008-11-06 07:38:28 -0500, Scott Schaeffner wrote: > gnupgp contains a parameter to determine which of these two certificate > validation models (shell or chain - --validation-model) shall be used > (http://gnupg.org/documentation/manuals/gnupg/Certificate-Options.html). To be clear, this gpg documentation is in the "GPGSM Options" section, so it refers to the X.509 certificates, not OpenPGP certificates, correct? > I was looking into the gnutls manual and did not find a statement > concerning the validation model that is being used. I don't see any clear notes on the page you linked explaining specifically what "shell" and "chain" mean in this context. However, GnuTLS has several functions that can be used for X.509 certificate validation: http://www.gnu.org/software/gnutls/manual/html_node/Verifying-X_002e509-certificate-paths.html http://www.gnu.org/software/gnutls/manual/html_node/X_002e509-certificate-functions.html You should be able to use those functions to build a certificate validation that meets your specific needs. What are you trying to do? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From mike at reys.be Fri Nov 7 18:10:06 2008 From: mike at reys.be (mike at reys.be) Date: Fri, 7 Nov 2008 18:10:06 +0100 (CET) Subject: [Help-gnutls] Holiday Message-ID: <20081107171006.B807238E0868B@zulu.openminds.be> Hi, I'm on holiday till November 17th without proper access to e-mail. Mike Reys From sschaeffner at hotmail.com Mon Nov 10 07:57:23 2008 From: sschaeffner at hotmail.com (Scott Schaeffner) Date: Mon, 10 Nov 2008 06:57:23 +0000 Subject: [Help-gnutls] Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: References: <200811080017.mA80HLx29355@f7.net> Message-ID: Hello, Here the message (response to gnu.org #388183) I'd like to post: ---------------------------------------------------------------- >I don't see any clear notes on the page you linked explaining >specifically what "shell" and "chain" mean in this context. The power point presentation http://www.bundesnetzagentur.de/media/archive/1894.pps#259 shows the differences concerning the two different validation models. I furthermore found a note that indicates that in germany the chain model is required (http://www.adobe.com/devnet/acrobat/pdfs/admin_guide.pdf section 5.4.4.2) I did not have a detailed look into the implementation yet, so I am not sure if gnutls offers one function for a certificate chain validation or if you have to implement the verification of the chain on your own and gnutls only offers the functions for that. >To be clear, this gpg documentation is in the "GPGSM Options" section, >so it refers to the X.509 certificates, not OpenPGP certificates, >correct? Well, except for the power point presentation I could not find much references in the internet concerning the validation models. But my current assumption is that the models apply to both types of certificates. Thanks for the infos. Scott --------------------------------------------------------------- > Subject: Re: [gnu.org #388183] http://lists.gnu.org/archive/html/help-gnutls/2008-11/msg00020.html - response not possible > From: webmasters at gnu.org > To: sschaeffner at hotmail.com > Date: Fri, 7 Nov 2008 19:17:50 -0500 > > Hi Scott, > > I was trying to respond to the post > http://lists.gnu.org/archive/html/help-gnutls/2008-11/msg00020.html > and got the following message on http://lists.gnu.org/mp/yyz.py > > Thanks for the report. I'll tell the sysadmins. > > and therefore it looks I can not post a response... . > > Please email your response to help-gnutls at gnu.org with > Subject: Re: [Help-gnutls] Is gnutls using the shell model or the chain model for a certificate validation > > and it should get through in due course. > > Best, > karl at gnu.org > > > _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Mon Nov 10 09:08:02 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Nov 2008 09:08:02 +0100 Subject: [Help-gnutls] Libtasn1 1.6 Message-ID: <87hc6g80m5.fsf@mocca.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by Shishi to handle Kerberos V5 packets. Version 1.6 (released 2008-11-10) - Fixed namespace violation for MAX_NAME_SIZE and MAX_ERROR_DESCRIPTION_SIZE. The new names are ASN1_MAX_NAME_SIZE and ASN1_MAX_ERROR_DESCRIPTION_SIZE. - Fixed namespace violation for libtasn1_perror and libtasn1_strerror. The new names are asn1_perror and asn1_strerror. - Fix namespace violation for LIBASN1_VERSION. The new name is ASN1_VERSION. - Decoder can now decode BER encoded octet strings. - doc: Change license on the manual to GFDLv1.3+. - doc: Sync gdoc script with GnuTLS, changes license on man-pages to GAP. - doc: Improve gtk-doc manual. - Assumes system has strdup and string.h. - Remove libtasn1-config and libtasn1.m4, use standard AC_CHECK_FUNCS autoconf tests or pkg-config instead. - Change detection of when to use a linker version script, use --enable-ld-version-script or --disable-ld-version-script to override auto-detection logic. - API and ABI changes since last version: asn1_get_length_ber: New function. ASN1_VERSION: New symbol, replaces LIBTASN1_VERSION. asn1_strerror: New function, replaces libtasn1_strerror. asn1_perror: New function, replaces libtasn1_perror. libtasn1_strerror: Marked as deprecated. libtasn1_perror: Marked as deprecated. LIBTASN1_VERSION: Deprecated. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Here are the compressed sources (1.6MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-1.6.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: fd670bcb88612190729948c7939e612132e3bb71 libtasn1-1.6.tar.gz 0e623d6a497ebe0ef33c2188d8b8bfc02ec0035f4c7bb0501e0819a3 libtasn1-1.6.tar.gz Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Nov 10 11:48:33 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Nov 2008 11:48:33 +0100 Subject: [Help-gnutls] GnuTLS 2.6.1 - Security release [GNUTLS-SA-2008-3] Message-ID: <873ahz7t6m.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.6.1. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Version 2.6.1 is a maintainance and security release on our stable branch. ** libgnutls: Fix X.509 certificate chain validation error. [GNUTLS-SA-2008-3] The flaw makes it possible for man in the middle attackers (i.e., active attackers) to assume any name and trick GNU TLS clients into trusting that name. Thanks for report and analysis from Martin von Gagern . [CVE-2008-4989] Any updates with more details about this vulnerability will be added to ** libgnutls: Add missing prototype for gnutls_srp_set_prime_bits. Reported by Kevin Quick in . ** libgnutls-extra: Protect internal symbols with static. Fixes problem when linking certtool statically. Tiny patch from Aaron Ucko . ** libgnutls-openssl: Fix patch against X509_get_issuer_name. It incorrectly returned the subject DN instead of issuer DN in v2.6.0. Thanks to Thomas Viehmann for report. ** certtool: Print a PKCS #8 key even if it is not encrypted. ** tests: Make tests compile when using internal libtasn1. Patch by ludo at gnu.org (Ludovic Court?s). ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.9MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.1.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.1.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.1.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.1.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.6.1.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: a445e84176bf772794db9d8c71d5515dedb14bcc gnutls-2.6.1.tar.bz2 f3882745a290cc2a091dc50d9fb8bc7b4b999c29ecebe9730fe3bafd gnutls-2.6.1.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer uses libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.1. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.6.1.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.6.1.exe.sig The checksum values for SHA-1 and SHA-224 are: 7efc24d79a258927d803b7fb25f798d82f9d1ac0 gnutls-2.6.1.exe 20054cf34bf6bf5dafda13b6956c2de02c1f91ed63858c5bf8e0268c gnutls-2.6.1.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.1-1_all.deb The checksum values for SHA-1 and SHA-224 are: e4f70a2348dce9c1dec9de6f05e2e40872f2551c mingw32-gnutls_2.6.1-1_all.deb 8483af5489daa10086ef8f2db288e632184744c9bc0fc278a2dd7db2 mingw32-gnutls_2.6.1-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Security Patch ============== The following patch can be used if you use releases older than v2.6.0, or if you don't want to upgrade from v2.6.0 to v2.6.1. It fixes the GNUTLS-SA-2008-3 aka CVE-2008-4989 vulnerability. The patch was created against v2.6.0. --- lib/x509/verify.c.orig 2008-11-10 10:58:33.000000000 +0100 +++ lib/x509/verify.c 2008-11-10 10:58:41.000000000 +0100 @@ -374,6 +374,17 @@ int i = 0, ret; unsigned int status = 0, output; + /* Check if the last certificate in the path is self signed. + * In that case ignore it (a certificate is trusted only if it + * leads to a trusted party by us, not the server's). + */ + if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1], + certificate_list[clist_size - 1]) > 0 + && clist_size > 0) + { + clist_size--; + } + /* Verify the last certificate in the certificate path * against the trusted CA certificate list. * @@ -412,17 +423,6 @@ } #endif - /* Check if the last certificate in the path is self signed. - * In that case ignore it (a certificate is trusted only if it - * leads to a trusted party by us, not the server's). - */ - if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1], - certificate_list[clist_size - 1]) > 0 - && clist_size > 0) - { - clist_size--; - } - /* Verify the certificate path (chain) */ for (i = clist_size - 1; i > 0; i--) Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Nov 10 12:30:24 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 10 Nov 2008 12:30:24 +0100 Subject: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: (Scott Schaeffner's message of "Mon, 10 Nov 2008 06:57:23 +0000") References: <200811080017.mA80HLx29355@f7.net> Message-ID: <87abc76cof.fsf@mocca.josefsson.org> Scott Schaeffner writes: > Hello, > > Here the message (response to gnu.org #388183) I'd like to post: > ---------------------------------------------------------------- >>I don't see any clear notes on the page you linked explaining >>specifically what "shell" and "chain" mean in this context. > > > > The power point presentation http://www.bundesnetzagentur.de/media/archive/1894.pps#259 shows the differences concerning the two different validation models. > > > > I furthermore found a note that indicates that in germany the chain model is required (http://www.adobe.com/devnet/acrobat/pdfs/admin_guide.pdf section 5.4.4.2) > > > > I did not have a detailed look into the implementation yet, so I am not > sure if gnutls offers one function for a certificate chain validation > or if you have to implement the verification of the chain on your own > and gnutls only offers the functions for that. I'm not sure I understand the difference between the shell vs chain models based on that powerpoint, but I can say that there is only one algorithm implemented in gnutls for x.509 validation, and it validates X.509 paths in a chaining way. Whether that matches what you are looking for is not clear to me. You can read the code in lib/x509/verify.c. /Simon From RReddy at mocana.com Tue Nov 11 22:48:32 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Tue, 11 Nov 2008 13:48:32 -0800 Subject: [Help-gnutls] GNU TLS 2.2.4 installation Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> Hi, Can anyone help me with an installation error in GNU TLS? I am trying to install GNU TLS 2.2.4. Since it requires Libgcrypt which inturn requires libgpg-error, I have first installed libgpg error 1.0 and then, am trying to install Libgcrypt 1.2.0. Following is the error I am seeing when doing a "make" on Libgcrypt. /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o libgcrypt.la -rpath /usr/l ocal/lib -version-info 12:1:1 libgcrypt_la-misc.lo libgcrypt_la-global.lo libgc rypt_la-sexp.lo libgcrypt_la-stdmem.lo libgcrypt_la-secmem.lo libgcrypt_la-missi ng-string.lo libgcrypt_la-module.lo libgcrypt_la-ath.lo ../cipher/libcipher.la . ./mpi/libmpi.la -L/usr/local/lib -lgpg-error *** Warning: This system can not link to static lib archive /usr/local/lib/libgp g-error.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. libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries rm -fr .libs/libgcrypt.lax mkdir .libs/libgcrypt.lax rm -fr .libs/libgcrypt.lax/libcipher.a mkdir .libs/libgcrypt.lax/libcipher.a (cd .libs/libgcrypt.lax/libcipher.a && ar x /cygdrive/c/Documents and Settings/Desktop/libgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src/../cipher/ .libs/libcipher.a) ar: /cygdrive/c/Documents: No such file or directory make[2]: *** [libgcrypt.la] Error 9 make[2]: Leaving directory `/cygdrive/c/Documents and Settings/Desktop/li bgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/Documents and Settings/Desktop/li bgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0' make: *** [all] Error 2 Can you please tell me what I must be missing? Thanks, Rajitha. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Nov 11 22:53:04 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Nov 2008 16:53:04 -0500 Subject: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: <87abc76cof.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon\, 10 Nov 2008 12\:30\:24 +0100") References: <200811080017.mA80HLx29355@f7.net> <87abc76cof.fsf@mocca.josefsson.org> Message-ID: <87fxlyudz3.fsf@squeak.fifthhorseman.net> On Mon 2008-11-10 06:30:24 -0500, Simon Josefsson wrote: > Scott Schaeffner writes: > >> The power point presentation >> http://www.bundesnetzagentur.de/media/archive/1894.pps#259 shows >> the differences concerning the two different validation models. > > I'm not sure I understand the difference between the shell vs chain > models based on that powerpoint, but I can say that there is only > one algorithm implemented in gnutls for x.509 validation, and it > validates X.509 paths in a chaining way. Whether that matches what > you are looking for is not clear to me. You can read the code in > lib/x509/verify.c. I'm not sure that the powerpoint in question is even relevant to TLS connections. The powerpoint appears to be specifically about document signatures, not X.509 certificates. Amid all the fancy graphics and swooping timelines, the only distinction i could suss out was: * the chain model implies that as long as the digital signature was made during the lifetime of the signer's key, it is considered indefinitely valid. * the shell model implies that the digital signature on a document is only valid during the lifetime of the signer's key. How might this be relevant to TLS connections? If you view an X.509 certificate as a document consisting of a public key bound to a chunk of metadata, all digitally signed by a certificate authority, then you should take into account that the X.509 signature itself has an expiration date (validity period) In that case, the distinction between "shell" and "chain" models would be: * the chain model implies that the period of validity for an X.509 certificate is simply the validity period contained in the certificate. * the shell model implies that the period of validity for an X.509 certificate is the intersection of the validity period in the certificate and the validity period of the CA's certificate. The former is simpler to implement, but the latter seems more solidly secure. Why would a CA need to grant a certificate whose duration was longer than the CA's own expiration date, unless the CA was extending its own certificate? And if it wants to extend itself: do we (as users) want "trusted" root CAs to be able to unilaterally extend their own expiration date? I'd be interested in seeing any other references to these models that might shed more light, as i'm still not sure i understand the distinctions. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From dkg at fifthhorseman.net Tue Nov 11 23:08:02 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Nov 2008 17:08:02 -0500 Subject: [Help-gnutls] GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> (Rajitha Reddy's message of "Tue\, 11 Nov 2008 13\:48\:32 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> Message-ID: <87bpwlvrul.fsf@squeak.fifthhorseman.net> Hi Rajitha-- On Tue 2008-11-11 16:48:32 -0500, Rajitha Reddy wrote: > Can anyone help me with an installation error in GNU TLS? > > I am trying to install GNU TLS 2.2.4. Since it requires Libgcrypt > which inturn requires libgpg-error, I have first installed libgpg > error 1.0 and then, am trying to install Libgcrypt 1.2.0. Following > is the error I am seeing when doing a "make" on Libgcrypt. The linewrap in your transcript was very odd. I had difficulty reading it. But it looks like you're using cygwin. Is there a reason not to use the prebuilt cygwin gnutls packages? http://cygwin.com/packages/gnutls/ Also, GnuTLS 2.2 is fairly old. You might prefer a more recent version. Please make sure that you track the project, though, as the current security advisory dust settles. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From RReddy at mocana.com Tue Nov 11 23:17:57 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Tue, 11 Nov 2008 14:17:57 -0800 Subject: [Help-gnutls] GNU TLS 2.2.4 installation In-Reply-To: <87bpwlvrul.fsf@squeak.fifthhorseman.net> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <87bpwlvrul.fsf@squeak.fifthhorseman.net> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A756E11D9@yugi.mocana.local> Hi Daniel, Thanks so much for the information. I will install GNU TLS 2.6.0. Yes, I am using Cygwin. Can I install it on linux if that's easier? I followed the link http://cygwin.com/packages/gnutls/ and tried to download the following: # gnutls-2.4.1-1 # gnutls-2.4.1-1-src But, the links further in # gnutls-2.4.1-1 are not enabled. So, the error I got is as follows: ================================================================================= /bin/sh ../libtool --mode=link gcc -g -O2 -Wall -o libgcrypt.la -rpath /usr/l ocal/lib -version-info 12:1:1 libgcrypt_la-misc.lo libgcrypt_la-global.lo libgc rypt_la-sexp.lo libgcrypt_la-stdmem.lo libgcrypt_la-secmem.lo libgcrypt_la-missi ng-string.lo libgcrypt_la-module.lo libgcrypt_la-ath.lo ../cipher/libcipher.la . ./mpi/libmpi.la -L/usr/local/lib -lgpg-error *** Warning: This system can not link to static lib archive /usr/local/lib/libgp g-error.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. libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared l ibraries rm -fr .libs/libgcrypt.lax mkdir .libs/libgcrypt.lax rm -fr .libs/libgcrypt.lax/libcipher.a mkdir .libs/libgcrypt.lax/libcipher.a (cd .libs/libgcrypt.lax/libcipher.a && ar x /cygdrive/c/Documents and Settings/Desktop/libgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src/../cipher/ .libs/libcipher.a) ar: /cygdrive/c/Documents: No such file or directory make[2]: *** [libgcrypt.la] Error 9 make[2]: Leaving directory `/cygdrive/c/Documents and Settings/Desktop/li bgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/c/Documents and Settings/Desktop/li bgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0' make: *** [all] Error 2 ================================================================================= Hopefully, the error message is readable now. Thanks, Rajitha. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Tuesday, November 11, 2008 2:08 PM To: Rajitha Reddy Cc: GnuTLS mailing list Subject: Re: [Help-gnutls] GNU TLS 2.2.4 installation Hi Rajitha-- On Tue 2008-11-11 16:48:32 -0500, Rajitha Reddy wrote: > Can anyone help me with an installation error in GNU TLS? > > I am trying to install GNU TLS 2.2.4. Since it requires Libgcrypt > which inturn requires libgpg-error, I have first installed libgpg > error 1.0 and then, am trying to install Libgcrypt 1.2.0. Following is > the error I am seeing when doing a "make" on Libgcrypt. The linewrap in your transcript was very odd. I had difficulty reading it. But it looks like you're using cygwin. Is there a reason not to use the prebuilt cygwin gnutls packages? http://cygwin.com/packages/gnutls/ Also, GnuTLS 2.2 is fairly old. You might prefer a more recent version. Please make sure that you track the project, though, as the current security advisory dust settles. Regards, --dkg From dkg at fifthhorseman.net Tue Nov 11 23:49:51 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 11 Nov 2008 17:49:51 -0500 Subject: [Help-gnutls] GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A756E11D9@yugi.mocana.local> (Rajitha Reddy's message of "Tue\, 11 Nov 2008 14\:17\:57 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <87bpwlvrul.fsf@squeak.fifthhorseman.net> <50DADDE6B33B1B47904E685AAFDC18241A756E11D9@yugi.mocana.local> Message-ID: <87iqqtop2o.fsf@squeak.fifthhorseman.net> On Tue 2008-11-11 17:17:57 -0500, Rajitha Reddy wrote: > Yes, I am using Cygwin. Can I install it on linux if that's easier? Yes, Linux would be easier! Most GNU/Linux distributions either ship with GnuTLS packages already installed, or they are easy to fetch from the distribution's package manager. For example, on Debian-derived distributions (such as Ubuntu), you can install the gnutls binary utilities with: aptitude install gnutls-bin If you want to develop code against gnutls, you'll probably want the development libraries, which you could fetch with: aptitude install libgnutls-dev There are probably similar commands/package names for redhat- or suse-based systems as well. > ar: /cygdrive/c/Documents: No such file or directory This looks to me like a problem with path names with spaces in them. /usr/bin/ar is looking for a file at "/cygdrive/c/Documents", though the full file is probably supposed to be somewhere inside: /cygdrive/c/Documents and Settings/Desktop/libgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src Can you try rebuilding the package from a directory without spaces in the path? I'm sorry i'm not more help; i haven't had to fuss with cygwin in several years. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From RReddy at mocana.com Wed Nov 12 00:16:12 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Tue, 11 Nov 2008 15:16:12 -0800 Subject: [Help-gnutls] GNU TLS 2.2.4 installation In-Reply-To: <87iqqtop2o.fsf@squeak.fifthhorseman.net> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <87bpwlvrul.fsf@squeak.fifthhorseman.net> <50DADDE6B33B1B47904E685AAFDC18241A756E11D9@yugi.mocana.local> <87iqqtop2o.fsf@squeak.fifthhorseman.net> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A756E11E8@yugi.mocana.local> Thank you Daniel. I will try to install it on Linux now. Thanks, Rajitha. -----Original Message----- From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] Sent: Tuesday, November 11, 2008 2:50 PM To: Rajitha Reddy Cc: GnuTLS mailing list Subject: Re: [Help-gnutls] GNU TLS 2.2.4 installation On Tue 2008-11-11 17:17:57 -0500, Rajitha Reddy wrote: > Yes, I am using Cygwin. Can I install it on linux if that's easier? Yes, Linux would be easier! Most GNU/Linux distributions either ship with GnuTLS packages already installed, or they are easy to fetch from the distribution's package manager. For example, on Debian-derived distributions (such as Ubuntu), you can install the gnutls binary utilities with: aptitude install gnutls-bin If you want to develop code against gnutls, you'll probably want the development libraries, which you could fetch with: aptitude install libgnutls-dev There are probably similar commands/package names for redhat- or suse-based systems as well. > ar: /cygdrive/c/Documents: No such file or directory This looks to me like a problem with path names with spaces in them. /usr/bin/ar is looking for a file at "/cygdrive/c/Documents", though the full file is probably supposed to be somewhere inside: /cygdrive/c/Documents and Settings/Desktop/libgcrypt-1.2.0.tar/libgcrypt-1.2.0/libgcrypt-1.2.0/src Can you try rebuilding the package from a directory without spaces in the path? I'm sorry i'm not more help; i haven't had to fuss with cygwin in several years. --dkg From simon at josefsson.org Wed Nov 12 10:03:05 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 12 Nov 2008 10:03:05 +0100 Subject: [Help-gnutls] Re: GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> (Rajitha Reddy's message of "Tue, 11 Nov 2008 13:48:32 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> Message-ID: <873ahxtiye.fsf@mocca.josefsson.org> Rajitha Reddy writes: > (cd .libs/libgcrypt.lax/libcipher.a && ar x /cygdrive/c/Documents and > Settings Libtool doesn't support building from directory names that contains the space character, even under GNU/Linux. You need to build it in a directory without SPC in it. /Simon From simon at josefsson.org Wed Nov 12 10:06:38 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 12 Nov 2008 10:06:38 +0100 Subject: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: <87fxlyudz3.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 11 Nov 2008 16:53:04 -0500") References: <200811080017.mA80HLx29355@f7.net> <87abc76cof.fsf@mocca.josefsson.org> <87fxlyudz3.fsf@squeak.fifthhorseman.net> Message-ID: <87y6zps481.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > In that case, the distinction between "shell" and "chain" models would be: > > * the chain model implies that the period of validity for an X.509 > certificate is simply the validity period contained in the > certificate. > > * the shell model implies that the period of validity for an X.509 > certificate is the intersection of the validity period in the > certificate and the validity period of the CA's certificate. > > The former is simpler to implement, but the latter seems more solidly > secure. > > Why would a CA need to grant a certificate whose duration was longer > than the CA's own expiration date, unless the CA was extending its own > certificate? And if it wants to extend itself: do we (as users) want > "trusted" root CAs to be able to unilaterally extend their own > expiration date? > > I'd be interested in seeing any other references to these models that > might shed more light, as i'm still not sure i understand the > distinctions. When trusting a CA certificate, I don't think the expiry date in that certificate matters -- you are only trusting that the public key corresponds to the CA. This is illustrated by older X.509 implementations that accepted trust CA's not encoded as certificates but just public keys and issuer name. Nowadays I think everyone requires a proper X.509 certificate even for the trusted CA's, to be able to validate various X.509 extension limitations. /Simon From simon at josefsson.org Wed Nov 12 11:24:10 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 12 Nov 2008 11:24:10 +0100 Subject: [Help-gnutls] Re: OpenLDAP related flaw in GnuTLS In-Reply-To: <568891.16563.qm@web95415.mail.in2.yahoo.com> (Bejoy Abraham Mathews's message of "Wed, 12 Nov 2008 15:41:45 +0530 (IST)") References: <568891.16563.qm@web95415.mail.in2.yahoo.com> Message-ID: <8763mts0mt.fsf@mocca.josefsson.org> I'm moving this to help-gnutls at gnu.org as it isn't really developer related. Bejoy Abraham Mathews writes: > Hi > > I > have been trying to setup OpenLDAP+GnuTLS. But not that successful. > Could someone guide me on this or some link? In the meanwhile I am > trying my best to set it up still... I haven't used OpenLDAP with GnuTLS, so I cannot help. If you post what kind of GnuTLS-related problems you have, we could try to help. > Hope these two complaints on gnutls, have been looked into, in the latest versions > 1. http://www.openldap.org/lists/openldap-devel/200802/msg00072.html Yes, this was addressed in v2.6.0 by adding gnutls_x509_crt_set_subject_alt_name. OpenLDAP needs to be modified to use it though. > 2. http://rustykruffle.com/2008/07/17/ultimate-home-server-ldap-gnutls-nightmare/. I didn't find any concrete problem in that article... /Simon From simon at josefsson.org Wed Nov 12 15:45:34 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 12 Nov 2008 15:45:34 +0100 Subject: [Help-gnutls] GnuTLS 2.6.2 - Brown paper bag release Message-ID: <87myg5ove9.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.6.2. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Version 2.6.2 is a maintenance release on our stable branch. * Version 2.6.2 (released 2008-11-12) ** libgnutls: Fix crash in X.509 validation code for self-signed certificates. The patch to fix the security problem GNUTLS-SA-2008-3 introduced a problem for certificate chains that contained just one self-signed certificate. Reported by Michael Meskes in . ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.9MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.2.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.2.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.2.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.2.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.6.2.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 2c7701b61c86d5cec8305f8741bc18bc64f33b31 gnutls-2.6.2.tar.bz2 7783486a33d91eb4872c8f9a51f91bdc928651b6e2d4a0ffb656cb87 gnutls-2.6.2.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer uses libgpg-error v1.6, libgcrypt v1.4.3, libtasn1 v1.5, and GnuTLS v2.6.2. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.6.2.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.6.2.exe.sig The checksum values for SHA-1 and SHA-224 are: 5f870f13d96965669598917b82f531825dcc6810 gnutls-2.6.2.exe d2b9b3a153ed45d1262fe38217e3c40dd04500e654b3cbb0f8ce3107 gnutls-2.6.2.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.2-1_all.deb The checksum values for SHA-1 and SHA-224 are: 577d2d9df6d0de1b2cd0bca152ad9b3f0f75d171 mingw32-gnutls_2.6.2-1_all.deb f7342095ba15f9b6c9c3176b27ba3491548bef33d32dffe780b20788 mingw32-gnutls_2.6.2-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Security Patch ============== The following patch can be used if you use releases older than v2.6.1, or if you don't want to upgrade to v2.6.2. It fixes the GNUTLS-SA-2008-3 aka CVE-2008-4989 vulnerability and the crash that was triggered by the patch used to fix the vulnerability in v2.6.1. The patch was created against v2.6.0. --- lib/x509/verify.c- 2008-11-12 15:39:53.000000000 +0100 +++ lib/x509/verify.c 2008-11-12 15:40:18.000000000 +0100 @@ -412,17 +412,6 @@ } #endif - /* Check if the last certificate in the path is self signed. - * In that case ignore it (a certificate is trusted only if it - * leads to a trusted party by us, not the server's). - */ - if (gnutls_x509_crt_check_issuer (certificate_list[clist_size - 1], - certificate_list[clist_size - 1]) > 0 - && clist_size > 0) - { - clist_size--; - } - /* Verify the certificate path (chain) */ for (i = clist_size - 1; i > 0; i--) Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From RReddy at mocana.com Wed Nov 12 17:45:17 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Wed, 12 Nov 2008 08:45:17 -0800 Subject: [Help-gnutls] RE: GNU TLS 2.2.4 installation In-Reply-To: <873ahxtiye.fsf@mocca.josefsson.org> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> Thank you. I have built it on Linux with latest versions of gnutls. Libcyrpt and libpgerror. It went through fine. Although, I got an error when doing a "make check " on gnutls. But, "make install" on gnutls did go through fine. ====================================================================================== PKCS8 OK enc2pkcs8.pem baz PKCS8 DONE (rc 0) PASS: pkcs8 ================== All 1 tests passed ================== make[3]: Leaving directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs8-decode' make[2]: Leaving directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs8-decode' Making check in pkcs12-decode make[2]: Entering directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' make pkcs12_s2k \ pkcs12 make[3]: Entering directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../lgl -I../../lgl -I./.. -I../../gl -I../../gl -I../../includes -I../../includes -I../../lib -I../../doc/examples -pipe -I/usr/local/include -g -O2 -Wno-pointer-sign -MT pkcs12_s2k.o -MD -MP -MF .deps/pkcs12_s2k.Tpo -c -o pkcs12_s2k.o pkcs12_s2k.c In file included from ../../lib/gnutls_int.h:142, from pkcs12_s2k.c:30: ../../lib/gnutls_mpi.h:29:23: error: libtasn1.h: No such file or directory In file included from ../../lib/gnutls_cert.h:30, from ../../lib/gnutls_int.h:268, from pkcs12_s2k.c:30: ../../lib/x509/x509_int.h:40: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:45: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:51: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:56: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:107: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:126: error: expected ')' before 'cert' ../../lib/x509/x509_int.h:130: error: expected ')' before 'src' ../../lib/x509/x509_int.h:146: error: expected ')' before 'asn1_struct' ../../lib/x509/x509_int.h:150: error: expected ')' before 'asn1_struct' ../../lib/x509/x509_int.h:155: error: expected ')' before 'asn1_struct' ../../lib/x509/x509_int.h:159: error: expected ')' before 'asn1_struct' ../../lib/x509/x509_int.h:177: error: expected '=', ',', ';', 'asm' or '__attribute__' before '_gnutls_privkey_decode_pkcs1_rsa_key' ../../lib/x509/x509_int.h:179: error: expected ')' before '*' token ../../lib/x509/x509_int.h:241: error: expected ')' before 'node' ../../lib/x509/x509_int.h:246: error: expected ')' before 'node' ../../lib/x509/x509_int.h:248: error: expected ')' before 'node' ../../lib/x509/x509_int.h:250: error: expected ')' before 'node' ../../lib/x509/x509_int.h:253: error: expected ')' before 'dst' In file included from ../../lib/gnutls_cert.h:30, from ../../lib/gnutls_int.h:268, from pkcs12_s2k.c:30: ../../lib/x509/x509_int.h:262: error: expected specifier-qualifier-list before 'ASN1_TYPE' ../../lib/x509/x509_int.h:320: error: expected declaration specifiers or '...' before 'ASN1_TYPE' make[3]: *** [pkcs12_s2k.o] Error 1 make[3]: Leaving directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests' make: *** [check-recursive] Error 1 [gnutls-2.6.0]# ====================================================================================== Will this be a problem? Also, I checked for gnutls under /usr/include. There isn't any. Can you please advise? I guess I can just start gnutls-cli from gnutls2.6.0/src isn't? Thanks, Rajitha. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Wednesday, November 12, 2008 1:03 AM To: Rajitha Reddy Cc: help-gnutls at gnu.org Subject: Re: GNU TLS 2.2.4 installation Rajitha Reddy writes: > (cd .libs/libgcrypt.lax/libcipher.a && ar x /cygdrive/c/Documents and > Settings Libtool doesn't support building from directory names that contains the space character, even under GNU/Linux. You need to build it in a directory without SPC in it. /Simon From michael at weiser.dinsnail.net Wed Nov 12 23:14:42 2008 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Wed, 12 Nov 2008 23:14:42 +0100 Subject: [Help-gnutls] Recognising error codes with an unsigned size_t Message-ID: <20081112221442.GC2097@weiser.dinsnail.net> Hello, I'm writing a small program using gnutls and its gnutls_record_{recv,send}() interface. They return a size_t which holds either the number of bytes transferred or a negative error code. But on Mac OS X size_t is an unsigned long which gives me grief when trying to recognise an error code as such. For a simple read() call this is straightforward to fix: Instead of if (bytes < 0) I now use if (bytes == -1) Obviously this doesn't work for gnutls error codes which may range from -1 to -65500. Something like if ((signed long)bytes < 0) seems just as wrong to me. Am I missing the obvious here? -- Thanks, Micha From sschaeffner at hotmail.com Thu Nov 13 08:11:59 2008 From: sschaeffner at hotmail.com (Scott Schaeffner) Date: Thu, 13 Nov 2008 07:11:59 +0000 Subject: [Help-gnutls] Is gnutls using the shell model or the chain model for a certificate validation Message-ID: I meanwhile found a reference that uses the shell model validation without naming it explicitly as shell model. Document rfc5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" explains in section 6 the "Certification Path Validation". Section 6.1.3. (a)(2) states that the timestamp of the validation(system date) has to be within the validity period of all certificates in the validation path. It uses the validation method that was named "shell model" in the referenced presentation. Currently I do not have any references concerning the "chain" validation model, however as the presentation was made by the Bundesnetzagentur which is a state agency in Germany, I guess it is used. The general question for us was which validation model shall we use for our implementation. We will go for the shell model that is also used in the rfc5280. Thanks for all the comments concerning this issue. _________________________________________________________________ Connect to the next generation of MSN Messenger? http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Thu Nov 13 09:32:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Nov 2008 09:32:21 +0100 Subject: [Help-gnutls] Re: GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> (Rajitha Reddy's message of "Wed, 12 Nov 2008 08:45:17 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> Message-ID: <873ahwowkq.fsf@mocca.josefsson.org> Rajitha Reddy writes: > Thank you. I have built it on Linux with latest versions of gnutls. Libcyrpt and libpgerror. It went through fine. Although, I got an error when doing a "make check " on gnutls. But, "make install" on gnutls did go through fine. ... > make[3]: Entering directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' ... > ../../lib/gnutls_mpi.h:29:23: error: libtasn1.h: No such file or directory In file included from ../../lib/gnutls_cert.h:30, This problem should be fixed in v2.6.2, try it instead. You could also install libtasn1 manually before building gnutls. /Simon From simon at josefsson.org Thu Nov 13 09:33:48 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Nov 2008 09:33:48 +0100 Subject: [Help-gnutls] Re: Recognising error codes with an unsigned size_t In-Reply-To: <20081112221442.GC2097@weiser.dinsnail.net> (Michael Weiser's message of "Wed, 12 Nov 2008 23:14:42 +0100") References: <20081112221442.GC2097@weiser.dinsnail.net> Message-ID: <87y6zonhxv.fsf@mocca.josefsson.org> Michael Weiser writes: > Hello, > > I'm writing a small program using gnutls and its gnutls_record_{recv,send}() > interface. They return a size_t which holds either the number of bytes > transferred or a negative error code. No, they return a ssize_t. > But on Mac OS X size_t is an unsigned long which gives me grief when > trying to recognise an error code as such. > > For a simple read() call this is straightforward to fix: Instead of > > if (bytes < 0) > > I now use > > if (bytes == -1) > > Obviously this doesn't work for gnutls error codes which may range from > -1 to -65500. Something like > > if ((signed long)bytes < 0) > > seems just as wrong to me. Am I missing the obvious here? I think you are using the wrong type for the 'bytes' variable, use 'ssize_t' which is guaranteed to be signed. Then the '< 0' comparison should work. /Simon From simon at josefsson.org Thu Nov 13 09:35:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Nov 2008 09:35:37 +0100 Subject: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: (Scott Schaeffner's message of "Thu, 13 Nov 2008 07:11:59 +0000") References: Message-ID: <87tzacnhuu.fsf@mocca.josefsson.org> Scott Schaeffner writes: > I meanwhile found a reference that uses the shell model validation without naming it explicitly as shell model. > Document rfc5280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" explains in section 6 the "Certification Path Validation". > > Section 6.1.3. (a)(2) states that the timestamp of the validation(system date) has to be within the validity period of all certificates in the validation path. > > It uses the validation method that was named "shell model" in the referenced presentation. Currently I do not have any references concerning the "chain" validation model, however as the presentation was made by the Bundesnetzagentur which is a state agency in Germany, I guess it is used. > > The general question for us was which validation model shall we use for our implementation. We will go for the shell model that is also used in the rfc5280. I think using the RFC 5280 algorithm won't be a bad choice. At least you can point at the RFC authors when someone discovers a logical flaw in it. ;) /Simon From simon at josefsson.org Thu Nov 13 09:37:52 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 13 Nov 2008 09:37:52 +0100 Subject: [Help-gnutls] Re: OpenLDAP related flaw in GnuTLS In-Reply-To: <977606.4482.qm@web95402.mail.in2.yahoo.com> (Bejoy Abraham Mathews's message of "Wed, 12 Nov 2008 22:32:58 +0530 (IST)") References: <977606.4482.qm@web95402.mail.in2.yahoo.com> Message-ID: <87myg4nhr3.fsf@mocca.josefsson.org> I'm adding the help-gnutls at gnu.org list to the discussion. Bejoy Abraham Mathews writes: > This is the output from "slapd -d -1" > > tls_read: want=5, got=0 > > TLS: can't accept: A TLS packet with unexpected length was received.. > connection_read(13): TLS accept failure error=-1 id=1, closing > connection_closing: readying conn=1 sd=13 for close > connection_close: conn=1 sd=13 > daemon: removing 13 > conn=1 fd=13 closed (TLS negotiation failure) Is there any way to enable GnuTLS debugging in OpenLDAP? We need more information to debug this. What client is connecting to your slapd server above? Are you sure the client is configured properly? What error messages does the client print? /Simon > > > > > > ________________________________ > From: Bejoy Abraham Mathews > To: Simon Josefsson > Sent: Wednesday, 12 November, 2008 8:02:10 PM > Subject: Re: OpenLDAP related flaw in GnuTLS > > > I don't find any errors in compilation of OpenLDAP using --with-tls=gnutls. But I don't know to read the StartTLS option. It is not reading the certificates. Showing TLS handshake error :( > > > > > ________________________________ > From: Bejoy Abraham Mathews > To: Simon Josefsson > Sent: Wednesday, 12 November, 2008 6:12:01 PM > Subject: Re: OpenLDAP related flaw in GnuTLS > > > Thanks for the advice Simon. I tried sending to it straight in the beginning - but that mail got rejected. Anyway, when I do get a solution - I will send one straight CCg you. > > With Regards > Bejoy > > > > > ________________________________ > From: Simon Josefsson > To: Bejoy Abraham Mathews > Sent: Wednesday, 12 November, 2008 5:01:14 PM > Subject: Re: OpenLDAP related flaw in GnuTLS > > Bejoy Abraham Mathews writes: > >> thanks Simon. You can close this thread. I'll add to this thread as a >> solution when I get gnutls properly running with certificates. > > Others may have similar questions as you had, so posting what you find > to the list can be useful. > >> I'm not member of help-gnutls at gnu.org yet. > > It is moderated, so you can send to it even if you are not a member. > > /Simon > > ________________________________ > Add more friends to your messenger and enjoy! Invite them now. > ________________________________ > Add more friends to your messenger and enjoy! Invite them now. > > > Bring your gang together. Do your thing. Find your favourite Yahoo! group at http://in.promos.yahoo.com/groups/ From dkg at fifthhorseman.net Thu Nov 13 16:26:46 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Nov 2008 10:26:46 -0500 Subject: [Help-gnutls] Respecting the validity period of Root CA certificates [was: Re: Is gnutls using the shell model or the chain model for a certificate validation] In-Reply-To: <87y6zps481.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 12 Nov 2008 10\:06\:38 +0100") References: <200811080017.mA80HLx29355@f7.net> <87abc76cof.fsf@mocca.josefsson.org> <87fxlyudz3.fsf@squeak.fifthhorseman.net> <87y6zps481.fsf@mocca.josefsson.org> Message-ID: <87wsf7lk95.fsf_-_@squeak.fifthhorseman.net> On Wed 2008-11-12 04:06:38 -0500, Simon Josefsson wrote: > When trusting a CA certificate, I don't think the expiry date in that > certificate matters -- you are only trusting that the public key > corresponds to the CA. On Thu 2008-11-13 02:11:59 -0500, Scott Schaeffner wrote: > Document rfc5280 "Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile" explains > in section 6 the "Certification Path Validation". > > Section 6.1.3. (a)(2) states that the timestamp of the > validation(system date) has to be within the validity period of all > certificates in the validation path. The trusted root CA's certificate is the last (or first, depending on your perspective) cert in the validation path. It seems to me that Scott's find suggests that the validity period of the root certificate *is* relevant. On Wed 2008-11-12 04:06:38 -0500, Simon Josefsson wrote: > This is illustrated by older X.509 implementations that accepted > trust CA's not encoded as certificates but just public keys and > issuer name. Nowadays I think everyone requires a proper X.509 > certificate even for the trusted CA's, to be able to validate > various X.509 extension limitations. I think that those older X.509 implementations were simply incomplete. Now that we're requiring proper X.509 certificates for root authorities, we should not ignore the additional semantic content in those certificates. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nmav at gnutls.org Thu Nov 13 19:30:30 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Nov 2008 20:30:30 +0200 Subject: [Help-gnutls] Re: Is gnutls using the shell model or the chain model for a certificate validation In-Reply-To: <87tzacnhuu.fsf@mocca.josefsson.org> References: <87tzacnhuu.fsf@mocca.josefsson.org> Message-ID: <491C7246.7050506@gnutls.org> Simon Josefsson wrote: > I think using the RFC 5280 algorithm won't be a bad choice. At least > you can point at the RFC authors when someone discovers a logical flaw > in it. ;) Only for a logical flaw. Implementation flaw is much more easy on an algorithm like that. regards, Nikos From michael at weiser.dinsnail.net Thu Nov 13 21:00:22 2008 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Thu, 13 Nov 2008 21:00:22 +0100 Subject: [Help-gnutls] Re: Recognising error codes with an unsigned size_t In-Reply-To: <87y6zonhxv.fsf@mocca.josefsson.org> References: <20081112221442.GC2097@weiser.dinsnail.net> <87y6zonhxv.fsf@mocca.josefsson.org> Message-ID: <20081113200022.GA319@weiser.dinsnail.net> On Thu, Nov 13, 2008 at 09:33:48AM +0100, Simon Josefsson wrote: > > I'm writing a small program using gnutls and its gnutls_record_{recv,send}() > > interface. They return a size_t which holds either the number of bytes > > transferred or a negative error code. > No, they return a ssize_t. > > seems just as wrong to me. Am I missing the obvious here? > I think you are using the wrong type for the 'bytes' variable, use > 'ssize_t' which is guaranteed to be signed. Then the '< 0' comparison > should work. Cheers. That was the obvious I was missing. With ssize_t's it works nicely now. -- Michael From michael at weiser.dinsnail.net Thu Nov 13 21:30:20 2008 From: michael at weiser.dinsnail.net (Michael Weiser) Date: Thu, 13 Nov 2008 21:30:20 +0100 Subject: [Help-gnutls] possible memory leak in _gnutls_free_auth_info() Message-ID: <20081113203020.GA877@weiser.dinsnail.net> Hello, I think I found a memory leak with PSK authentication. After one successful gnutls_handshake on a fresh session, the leaks tool on my Mac reports the memory leaks shown below (edited for readability). I tracked this to a missing case for GNUTLS_CRD_PSK in _gnutls_free_auth_info() and fixed it using the attached patch. It's against 2.6.0 but applies cleanly to 2.6.2. before: michael at esgaroth:~ # leaks 93514 Process 93514: 4074 nodes malloced for 104 KB Process 93514: 4 leaks for 592 total leaked bytes. Leak: 0x31c540 size=304 string 'michael' Call stack: [thread 0xa03b9fa0]: | start | main | gnutls_handshake | _gnutls_handshake_server | _gnutls_send_server_kx_message | gen_psk_server_kx | _gnutls_auth_info_set | calloc | malloc_zone_calloc Leak: 0x31c6f0 size=144 Call stack: [thread 0xa03b9fa0]: | start | main | gnutls_handshake | _gnutls_handshake_server | _gnutls_send_server_kx_message | gen_psk_server_kx | _gnutls_dh_set_group | _gnutls_mpi_dprint_lz | malloc | malloc_zone_malloc Leak: 0x31ca80 size=128 Call stack: [thread 0xa03b9fa0]: | start | main | gnutls_handshake | _gnutls_handshake_server | _gnutls_recv_client_kx_message | proc_psk_client_kx | _gnutls_proc_dh_common_client_kx | _gnutls_dh_set_peer_public | _gnutls_mpi_dprint_lz | malloc | malloc_zone_malloc Leak: 0x300a20 size=16 string 'UUUUUUUUUUUUUUU' Call stack: [thread 0xa03b9fa0]: | start | main | gnutls_handshake | _gnutls_handshake_server | _gnutls_send_server_kx_message | gen_psk_server_kx | _gnutls_dh_set_group | _gnutls_mpi_dprint_lz | malloc | malloc_zone_malloc after: michael at esgaroth:~ # leaks 6276 Process 6276: 4070 nodes malloced for 104 KB Process 6276: 0 leaks for 0 total leaked bytes. -- Micha -------------- next part -------------- --- gnutls-2.6.0/lib/gnutls_auth.c.orig 2008-10-05 15:41:43.000000000 +0200 +++ gnutls-2.6.0/lib/gnutls_auth.c 2008-11-13 20:55:23.000000000 +0100 @@ -31,6 +31,8 @@ #include #include "auth_anon.h" +#include "auth_psk.h" + /* The functions here are used in order for authentication algorithms * to be able to retrieve the needed credentials eg public and private * key etc. @@ -342,6 +344,17 @@ break; + case GNUTLS_CRD_PSK: + { + psk_auth_info_t info = _gnutls_get_auth_info (session); + + if (info == NULL) + break; + + dh_info = &info->dh; + _gnutls_free_dh_info (dh_info); + } + break; default: return; From RReddy at mocana.com Thu Nov 13 22:32:36 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Thu, 13 Nov 2008 13:32:36 -0800 Subject: [Help-gnutls] RE: GNU TLS 2.2.4 installation In-Reply-To: <873ahwowkq.fsf@mocca.josefsson.org> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> Thanks for the information. I am trying to test my SSL Server on how it can handle the GNU TLS Client servername extension. Is this the file to be modified on the GNU TLS client to send servername extension? lib/gnutls_extensions.c thanks, Rajitha. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Thursday, November 13, 2008 12:32 AM To: Rajitha Reddy Cc: help-gnutls at gnu.org Subject: Re: GNU TLS 2.2.4 installation Rajitha Reddy writes: > Thank you. I have built it on Linux with latest versions of gnutls. Libcyrpt and libpgerror. It went through fine. Although, I got an error when doing a "make check " on gnutls. But, "make install" on gnutls did go through fine. ... > make[3]: Entering directory `/auto/users/rreddy/software/ssl/gnutls-2.6.0/tests/pkcs12-decode' ... > ../../lib/gnutls_mpi.h:29:23: error: libtasn1.h: No such file or directory In file included from ../../lib/gnutls_cert.h:30, This problem should be fixed in v2.6.2, try it instead. You could also install libtasn1 manually before building gnutls. /Simon From simon at josefsson.org Fri Nov 14 11:45:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 14 Nov 2008 11:45:47 +0100 Subject: [Help-gnutls] Re: GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> (Rajitha Reddy's message of "Thu, 13 Nov 2008 13:32:36 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> Message-ID: <87r65e37s4.fsf@mocca.josefsson.org> Rajitha Reddy writes: > Thanks for the information. > > I am trying to test my SSL Server on how it can handle the GNU TLS Client servername extension. > > Is this the file to be modified on the GNU TLS client to send servername extension? > lib/gnutls_extensions.c You don't have modify any source code to test it, just use the gnutls-cli tool like this: gnutls-cli -p 4711 your.server.org -d 4711 You'll see it send the extension if you see this: |<2>| EXT[a04e070]: Sending extension SERVER_NAME /Simon From RReddy at mocana.com Fri Nov 14 20:06:16 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Fri, 14 Nov 2008 11:06:16 -0800 Subject: [Help-gnutls] RE: GNU TLS 2.2.4 installation In-Reply-To: <87r65e37s4.fsf@mocca.josefsson.org> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A7860427B@yugi.mocana.local> Thanks Simon. So, the argument "your.server.org" is the name of my SSL server? Thanks, Rajitha. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Friday, November 14, 2008 2:46 AM To: Rajitha Reddy Cc: help-gnutls at gnu.org Subject: Re: GNU TLS 2.2.4 installation Rajitha Reddy writes: > Thanks for the information. > > I am trying to test my SSL Server on how it can handle the GNU TLS Client servername extension. > > Is this the file to be modified on the GNU TLS client to send servername extension? > lib/gnutls_extensions.c You don't have modify any source code to test it, just use the gnutls-cli tool like this: gnutls-cli -p 4711 your.server.org -d 4711 You'll see it send the extension if you see this: |<2>| EXT[a04e070]: Sending extension SERVER_NAME /Simon From RReddy at mocana.com Sat Nov 15 15:51:27 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Sat, 15 Nov 2008 06:51:27 -0800 Subject: [Help-gnutls] RE: GNU TLS 2.2.4 installation References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> Hi, Here is how I am calling the gnutls client: gnutls-cli -d 10000 -p 6443 testserver where testserver - name of the machine running the ssl server. 6443 - port on which the server is listening. Is this the right way of sending the servername extension to my ssl server? With this, I am seeing that the gnu cli shows the following in its output: |<2>| EXT[9dc5888]: Sending extension SERVER_NAME My doubt is: What is the difference between -srpusername and the field "testserver" in "gnutls-cli -d 10000 -p 6443 testserver" Thanks, Reddy. -----Original Message----- From: Rajitha Reddy Sent: Friday, November 14, 2008 11:06 AM To: 'Simon Josefsson' Cc: help-gnutls at gnu.org Subject: RE: GNU TLS 2.2.4 installation Thanks Simon. So, the argument "your.server.org" is the name of my SSL server? Thanks, Rajitha. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Friday, November 14, 2008 2:46 AM To: Rajitha Reddy Cc: help-gnutls at gnu.org Subject: Re: GNU TLS 2.2.4 installation Rajitha Reddy writes: > Thanks for the information. > > I am trying to test my SSL Server on how it can handle the GNU TLS Client servername extension. > > Is this the file to be modified on the GNU TLS client to send servername extension? > lib/gnutls_extensions.c You don't have modify any source code to test it, just use the gnutls-cli tool like this: gnutls-cli -p 4711 your.server.org -d 4711 You'll see it send the extension if you see this: |<2>| EXT[a04e070]: Sending extension SERVER_NAME /Simon From nmav at gnutls.org Sat Nov 15 16:49:06 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 15 Nov 2008 17:49:06 +0200 Subject: [Help-gnutls] possible memory leak in _gnutls_free_auth_info() In-Reply-To: <20081113203020.GA877@weiser.dinsnail.net> References: <20081113203020.GA877@weiser.dinsnail.net> Message-ID: <491EEF72.9030004@gnutls.org> Michael Weiser wrote: > Hello, > > I think I found a memory leak with PSK authentication. After one > successful gnutls_handshake on a fresh session, the leaks tool on my Mac > reports the memory leaks shown below (edited for readability). > I tracked this to a missing case for GNUTLS_CRD_PSK in > _gnutls_free_auth_info() and fixed it using the attached patch. It's > against 2.6.0 but applies cleanly to 2.6.2. Thank you for the trace and the patch. Applied! regards, Nikos From mike at reys.be Sat Nov 15 18:09:14 2008 From: mike at reys.be (mike at reys.be) Date: Sat, 15 Nov 2008 18:09:14 +0100 (CET) Subject: [Help-gnutls] Holiday Message-ID: <20081115170914.B423338E0869B@zulu.openminds.be> Hi, I'm on holiday till November 17th without proper access to e-mail. Mike Reys From simon at josefsson.org Sat Nov 15 18:08:45 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 15 Nov 2008 18:08:45 +0100 Subject: [Help-gnutls] Re: GNU TLS 2.2.4 installation In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> (Rajitha Reddy's message of "Sat, 15 Nov 2008 06:51:27 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> Message-ID: <87k5b4zzkx.fsf@mocca.josefsson.org> Rajitha Reddy writes: > Hi, > > Here is how I am calling the gnutls client: > > gnutls-cli -d 10000 -p 6443 testserver > > where > testserver - name of the machine running the ssl server. > 6443 - port on which the server is listening. > > Is this the right way of sending the servername extension to my ssl server? Yes. > With this, I am seeing that the gnu cli shows the following in its output: > > |<2>| EXT[9dc5888]: Sending extension SERVER_NAME Seems like it works then. > My doubt is: > > What is the difference between -srpusername and the field "testserver" in > > "gnutls-cli -d 10000 -p 6443 testserver" Testserver is a hostname, -srpusername indicates the username used with SRP authentication. The SRP username doesn't have anything to do with the hostname in the server name extension. /Simon From RReddy at mocana.com Mon Nov 17 06:15:31 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Sun, 16 Nov 2008 21:15:31 -0800 Subject: [Help-gnutls] RE: GNU TLS 2.2.4 installation In-Reply-To: <87k5b4zzkx.fsf@mocca.josefsson.org> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> <87k5b4zzkx.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A7860430F@yugi.mocana.local> Thanks Simon. That helps a lot. - Rajitha. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Saturday, November 15, 2008 9:09 AM To: Rajitha Reddy Cc: help-gnutls at gnu.org Subject: Re: GNU TLS 2.2.4 installation Rajitha Reddy writes: > Hi, > > Here is how I am calling the gnutls client: > > gnutls-cli -d 10000 -p 6443 testserver > > where > testserver - name of the machine running the ssl server. > 6443 - port on which the server is listening. > > Is this the right way of sending the servername extension to my ssl server? Yes. > With this, I am seeing that the gnu cli shows the following in its output: > > |<2>| EXT[9dc5888]: Sending extension SERVER_NAME Seems like it works then. > My doubt is: > > What is the difference between -srpusername and the field "testserver" in > > "gnutls-cli -d 10000 -p 6443 testserver" Testserver is a hostname, -srpusername indicates the username used with SRP authentication. The SRP username doesn't have anything to do with the hostname in the server name extension. /Simon From simon at josefsson.org Mon Nov 17 11:36:42 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 17 Nov 2008 11:36:42 +0100 Subject: [Help-gnutls] Libtasn1 1.7 Message-ID: <87r65avdtx.fsf@mocca.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by Shishi to handle Kerberos V5 packets. Version 1.7 (released 2008-11-17) - Add libtasn1-config for compatibility. Please stop use it as it will disappear in v2.0! Use standard AC_CHECK_FUNCS autoconf tests or pkg-config instead. - Read PKCS#12 blob as binary file, fixes self-tests under Mingw. - Fix use of __attribute__ ((deprecated)) to work on non-GCC (#106548). Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Here are the compressed sources (1.6MB): ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz http://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz.sig http://ftp.gnu.org/gnu/gnutls/libtasn1-1.7.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: 2d7bfe0d84f38a5450d8bab511eb1ec4036f18ec libtasn1-1.7.tar.gz ce004d130068664ec2b11dc291bec05b2ef98afc2d44257f7b6b7225 libtasn1-1.7.tar.gz Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From RReddy at mocana.com Mon Nov 17 21:16:05 2008 From: RReddy at mocana.com (Rajitha Reddy) Date: Mon, 17 Nov 2008 12:16:05 -0800 Subject: [Help-gnutls] GNU DTLS? In-Reply-To: <87k5b4zzkx.fsf@mocca.josefsson.org> References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> <87k5b4zzkx.fsf@mocca.josefsson.org> Message-ID: <50DADDE6B33B1B47904E685AAFDC18241A78604374@yugi.mocana.local> Hi, I am testing my ssl server with GNU TLS client. I am testing how my server processes the server name extension sent by the gnu tls client. The following part is the client hello extension that my ssl server received from GnuTLS client. It doesn't look right to me. It seems to contain the version number and perhaps a sequence number as well. 17 00 09 00 03 02 00 01 00 00 00 0c 00 0a 00 00 07 62 69 73 6f 6e 73 76 DTLS added the sequence number inside the hand shake message. Can you please let me know if there is a way to check if GNU DTLS is turned on? Thanks, Rajitha. From simon at josefsson.org Tue Nov 18 01:09:36 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 18 Nov 2008 01:09:36 +0100 Subject: [Help-gnutls] Re: GNU DTLS? In-Reply-To: <50DADDE6B33B1B47904E685AAFDC18241A78604374@yugi.mocana.local> (Rajitha Reddy's message of "Mon, 17 Nov 2008 12:16:05 -0800") References: <50DADDE6B33B1B47904E685AAFDC18241A756E11D6@yugi.mocana.local> <873ahxtiye.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A756E123B@yugi.mocana.local> <873ahwowkq.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A786041FE@yugi.mocana.local> <87r65e37s4.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A78604300@yugi.mocana.local> <87k5b4zzkx.fsf@mocca.josefsson.org> <50DADDE6B33B1B47904E685AAFDC18241A78604374@yugi.mocana.local> Message-ID: <87vdul3nen.fsf@mocca.josefsson.org> Rajitha Reddy writes: > Hi, > > I am testing my ssl server with GNU TLS client. I am testing how my server processes the server name extension sent by the gnu tls client. > > The following part is the client hello extension that my ssl server received from GnuTLS client. It doesn't look right to me. It seems to contain the version number and perhaps a sequence number as well. > > 17 00 09 00 03 02 00 01 00 00 00 0c 00 0a 00 00 > 07 62 69 73 6f 6e 73 76 > > DTLS added the sequence number inside the hand shake message. > > Can you please let me know if there is a way to check if GNU DTLS is turned on? GnuTLS doesn't support DTLS. /Simon From sschaeffner at hotmail.com Wed Nov 26 10:19:25 2008 From: sschaeffner at hotmail.com (Scott Schaeffner) Date: Wed, 26 Nov 2008 09:19:25 +0000 Subject: [Help-gnutls] Excluding specific cipher suites from being offered during the TLS handshake Message-ID: Hello, Our diameter server solution consists of a C++ diameter server and its stand-in counterpart implemented in Java, meaning that in case the C++ diameter server has an operational problem, the backup written in Java takes over as long as necessary. The C++ server utilizes GNU TLS functionality (currently version 2.2.5 using the openssl compatibility layer) for providing security for TCP communication and the one written in Java (version 1.5) uses the TLS functionality in JSSE. The sets of ciphersuites supported by these two libraries differ from each other. Since both diameter servers should provide (almost) identical diameter interface to a client, it should be possible to enable the same ciphersuites for both of the implementations. So should both offer the same set of ciphersuites to a Diameter client. Our problem in case of GNU TLS is that we are not able to exclude a specific ciphersuite (as in case of JSSE) before the TLS handshake, but only a set of ciphersuites corresponding to a cipher algorithm (or a key exchange algorithm or a MAC algorithm) by modifying the arrays cipher_priority, kx_priority and mac_priority accordingly, i.e. it does not seem to us possible for example to exclude the ciphersuite TLS_DHE_DSS_ARCFOUR_SHA1 but not TLS_RSA_ARCFOUR_SHA1. Does the current GNU TLS library (v. 2.2.5) provide a solution (that we have overlooked) ? Thanks a lot, Liisa & Scott _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: From sega01 at gmail.com Thu Nov 27 01:04:52 2008 From: sega01 at gmail.com (Teran McKinney) Date: Thu, 27 Nov 2008 00:04:52 +0000 Subject: [Help-gnutls] Alternate random device for certtool Message-ID: Hey, I am using Gnutls 2.6.2, but have had no luck generating certificates with certtool. I found that it uses /dev/random instead of /dev/urandom, which is too slow on my systems. I could try to produce more entropy, but I would prefer to use /dev/urandom. The man page indicates that certtool uses /dev/urandom by default, due to the --disable-quick-random option, however it is acting as the default. Could this be a bug, or is there a way to specify an alternative device file? Thanks, Teran (sega01) From dkg at fifthhorseman.net Thu Nov 27 18:27:26 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Nov 2008 12:27:26 -0500 Subject: [Help-gnutls] Alternate random device for certtool In-Reply-To: (Teran McKinney's message of "Thu\, 27 Nov 2008 00\:04\:52 +0000") References: Message-ID: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> On Wed 2008-11-26 19:04:52 -0500, Teran McKinney wrote: > I am using Gnutls 2.6.2, but have had no luck generating certificates > with certtool. I found that it uses /dev/random instead of > /dev/urandom How are you determining that it uses /dev/random? I'm using gnutls 2.6.2 from debian's experimental repository, and it seems to be pulling from /dev/urandom unless i pass it the --disable-quick-random flag. It does apparently check to make sure that /dev/random is readable, but it doesn't open the file unless it needs to: wt215 at squeak:~$ time strace certtool -p --outfile /dev/null 2>&1 | grep random access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 open("/dev/urandom", O_RDONLY) = 4 real 0m5.453s user 0m5.284s sys 0m0.020s wt215 at squeak:~$ time strace certtool -p --disable-quick-random --outfile /dev/null 2>&1 | grep random execve("/usr/bin/certtool", ["certtool", "-p", "--disable-quick-random", "--outfile", "/dev/null"], [/* 15 vars */]) = 0 access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 open("/dev/urandom", O_RDONLY) = 4 write(2, "This might take several minutes d"..., 88This might take several minutes depending on availability of randomness in /dev/random. open("/dev/random", O_RDONLY) = 5 real 1m5.935s user 0m4.668s sys 0m0.036s wt215 at squeak:~$ dpkg -l gnutls-bin libgnutls26 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii gnutls-bin 2.6.2-1 the GNU TLS library - commandline utilities ii libgnutls26 2.6.2-1 the GNU TLS library - runtime library wt215 at squeak:~$ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sega01 at gmail.com Thu Nov 27 19:02:05 2008 From: sega01 at gmail.com (Teran McKinney) Date: Thu, 27 Nov 2008 18:02:05 +0000 Subject: [Help-gnutls] Alternate random device for certtool In-Reply-To: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> References: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> Message-ID: Thanks for getting back to me. I previously checked which random device it was using with strace, but have done a couple additional tests since. sega01[~]$ time strace certtool -p --outfile /dev/null 2>&1 | grep random access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 open("/dev/urandom", O_RDONLY) = 4 open("/dev/random", O_RDONLY) = 5 real 0m32.772s user 0m0.234s sys 0m0.011s It opens urandom, but opens random afterwards and times out if it cannot get enough data from it. ie: select(6, [5], NULL, NULL, {3, 0}) = 0 (Timeout) I ssh into the systems that I would need to do this on, and most are headless. I noticed how easy it was to generate data for /dev/random by moving the mouse, but without it generating entropy is much more difficult. Grepping strace for random with the --disable-quick-random flag on gives the same two access lines and two open lines for the random devices, as well as the text about "This may take several minutes" which only comes up when that flag is used. I can also get the same speeds when using and not using the flag (with a consistent level of mouse-induced entropy), so I am quite sure that it is gathering most of the data from /dev/random instead of /dev/urandom. Perhaps Debian uses a patch for certtool? Thanks, Teran (sega01) PS: I have checked this with two different distributions, though one is a fork of the other (however it is quite different and completely rebuilt). I have the same effect on both. On Thu, Nov 27, 2008 at 17:27, Daniel Kahn Gillmor wrote: > On Wed 2008-11-26 19:04:52 -0500, Teran McKinney wrote: > >> I am using Gnutls 2.6.2, but have had no luck generating certificates >> with certtool. I found that it uses /dev/random instead of >> /dev/urandom > > How are you determining that it uses /dev/random? > > I'm using gnutls 2.6.2 from debian's experimental repository, and it > seems to be pulling from /dev/urandom unless i pass it the > --disable-quick-random flag. It does apparently check to make sure > that /dev/random is readable, but it doesn't open the file unless it > needs to: > > wt215 at squeak:~$ time strace certtool -p --outfile /dev/null 2>&1 | grep random > access("/dev/random", R_OK) = 0 > access("/dev/urandom", R_OK) = 0 > open("/dev/urandom", O_RDONLY) = 4 > > real 0m5.453s > user 0m5.284s > sys 0m0.020s > wt215 at squeak:~$ time strace certtool -p --disable-quick-random --outfile /dev/null 2>&1 | grep random > execve("/usr/bin/certtool", ["certtool", "-p", "--disable-quick-random", "--outfile", "/dev/null"], [/* 15 vars */]) = 0 > access("/dev/random", R_OK) = 0 > access("/dev/urandom", R_OK) = 0 > open("/dev/urandom", O_RDONLY) = 4 > write(2, "This might take several minutes d"..., 88This might take several minutes depending on availability of randomness in /dev/random. > open("/dev/random", O_RDONLY) = 5 > > real 1m5.935s > user 0m4.668s > sys 0m0.036s > wt215 at squeak:~$ dpkg -l gnutls-bin libgnutls26 > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) > ||/ Name Version Description > +++-==============-==============-============================================ > ii gnutls-bin 2.6.2-1 the GNU TLS library - commandline utilities > ii libgnutls26 2.6.2-1 the GNU TLS library - runtime library > wt215 at squeak:~$ > > --dkg > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > From simon at josefsson.org Thu Nov 27 19:01:19 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 27 Nov 2008 19:01:19 +0100 Subject: [Help-gnutls] Re: Alternate random device for certtool References: Message-ID: <87ej0xujyo.fsf@mocca.josefsson.org> "Teran McKinney" writes: > Hey, > > I am using Gnutls 2.6.2, but have had no luck generating certificates > with certtool. I found that it uses /dev/random instead of > /dev/urandom, which is too slow on my systems. I could try to produce > more entropy, but I would prefer to use /dev/urandom. The man page > indicates that certtool uses /dev/urandom by default, due to the > --disable-quick-random option, however it is acting as the default. > > Could this be a bug, or is there a way to specify an alternative device file? This is a mostly a libgcrypt issue. Which libgcrypt version are you using? With recent libgcrypt, I believe GnuTLS certtool uses /dev/urandom, like Daniel explained. /Simon From dkg at fifthhorseman.net Thu Nov 27 19:49:11 2008 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 27 Nov 2008 13:49:11 -0500 Subject: [Help-gnutls] Alternate random device for certtool In-Reply-To: (Teran McKinney's message of "Thu\, 27 Nov 2008 18\:02\:05 +0000") References: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> Message-ID: <87y6z5m2c8.fsf@squeak.fifthhorseman.net> On Thu 2008-11-27 13:02:05 -0500, Teran McKinney wrote: > I ssh into the systems that I would need to do this on, and most are > headless. I noticed how easy it was to generate data for /dev/random > by moving the mouse, but without it generating entropy is much more > difficult. Agreed! Sometimes running "find / >/dev/null" thrashes the disks enough to give a bit of randomness. But it would be nice if there was a clear place that documents ways to feed the entropy pool on headless machines. > PS: I have checked this with two different distributions, though one > is a fork of the other (however it is quite different and completely > rebuilt). I have the same effect on both. What distros are you testing this on, specifically? I suspect that Simon's suggestion about gcrypt versions is on the right track. I'm using 1.4.1-1 on debian lenny. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sega01 at gmail.com Thu Nov 27 20:10:55 2008 From: sega01 at gmail.com (Teran McKinney) Date: Thu, 27 Nov 2008 19:10:55 +0000 Subject: [Help-gnutls] Alternate random device for certtool In-Reply-To: <87y6z5m2c8.fsf@squeak.fifthhorseman.net> References: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> <87y6z5m2c8.fsf@squeak.fifthhorseman.net> Message-ID: I am using libgcrypt 1.4.3, and I'm quite cetain that all of Gnutls' libraries are up to date. Could this possibly a bug with not building without Linux capabilities support? I have been testing with Arch Linux, and more so, my fork of Arch Linux, Icadyptes. I noticed that libgpg-error was out of date (1.6 instead of 1.7), so I updated it and rebuilt libgcrypt; this had no effect. Here are some of the related buildscripts: ftp://icadyptes.go-beyond.org/icadyptes/abs/core/base/libgcrypt/PKGBUILD ftp://icadyptes.go-beyond.org/icadyptes/abs/core/lib/gnutls/PKGBUILD Thanks, Teran (sega01) On Thu, Nov 27, 2008 at 18:49, Daniel Kahn Gillmor wrote: >> I ssh into the systems that I would need to do this on, and most are >> headless. I noticed how easy it was to generate data for /dev/random >> by moving the mouse, but without it generating entropy is much more >> difficult. > > Agreed! Sometimes running "find / >/dev/null" thrashes the disks > enough to give a bit of randomness. But it would be nice if there was > a clear place that documents ways to feed the entropy pool on headless > machines. > >> PS: I have checked this with two different distributions, though one >> is a fork of the other (however it is quite different and completely >> rebuilt). I have the same effect on both. > > What distros are you testing this on, specifically? > > I suspect that Simon's suggestion about gcrypt versions is on the > right track. I'm using 1.4.1-1 on debian lenny. > > --dkg > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > > From nmav at gnutls.org Sat Nov 29 09:21:22 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 29 Nov 2008 10:21:22 +0200 Subject: [Help-gnutls] Alternate random device for certtool In-Reply-To: References: <87vdu9qdtt.fsf@squeak.fifthhorseman.net> <87y6z5m2c8.fsf@squeak.fifthhorseman.net> Message-ID: <4930FB82.2090603@gnutls.org> Teran McKinney wrote: > I am using libgcrypt 1.4.3, and I'm quite cetain that all of Gnutls' > libraries are up to date. Could this possibly a bug with not building > without Linux capabilities support? I have been testing with Arch > Linux, and more so, my fork of Arch Linux, Icadyptes. I noticed that > libgpg-error was out of date (1.6 instead of 1.7), so I updated it and > rebuilt libgcrypt; this had no effect. I CC to gcrypt-devel since this might be gcrypt related. Could it be that newer versions from 1.4.1 ignore the control: gcry_control (GCRYCTL_ENABLE_QUICK_RANDOM, 0); I upgraded to gcrypt 1.4.4 and I notice the same delay, and strace shows that /dev/random is being used even with this flag. output from gcrypt 1.4.1: nmav at crystal:~/cvs/gnutls/src$ time strace certtool -p --outfile /dev/null 2>&1 | grep random access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 open("/dev/urandom", O_RDONLY) = 4 real 0m1.220s user 0m1.136s sys 0m0.028s output from gcrypt 1.4.4: access("/dev/random", R_OK) = 0 access("/dev/urandom", R_OK) = 0 open("/dev/urandom", O_RDONLY) = 4 open("/dev/random", O_RDONLY) = 5 real 0m29.867s user 0m0.016s sys 0m0.016s regards, Nikos