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