From simon at josefsson.org  Wed Oct  1 16:06:37 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 01 Oct 2008 16:06:37 +0200
Subject: [Help-gnutls] Re: compiling without gnutls-extra
In-Reply-To: <589058.75214.qm__23939.7897189066$1222868293$gmane$org@web56202.mail.re3.yahoo.com>
	(vipul aggarwal's message of "Wed, 1 Oct 2008 02:39:25 -0700 (PDT)")
References: <589058.75214.qm__23939.7897189066$1222868293$gmane$org@web56202.mail.re3.yahoo.com>
Message-ID: <87tzbwcsuq.fsf@mocca.josefsson.org>

vipul aggarwal <vipul3aggarwal at yahoo.com> writes:

> Hi,
>
> We are using gnutls 1.6.3. I was wondering, if we can compile the
> gnutls without the gnutls-extra.  This is required because the
> gnutls-extra is under GPL and we want to remove the GPL component
> completely from the gnutls package.  And then we want to ship gnutls
> without gnutls-extra along with our product.
>
> So, what I want to know is that is there a way to compile the gnutls
> without the gnutls-extra?

Replace all calls to 'make' with a call to 'make -C lib install': then
libgnutls-extra (and the other GPLv2+ components such as the command
line tool in src/) will not be built or installed.

I suppose you could modify the top-level Makefile.in so that this
happens by default if you cannot modify the make-calls for some reason.

/Simon




From fweimer at bfk.de  Thu Oct  2 10:35:09 2008
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 02 Oct 2008 10:35:09 +0200
Subject: [Help-gnutls] gnutls with unix domain (local) sockets
In-Reply-To: <1222696099.2874.15.camel@sundaysister> (Lennart Koopmann's
	message of "Mon, 29 Sep 2008 15:48:19 +0200")
References: <7a9ca1180809290549v7050c7f9x80284ac72d749797@mail.gmail.com>
	<48E0D384.1010401@gnutls.org>
	<7a9ca1180809290644q1164694nd706c6819de24d2d@mail.gmail.com>
	<1222696099.2874.15.camel@sundaysister>
Message-ID: <82d4ij2y4i.fsf@mid.bfk.de>

* Lennart Koopmann:

> Am Montag, den 29.09.2008, 16:44 +0300 schrieb Arturo Martinez Rubio:
>> In my specific case, the applications which will communicate using TLS
>> are running in the same machine.
>
> Isn't TLS pretty useless if used for interprocess communication? Or does
> some kind of server that is running on the local machine require TLS?

Some applications use UNIX domain sockets in /tmp, where the identity
of the peer is less than clear.  It's been suggested to use TLS in
this scenario.

(Personally, I think using a separate directory, writable by the
appropriate user, is a better choice, perhaps combined with
credentials passing.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99




From vipul2.aggarwal at aricent.com  Thu Oct  2 16:31:51 2008
From: vipul2.aggarwal at aricent.com (Vipul2 Aggarwal)
Date: Thu, 2 Oct 2008 20:01:51 +0530
Subject: [Help-gnutls] compiling without gnutls-extra
Message-ID: <2644750229D3DC4896C04587BF628046021E616F03@GUREXMB01.ASIAN.AD.ARICENT.COM>

Hi,

We are using gnutls 1.6.3. I was wondering, if we can compile the gnutls without the gnutls-extra.
This is required because the gnutls-extra is under GPL and we want to remove the GPL component completely from the gnutls package.
And then we want to ship gnutls without gnutls-extra along with our product.

So, what I want to know is that is there a way to compile the gnutls without the gnutls-extra?

Thanks n Regds,

Vipul Aggarwal


Senior Software Engineer





A R I C E N T





The Presidency Tower-A


351/2, Sector 14, M.G Road


Gurgaon, 122001,  Haryana, India




________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081002/ddbc3fc8/attachment.htm>

From simon at josefsson.org  Thu Oct  2 18:13:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 02 Oct 2008 18:13:43 +0200
Subject: [Help-gnutls] Re: compiling without gnutls-extra
In-Reply-To: <2644750229D3DC4896C04587BF628046021E616F03@GUREXMB01.ASIAN.AD.ARICENT.COM>
	(Vipul's message of "Thu, 2 Oct 2008 20:01:51 +0530")
References: <2644750229D3DC4896C04587BF628046021E616F03@GUREXMB01.ASIAN.AD.ARICENT.COM>
Message-ID: <87ej2z0ybs.fsf@mocca.josefsson.org>

Vipul2 Aggarwal <vipul2.aggarwal at aricent.com> writes:

> Hi,
>
> We are using gnutls 1.6.3. I was wondering, if we can compile the gnutls without the gnutls-extra.
> This is required because the gnutls-extra is under GPL and we want to remove the GPL component completely from the gnutls package.
> And then we want to ship gnutls without gnutls-extra along with our product.
>
> So, what I want to know is that is there a way to compile the gnutls without the gnutls-extra?

Is this a duplicate?  I already answered the question before in:

http://permalink.gmane.org/gmane.network.gnutls.general/1379

/Simon




From pva at gentoo.org  Fri Oct  3 13:45:23 2008
From: pva at gentoo.org (Peter Volkov)
Date: Fri, 03 Oct 2008 15:45:23 +0400
Subject: [Help-gnutls] gnutls fails to verify server sertificate while
	openssl works
Message-ID: <1223034323.30303.29.camel@localhost>

Hello.

I found issue that while openssl works, gnutls-cli returns:

*** Verifying server certificate failed...

I've tried with gnutls 2.2.5 and 2.5.4.

Commands I've used to test and their outputs are in attachment.

I think this issue is rather important problem as it requires manual
intervention during the first build of Metasploit package in Gentoo:

Error validating server certificate for 'https://metasploit.com:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: metasploit.com
 - Valid: from Sun, 01 Apr 2007 22:02:24 GMT until Thu, 01 Apr 2010 22:02:24 GMT
 - Issuer: 07969287, http://certificates.godaddy.com/repository, GoDaddy.com, Inc., Scottsdale, Arizona, US
 - Fingerprint: 20:a7:2e:df:6d:53:10:6c:dc:2a:ca:33:fd:35:76:2c:0e:62:b1:4d
(R)eject, accept (t)emporarily or accept (p)ermanently?

Could you help me to find root issue? I have not attached ValiCert Class
2 certificate as I think it's installed on most systems. But if you need
that just ask me.

Thank you in advance.
-- 
Peter.
-------------- next part --------------
peter at camobap ~ $ /usr/bin/gnutls-cli -V --x509cafile /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt metasploit.com > gnutls-cli.out
Processed 1 CA certificate(s).
Resolving 'metasploit.com'...
Connecting to '216.75.15.231:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1032 bits
 - Secret key: 1023 bits
 - Peer's public key: 1024 bits
- Certificate type: X.509
 - Got a certificate list of 3 certificates.

 - Certificate[0] info:
 # The hostname in the certificate matches 'metasploit.com'.
 # valid since: Mon Apr  2 02:02:24 MSD 2007
 # expires at: Fri Apr  2 02:02:24 MSD 2010
 # serial number: 3F:C9:23
 # fingerprint: 80:7C:0A:A4:88:B8:53:D7:58:1D:66:3B:8C:16:9E:03
 # version: #3
 # public key algorithm: RSA (2048 bits)
 # e [24 bits]: 01:00:01
 # m [2048 bits]: AF:95:DD:5B:3C:33:EE:3C:0A:87:E3:CC:7E:4A:13:73:00:D4:29:9F:5E:1C:F6:BF:07:96:DF:1D:BB:4C:A8:59:07:16:CB:2F:15:4E:A6:76:C5:4F:17:DC:EA:00:F5:36:67:11:7C:14:72:46:E1:8D:72:59:30:9E:47:D0:67:86:1B:91:72:09:58:28:E8:BF:43:99:35:F6:13:34:E4:1B:0E:D7:59:3C:AF:6A:F7:88:7D:C0:75:10:3A:4A:57:97:59:3E:5D:EF:3E:81:5A:8B:8A:5A:9C:4B:58:A4:21:25:10:56:C2:81:61:AD:7C:15:A4:FF:3F:21:44:BF:4D:19:B1:EC:2D:7A:12:FA:0B:DA:17:0A:6F:35:1C:7D:92:FC:70:6E:F8:25:B5:4C:9D:D7:E4:BA:22:BE:CD:B8:69:1E:B9:77:3B:0A:16:11:B6:B6:7C:D4:C6:8C:74:46:0D:A2:C4:F5:2E:7B:CC:40:A1:31:AA:BA:E8:E6:CB:FD:1A:6B:AC:9E:4F:59:2C:C0:54:CB:9D:C4:CB:FC:62:F1:42:08:2D:6A:1F:6E:97:9D:29:61:05:91:2E:E4:CD:38:86:2C:8D:24:B7:DB:33:EC:D5:93:93:37:C4:64:0E:B7:42:98:45:8F:53:1A:F3:82:65:26:35:0C:CA:0E:F1:E3:56:9F
 # Subject's DN: O=metasploit.com,OU=Domain Control Validated,CN=metasploit.com
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287

 - Certificate[1] info:
 # valid since: Tue Jun 29 21:06:20 MSD 2004
 # expires at: Sat Jun 29 21:06:20 MSD 2024
 # serial number: 01:0D
 # fingerprint: 82:BD:9A:0B:82:6A:0E:3E:91:AD:3E:27:04:2B:3F:45
 # version: #3
 # public key algorithm: RSA (2048 bits)
 # e [8 bits]: 03
 # m [2048 bits]: DE:9D:D7:EA:57:18:49:A1:5B:EB:D7:5F:48:86:EA:BE:DD:FF:E4:EF:67:1C:F4:65:68:B3:57:71:A0:5E:77:BB:ED:9B:49:E9:70:80:3D:56:18:63:08:6F:DA:F2:CC:D0:3F:7F:02:54:22:54:10:D8:B2:81:D4:C0:75:3D:4B:7F:C7:77:C3:3E:78:AB:1A:03:B5:20:6B:2F:6A:2B:B1:C5:88:7E:C4:BB:1E:B0:C1:D8:45:27:6F:AA:37:58:F7:87:26:D7:D8:2D:F6:A9:17:B7:1F:72:36:4E:A6:17:3F:65:98:92:DB:2A:6E:5D:A2:FE:88:E0:0B:DE:7F:E5:8D:15:E1:EB:CB:3A:D5:E2:12:A2:13:2D:D8:8E:AF:5F:12:3D:A0:08:05:08:B6:5C:A5:65:38:04:45:99:1E:A3:60:60:74:C5:41:A5:72:62:1B:62:C5:1F:6F:5F:1A:42:BE:02:51:65:A8:AE:23:18:6A:FC:78:03:A9:4D:7F:80:C3:FA:AB:5A:FC:A1:40:A4:CA:19:16:FE:B2:C8:EF:5E:73:0D:EE:77:BD:9A:F6:79:98:BC:B1:07:67:A2:15:0D:DD:A0:58:C6:44:7B:0A:3E:62:28:5F:BA:41:07:53:58:CF:11:7E:38:74:C5:F8:FF:B5:69:90:8F:84:74:EA:97:1B:AF
 # Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
 # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info at valicert.com

 - Certificate[2] info:
 # valid since: Thu Nov 16 04:54:37 MSK 2006
 # expires at: Mon Nov 16 04:54:37 MSK 2026
 # serial number: 03:01
 # fingerprint: D5:DF:85:B7:9A:52:87:D1:8C:D5:0F:90:23:2D:B5:34
 # version: #3
 # public key algorithm: RSA (2048 bits)
 # e [24 bits]: 01:00:01
 # m [2048 bits]: C4:2D:D5:15:8C:9C:26:4C:EC:32:35:EB:5F:B8:59:01:5A:A6:61:81:59:3B:70:63:AB:E3:DC:3D:C7:2A:B8:C9:33:D3:79:E4:3A:ED:3C:30:23:84:8E:B3:30:14:B6:B2:87:C3:3D:95:54:04:9E:DF:99:DD:0B:25:1E:21:DE:65:29:7E:35:A8:A9:54:EB:F6:F7:32:39:D4:26:55:95:AD:EF:FB:FE:58:86:D7:9E:F4:00:8D:8C:2A:0C:BD:42:04:CE:A7:3F:04:F6:EE:80:F2:AA:EF:52:A1:69:66:DA:BE:1A:AD:5D:DA:2C:66:EA:1A:6B:BB:E5:1A:51:4A:00:2F:48:C7:98:75:D8:B9:29:C8:EE:F8:66:6D:0A:9C:B3:F3:FC:78:7C:A2:F8:A3:F2:B5:C3:F3:B9:7A:91:C1:A7:E6:25:2E:9C:A8:ED:12:65:6E:6A:F6:12:44:53:70:30:95:C3:9C:2B:58:2B:3D:08:74:4A:F2:BE:51:B0:BF:87:D0:4C:27:58:6B:B5:35:C5:9D:AF:17:31:F8:0B:8F:EE:AD:81:36:05:89:08:98:CF:3A:AF:25:87:C0:49:EA:A7:FD:67:F7:45:8E:97:CC:14:39:E2:36:85:B5:7E:1A:37:FD:16:F6:71:11:9A:74:30:16:FE:13:94:A3:3F:84:0D:4F
 # Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
 # Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority


- 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
- Session ID: 69:61:81:42:89:5B:BA:24:4F:12:0D:D9:F5:3E:B5:D1:87:EC:6E:43:4B:60:24:90:33:93:0A:0B:DA:90:3B:7D
*** Verifying server certificate failed...
-------------- next part --------------
peter at camobap ~ $ openssl s_client -CAfile /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt -connect metasploit.com:443 > openssl.out 2>&1
depth=3 /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com
verify return:1
depth=2 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
verify return:1
depth=1 /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
verify return:1
depth=0 /O=metasploit.com/OU=Domain Control Validated/CN=metasploit.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:/O=metasploit.com/OU=Domain Control Validated/CN=metasploit.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
 1 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 2 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info at valicert.com
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFdjCCBF6gAwIBAgIDP8kjMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJV
UzEQMA4GA1UECBMHQXJpem9uYTETMBEGA1UEBxMKU2NvdHRzZGFsZTEaMBgGA1UE
ChMRR29EYWRkeS5jb20sIEluYy4xMzAxBgNVBAsTKmh0dHA6Ly9jZXJ0aWZpY2F0
ZXMuZ29kYWRkeS5jb20vcmVwb3NpdG9yeTEwMC4GA1UEAxMnR28gRGFkZHkgU2Vj
dXJlIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MREwDwYDVQQFEwgwNzk2OTI4NzAe
Fw0wNzA0MDEyMjAyMjRaFw0xMDA0MDEyMjAyMjRaMFUxFzAVBgNVBAoTDm1ldGFz
cGxvaXQuY29tMSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxFzAV
BgNVBAMTDm1ldGFzcGxvaXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAr5XdWzwz7jwKh+PMfkoTcwDUKZ9eHPa/B5bfHbtMqFkHFssvFU6mdsVP
F9zqAPU2ZxF8FHJG4Y1yWTCeR9BnhhuRcglYKOi/Q5k19hM05BsO11k8r2r3iH3A
dRA6SleXWT5d7z6BWouKWpxLWKQhJRBWwoFhrXwVpP8/IUS/TRmx7C16EvoL2hcK
bzUcfZL8cG74JbVMndfkuiK+zbhpHrl3OwoWEba2fNTGjHRGDaLE9S57zEChMaq6
6ObL/RprrJ5PWSzAVMudxMv8YvFCCC1qH26XnSlhBZEu5M04hiyNJLfbM+zVk5M3
xGQOt0KYRY9TGvOCZSY1DMoO8eNWnwIDAQABo4IB1zCCAdMwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMFYGA1Ud
HwRPME0wS6BJoEeGRWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuZ29kYWRkeS5jb20vcmVw
b3NpdG9yeS9nb2RhZGR5ZXh0ZW5kZWRpc3N1aW5nLmNybDBSBgNVHSAESzBJMEcG
C2CGSAGG/W0BBxcBMDgwNgYIKwYBBQUHAgEWKmh0dHA6Ly9jZXJ0aWZpY2F0ZXMu
Z29kYWRkeS5jb20vcmVwb3NpdG9yeTB/BggrBgEFBQcBAQRzMHEwIwYIKwYBBQUH
MAGGF2h0dHA6Ly9vY3NwLmdvZGFkZHkuY29tMEoGCCsGAQUFBzAChj5odHRwOi8v
Y2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2RfaW50ZXJtZWRp
YXRlLmNydDAdBgNVHQ4EFgQUOSJKMN4LQ0ObaKhRV6thG4ta1vIwHwYDVR0jBBgw
FoAU/axhMpNsRdbi7oVfmrrndplozOcwLQYDVR0RBCYwJIIObWV0YXNwbG9pdC5j
b22CEnd3dy5tZXRhc3Bsb2l0LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAnFJumw5T
K3j3MBMtWTuU2gY9+kVZfzap99lK95OohqKcaFlmDnLz8K1JluT3L7K4JFa/SUIE
WQUkxa0QHZsl/t2hDOLyZtOh8BDU6Wx3Fkqf7ZSkB9OScOZPf3it4t847ZS2AASw
BetznjALeA8meoIBMdZxrAqV0NKuOm63YebW5sbxvuVPPpF9rS0MQI8m8EM4rwHQ
IFaT5UY+iAeWWjE0TPf7Wx8K9HV+k/Qlmb9pW5pYyUYSftuCmiBlFCHuMn+UDx9V
TwnMtYE5+Cdq2xAK4R5r1r8AxFJxINzus+2vxZxbqVyKVze3OH/3w1cGGsxVLtUY
EkHgdCQ0fcoHMQ==
-----END CERTIFICATE-----
subject=/O=metasploit.com/OU=Domain Control Validated/CN=metasploit.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.godaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287
---
No client certificate CA names sent
---
SSL handshake has read 4629 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 6FCDA1DEA5A5FA20DEC001B9A56DA17138A6B2DFC837A431E65B9DDB9C397C94
    Session-ID-ctx: 
    Master-Key: 7A367CC0186F7FD30A27254E034105002B6683E1BEE945D968B0F48120F43B025F7EEC40DE3CBB9B77E411D38BD4F211
    Key-Arg   : None
    Start Time: 1223033494
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
GET /
closed

From simon at josefsson.org  Fri Oct  3 17:51:45 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 03 Oct 2008 17:51:45 +0200
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while
	openssl works
In-Reply-To: <1223034323.30303.29.camel@localhost> (Peter Volkov's message of
	"Fri, 03 Oct 2008 15:45:23 +0400")
References: <1223034323.30303.29.camel@localhost>
Message-ID: <877i8pk772.fsf@mocca.josefsson.org>

Peter Volkov <pva at gentoo.org> writes:

> peter at camobap ~ $ /usr/bin/gnutls-cli -V --x509cafile /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt metasploit.com > gnutls-cli.out

The certificate chain returned by that server appears to be:

cert[0]
 # Subject's DN: O=metasploit.com,OU=Domain Control Validated,CN=metasploit.com
 # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287

cert[1]
 # Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
 # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info at valicert.com

cert[2]
 # Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
 # Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority

As far as I can tell, that isn't a valid certificate chain.  The issuer
of the first, end-entity, certificate isn't the subject of the middle
certificate in the chain.  It seems as if the final two certificates in
the chain are swapped.

According to RFC 4346 (earlier TLS specifications contains similar
wording):

   certificate_list
      This is a sequence (chain) of X.509v3 certificates.  The sender's
      certificate must come first in the list.  Each following
      certificate must directly certify the one preceding it.  Because
                  ^^^^
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority may optionally be omitted from the chain,
      under the assumption that the remote end must already possess it
      in order to validate it in any case.

So I'd say this is a server configuration error.

/Simon




From pva at gentoo.org  Sat Oct  4 11:59:57 2008
From: pva at gentoo.org (Peter Volkov)
Date: Sat, 04 Oct 2008 13:59:57 +0400
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while
	openssl works
In-Reply-To: <877i8pk772.fsf@mocca.josefsson.org>
References: <1223034323.30303.29.camel@localhost>
	<877i8pk772.fsf@mocca.josefsson.org>
Message-ID: <1223114397.12774.31.camel@localhost>

CC'ing openssl developers for their opinions, since I think this
behavior better to have consistent or configurable. Description of the
problem is here:

http://thread.gmane.org/gmane.network.gnutls.general/1383

? ???, 03/10/2008 ? 17:51 +0200, Simon Josefsson ?????:
> Peter Volkov <pva at gentoo.org> writes:
> > peter at camobap ~ $ /usr/bin/gnutls-cli -V \
>   --x509cafile /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt \
>     metasploit.com > gnutls-cli.out
> 
> The certificate chain returned by that server appears to be:
> 
> cert[0]
>  # Subject's DN: O=metasploit.com,OU=Domain Control Validated,CN=metasploit.com
>  # Issuer's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
> 
> cert[1]
>  # Subject's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
>  # Issuer's DN: L=ValiCert Validation Network,O=ValiCert\, Inc.,OU=ValiCert Class 2 Policy Validation Authority,CN=http://www.valicert.com/,EMAIL=info at valicert.com
> 
> cert[2]
>  # Subject's DN: C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com\, Inc.,OU=http://certificates.godaddy.com/repository,CN=Go Daddy Secure Certification Authority,serialNumber=07969287
>  # Issuer's DN: C=US,O=The Go Daddy Group\, Inc.,OU=Go Daddy Class 2 Certification Authority
> 
> As far as I can tell, that isn't a valid certificate chain.  The issuer
> of the first, end-entity, certificate isn't the subject of the middle
> certificate in the chain.  It seems as if the final two certificates in
> the chain are swapped.
> 
> According to RFC 4346 (earlier TLS specifications contains similar
> wording):
> 
>    certificate_list
>       This is a sequence (chain) of X.509v3 certificates.  The sender's
>       certificate must come first in the list.  Each following
>       certificate must directly certify the one preceding it.  Because
>                   ^^^^
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority may optionally be omitted from the chain,
>       under the assumption that the remote end must already possess it
>       in order to validate it in any case.
> 
> So I'd say this is a server configuration error.

Simon, I agree that this is configuration issue. But since openssl does
validates this chain and people use openssl to check server
configuration, I'm not sure what should be done here. Possibly openssl
should report about this wrong certificate chain. Or may be gnutls
should have option to warn but still validate this chain? Or may be
openssl should not validate such chains at all (seems best solution as
it's always good to follow RFC's)?


P.S. since both openssl and gnutls mailing lists require subscription
here are links to subscription forms:
http://lists.gnu.org/mailman/listinfo/help-gnutls
http://www.openssl.org/support/

-- 
Peter.





From simon at josefsson.org  Mon Oct  6 09:48:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Oct 2008 09:48:57 +0200
Subject: [Help-gnutls] GnuTLS 2.6.0
Message-ID: <87myhitb86.fsf@mocca.josefsson.org>

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

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
==========

Major end-user visible changes compared to the v2.4 branch:

** certtool: updated so it can add several subject alternative names using
the template file.

** opencdk: Parse (but not decrypt) encrypted secret keys.
Contributed by Daniel Kahn Gillmor <dkg at fifthhorseman.net>.

** libgnutls: Remove code to import certificate chains in PKCS#7 format.
The code has not worked since v0.9.0 and apparently nobody has missed
it, so we decided to remove the code rather than fix it.  If you have
old certificate chains stored in PKCS#7 format, you can convert them
to a list of PEM certificates by using 'certtool --p7-info'.  Reported
by Christian Grothoff <christian at grothoff.org>.

** gnutls-cli: Improve --list output to include public key and signature algs.

** gnutls-cli, gnutls-serv: Remove --copyright parameter.
Use standard --version to get license info.

** The main manual and the GTK-DOC API documentation have been improved.

** Uses autoconf 2.63, automake 1.10.1, libtool 2.2.6a.

Major developer visible changes compared to the v2.4 branch:

** Added API to replace and update the crypto backend.
The header gnutls/crypto.h is now officially supported, and declares
the symbols below.
gnutls_crypto_bigint_register2: ADDED.
gnutls_crypto_cipher_register2: ADDED.
gnutls_crypto_digest_register2: ADDED.
gnutls_crypto_mac_register2: ADDED.
gnutls_crypto_pk_register2: ADDED.
gnutls_crypto_rnd_register2: ADDED.
gnutls_crypto_single_cipher_register2: ADDED.
gnutls_crypto_single_digest_register2: ADDED.
gnutls_crypto_single_mac_register2: ADDED.

** libgnutls: gnutls_x509_crt_set_subject_alt_name() was added that can
either set or append alternative names. It can also handle binary structures
such as IP addresses.

** libgnutls: New function to set minimum acceptable SRP bits.
The function is gnutls_srp_set_prime_bits.  Tiny patch by Kevin Quick
<quick at sparq.org> in <https://savannah.gnu.org/support/index.php?106454>.

** libgnutls: Add interface to deal with public key and signature algorithms.
The functions are called gnutls_pk_list, gnutls_pk_get_id,
gnutls_sign_list, and gnutls_sign_get_id.  Suggested by Sam
Varshavchik <mrsam at courier-mta.com>.

** libgnutls: New interfaces to get name of public key and signing algorithms.
The functions are gnutls_sign_get_name and gnutls_pk_get_name.

** libgnutls: New API to get a string corresponding to a error symbol.
The function is gnutls_strerror_name.

** libgnutls: New API to set the public parameters in a certificate request
** from a private key.
The function is gnutls_x509_crq_set_key_rsa_raw.  Inspired by
discussion with "Zach C." <fxchip at gmail.com>.

** libgnutls: New API to set a callback to extract TLS Finished data.
The function to register is gnutls_session_set_finished_function and
it takes a callback of the gnutls_finished_callback_func type.

** libgnutls: Fix namespace problem with TLS_MASTER_SIZE and TLS_RANDOM_SIZE.
The new names are GNUTLS_MASTER_SIZE and GNUTLS_RANDOM_SIZE.  The old
names are mapped to the new names in compat.h.  These mappings will
likely be removed more quickly than other mappings in that file due to
the namespace violation.

** libgnutls: New interface to register a new TLS extension handler.
The new function gnutls_ext_register can be used to register handlers
for specific TLS extension types.  The callback functions have the new
types gnutls_ext_recv_func and gnutls_ext_send_func.  A type to
classify TLS extensions, gnutls_ext_parse_type_t, has been added as
well.

** Opencdk: Add calls to gnutls_assert to ease debugging.

** libgnutls-extra: Add function to work with Libgcrypt in FIPS mode.
The function is gnutls_register_md5_handler.  When libgcrypt is in
FIPS mode, MD5 is disabled, but TLS normally requires use of MD5 in
the PRF.

Of course, many smaller fixes have been made, see the ChangeLog file.

API/ABI changes in GnuTLS 2.6
=============================

No functions have been removed or modified.  The library should be
fully backwards compatible on both the source and binary level.

A new header file <gnutls/crypto.h> have been added.  It contains
definitions related to replacing the internal crypto functionality.
All definitions and the header itself is experimental but supported.

We have realized that the symbols TLS_MASTER_SIZE and TLS_RANDOM_SIZE
does not use the normal namespace.  We have added GNUTLS_MASTER_SIZE
and GNUTLS_RANDOM_SIZE, but the old symbols are still defined.

The following functions have been added to libgnutls:

GNUTLS_MASTER_SIZE
GNUTLS_RANDOM_SIZE
gnutls_crypto_bigint_register2
gnutls_crypto_cipher_register2
gnutls_crypto_digest_register2
gnutls_crypto_mac_register2
gnutls_crypto_pk_register2
gnutls_crypto_rnd_register2
gnutls_crypto_single_cipher_register2
gnutls_crypto_single_digest_register2
gnutls_crypto_single_mac_register2
gnutls_ext_register
gnutls_pk_get_id
gnutls_pk_get_name
gnutls_pk_list
gnutls_session_set_finished_function
gnutls_sign_get_id
gnutls_sign_get_name
gnutls_sign_list
gnutls_srp_set_prime_bits:
gnutls_strerror_name
gnutls_x509_crq_set_key_rsa_raw
gnutls_x509_crt_set_crl_dist_points2
gnutls_x509_crt_set_subject_alt_name

The following functions have been added to libgnutls-extra:

gnutls_register_md5_handler

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

GnuTLS may be downloaded from one of the mirror sites or direct from
<ftp://ftp.gnutls.org/pub/gnutls/>.  The list of mirrors can be found at
<http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources (4.9MB):

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.tar.bz2

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.0.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.0.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 <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
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:

bbd9e5f3a77bfcbef5a769c67d1576e7a6e4bda5  gnutls-2.6.0.tar.bz2

c8b42e979224051e756bd0a9c37da54ef19f49f47f18f741e3c33c56  gnutls-2.6.0.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.gnupg.org/mailman/listinfo/gnutls-dev

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.0.

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.0.exe (14MB)
  http://josefsson.org/gnutls4win/gnutls-2.6.0.exe.sig

The checksum values for SHA-1 and SHA-224 are:

305efcd1515dc8c4e3b0b2caa5cfe4436b74c09d  gnutls-2.6.0.exe

5a2971b672d50e3c384e78a334002f4c04d63e9eae49dc5d28a84b4d  gnutls-2.6.0.exe

Thanks to Enrico Tassi, we also have mingw32 *.deb's available:
  http://josefsson.org/gnutls4win/mingw32-gnutls_2.3.15-1_all.deb

The checksum values for SHA-1 and SHA-224 are:

cde730b75340676f5149afda9a0d8556131f47a8  mingw32-gnutls_2.6.0-1_all.deb

8eb3d88360da079b86eec549ba41111acc7be5b8a375eee08f4bf848  mingw32-gnutls_2.6.0-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

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: </pipermail/attachments/20081006/0a06b153/attachment.pgp>

From pva at gentoo.org  Mon Oct  6 10:20:51 2008
From: pva at gentoo.org (Peter Volkov)
Date: Mon, 06 Oct 2008 12:20:51 +0400
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while
	openssl works
In-Reply-To: <877i8pk772.fsf@mocca.josefsson.org>
References: <1223034323.30303.29.camel@localhost>
	<877i8pk772.fsf@mocca.josefsson.org>
Message-ID: <1223281251.12502.74.camel@localhost>

Is it possible to do something similar in gnutls? It looks like there
are reasons to validate certificate with wrong order...

-------- Forwarded message --------
From: Tim Hudson <tjh AT cryptsoft  com>
Reply-TO: openssl-dev at openssl.org
TO: openssl-dev at openssl.org

Peter Volkov wrote:
> CC'ing openssl developers for their opinions, since I think this
> behavior better to have consistent or configurable. Description of the
> problem is here:

Placing this in context - connect with internet explorer or firefox to 
https://metasploit.com/ and you will see that both of those independent 
implementations see nothing wrong with the certificate chain and handle the 
redirect to http://metasploit.com/ without and errors or warnings.

Implementations typically take the list of certificates as untrusted 
certificates to add into the process of walking the certificate chain to a 
trusted root certificate. There are pragmatic reasons for doing it this way.

 From an interoperability point of view remember the adage - "Be strict in what 
you generate, be liberal in what you accept"

Tim.
______________________________________________________________________


-- 
Peter.





From simon at josefsson.org  Mon Oct  6 10:40:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Oct 2008 10:40:43 +0200
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while
	openssl works
In-Reply-To: <1223281251.12502.74.camel@localhost> (Peter Volkov's message of
	"Mon, 06 Oct 2008 12:20:51 +0400")
References: <1223034323.30303.29.camel@localhost>
	<877i8pk772.fsf@mocca.josefsson.org>
	<1223281251.12502.74.camel@localhost>
Message-ID: <87ej2ut8tw.fsf@mocca.josefsson.org>

The specification is clear that the chain must be in proper order.  I'll
bring this up in the TLS WG to see if there is any consensus to make the
specification more in line with what some implementations do.  I can see
several reasons for NOT doing this (e.g., covert channels,
DoS-considerations, and unneeded complexity).  We should have a strong
reason before we violate explicit recommendations in the protocol
specification.

/Simon

Peter Volkov <pva at gentoo.org> writes:

> Is it possible to do something similar in gnutls? It looks like there
> are reasons to validate certificate with wrong order...
>
> -------- Forwarded message --------
> From: Tim Hudson <tjh AT cryptsoft  com>
> Reply-TO: openssl-dev at openssl.org
> TO: openssl-dev at openssl.org
>
> Peter Volkov wrote:
>> CC'ing openssl developers for their opinions, since I think this
>> behavior better to have consistent or configurable. Description of the
>> problem is here:
>
> Placing this in context - connect with internet explorer or firefox to 
> https://metasploit.com/ and you will see that both of those independent 
> implementations see nothing wrong with the certificate chain and handle the 
> redirect to http://metasploit.com/ without and errors or warnings.
>
> Implementations typically take the list of certificates as untrusted 
> certificates to add into the process of walking the certificate chain to a 
> trusted root certificate. There are pragmatic reasons for doing it this way.
>
>  From an interoperability point of view remember the adage - "Be strict in what 
> you generate, be liberal in what you accept"
>
> Tim.
> ______________________________________________________________________
>
>
> -- 
> Peter.




From simon at josefsson.org  Mon Oct  6 11:39:11 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 06 Oct 2008 11:39:11 +0200
Subject: [Help-gnutls] Re: gnutls fails to verify server sertificate while
	openssl works
In-Reply-To: <87ej2ut8tw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon, 06 Oct 2008 10:40:43 +0200")
References: <1223034323.30303.29.camel@localhost>
	<877i8pk772.fsf@mocca.josefsson.org>
	<1223281251.12502.74.camel@localhost>
	<87ej2ut8tw.fsf@mocca.josefsson.org>
Message-ID: <871vyut64g.fsf@mocca.josefsson.org>

I brought this up in the TLS WG:

http://thread.gmane.org/gmane.ietf.tls/3782

Thanks,
/Simon

Simon Josefsson <simon at josefsson.org> writes:

> The specification is clear that the chain must be in proper order.  I'll
> bring this up in the TLS WG to see if there is any consensus to make the
> specification more in line with what some implementations do.  I can see
> several reasons for NOT doing this (e.g., covert channels,
> DoS-considerations, and unneeded complexity).  We should have a strong
> reason before we violate explicit recommendations in the protocol
> specification.
>
> /Simon
>
> Peter Volkov <pva at gentoo.org> writes:
>
>> Is it possible to do something similar in gnutls? It looks like there
>> are reasons to validate certificate with wrong order...
>>
>> -------- Forwarded message --------
>> From: Tim Hudson <tjh AT cryptsoft  com>
>> Reply-TO: openssl-dev at openssl.org
>> TO: openssl-dev at openssl.org
>>
>> Peter Volkov wrote:
>>> CC'ing openssl developers for their opinions, since I think this
>>> behavior better to have consistent or configurable. Description of the
>>> problem is here:
>>
>> Placing this in context - connect with internet explorer or firefox to 
>> https://metasploit.com/ and you will see that both of those independent 
>> implementations see nothing wrong with the certificate chain and handle the 
>> redirect to http://metasploit.com/ without and errors or warnings.
>>
>> Implementations typically take the list of certificates as untrusted 
>> certificates to add into the process of walking the certificate chain to a 
>> trusted root certificate. There are pragmatic reasons for doing it this way.
>>
>>  From an interoperability point of view remember the adage - "Be strict in what 
>> you generate, be liberal in what you accept"
>>
>> Tim.
>> ______________________________________________________________________
>>
>>
>> -- 
>> Peter.




From kristian.martens at freenet.de  Tue Oct  7 14:37:32 2008
From: kristian.martens at freenet.de (kristian.martens at freenet.de)
Date: Tue, 07 Oct 2008 14:37:32 +0200
Subject: [Help-gnutls] Client auth. fails
Message-ID: <5b16ca697b67c971780f7596f957d597@email.freenet.de>

All,

the gnutls server implementation (I am using gnutls 2.0.1) encounters a
problem when verifying a client certificate. I saw a strange log entry
saying " Possible PKCS #1 format attack ". What does this mean? Could
this be the reason for the failure?  Does anyone know the root cause? 

Thanks,
Kris 

Please find attached the handshake log:

0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 35
0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[0]
Handshake(22) with length: 1
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[0]
Handshake(22) with length: 53
0x574f76c (t2): IN.gnutls: READ: Got 53 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 53 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 01 00 00 31 03 01 48 d9 49 3f f7 83 70
f9 34 0a
0x574f76c (t2): IN.gnutls: 0001 - c3 3f 94 57 65 47 85 12 e3 21 7e 56 da
07 3c ca
0x574f76c (t2): IN.gnutls: 0002 - 98 92 ee 83 94 be 00 00 0a 00 04 00 05
00 0a 00
0x574f76c (t2): IN.gnutls: 0003 - 2f 00 35 01 00
0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 53
bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 58 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Decrypted Packet[0]
Handshake(22) with length: 53
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 53 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CLIENT HELLO was received [53
bytes]
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 49 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 49 bytes of Data
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Client's version: 3.1
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_db.c:239
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_algorithms.c:1627
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Selected Compression Method:
NULL
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_extensions.c:162
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
PSK_SHA_ARCFOUR_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
PSK_SHA_3DES_EDE_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
PSK_SHA_AES_128_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
PSK_SHA_AES_256_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_PSK_SHA_ARCFOUR_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_PSK_SHA_3DES_EDE_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_PSK_SHA_AES_128_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_PSK_SHA_AES_256_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
DHE_DSS_ARCFOUR_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
DHE_DSS_3DES_EDE_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
DHE_DSS_AES_128_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
DHE_DSS_AES_256_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_RSA_3DES_EDE_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_RSA_AES_128_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
DHE_RSA_AES_256_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
RSA_ARCFOUR_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
RSA_ARCFOUR_MD5
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
RSA_3DES_EDE_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
RSA_AES_128_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
RSA_AES_256_CBC_SHA1
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Selected cipher suite:
RSA_ARCFOUR_MD5
0x574f76c (t2): IN.gnutls: ASSERT: ext_authz.c:180
0x574f76c (t2): IN.gnutls: ASSERT: ext_authz.c:237
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SessionID:
ef942f18006dd557b97a576e795123ee917aa9947461f0380ff19870338e7fe9
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SERVER HELLO was send [74
bytes]
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 53 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[0] Handshake(22)
with length: 74
0x574f76c (t2): IN.gnutls: WRITE: Will write 79 bytes to 166892884.
0x574f76c (t2): IN.gnutls: WRITE: wrote 79 bytes to 166892884. Left 0
bytes. Total 79 bytes.
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 4a 02 00 00 46 03 01 48 eb
8c fa ef
0x574f76c (t2): IN.gnutls: 0001 - 94 2f 18 00 6d d5 57 b9 7a 57 6e 79 51
23 ee 91
0x574f76c (t2): IN.gnutls: 0002 - 7a a9 94 74 61 f0 38 0f f1 98 70 20 ef
94 2f 18
0x574f76c (t2): IN.gnutls: 0003 - 00 6d d5 57 b9 7a 57 6e 79 51 23 ee 91
7a a9 94
0x574f76c (t2): IN.gnutls: 0004 - 74 61 f0 38 0f f1 98 70 33 8e 7f e9 00
04 00
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[1] Handshake(22)
with length: 79
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE was send [623
bytes]
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[1] Handshake(22)
with length: 623
0x574f76c (t2): IN.gnutls: WRITE: Will write 628 bytes to 166892884.
0x574f76c (t2): IN.gnutls: WRITE: wrote 628 bytes to 166892884. Left 0
bytes. Total 628 bytes.
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 02 6f 0b 00 02 6b 00 02 68 00
02 65 30
0x574f76c (t2): IN.gnutls: 0001 - 82 02 61 30 82 01 cc a0 03 02 01 02 02
04 47 27
0x574f76c (t2): IN.gnutls: 0002 - 2d 2d 30 0b 06 09 2a 86 48 86 f7 0d 01
01 05 30
0x574f76c (t2): IN.gnutls: 0003 - 17 31 15 30 13 06 03 55 04 03 13 0c 54
65 6b 74
0x574f76c (t2): IN.gnutls: 0004 - 72 6f 6e 69 78 20 43 41 30 1e 17 0d 30
37 31 30
0x574f76c (t2): IN.gnutls: 0005 - 33 30 31 33 31 30 30 35 5a 17 0d 31 37
31 30 32
0x574f76c (t2): IN.gnutls: 0006 - 37 31 33 31 30 30 35 5a 30 42 31 0b 30
09 06 03
0x574f76c (t2): IN.gnutls: 0007 - 55 04 06 13 02 55 53 31 17 30 15 06 03
55 04 0a
0x574f76c (t2): IN.gnutls: 0008 - 13 0e 54 65 6b 74 72 6f 6e 69 78 20 49
6e 63 2e
0x574f76c (t2): IN.gnutls: 0009 - 31 1a 30 18 06 03 55 04 03 13 11 77 77
77 2e 74
0x574f76c (t2): IN.gnutls: 000a - 65 6b 74 72 6f 6e 69 78 2e 63 6f 6d 30
81 9c 30
0x574f76c (t2): IN.gnutls: 000b - 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03
81 8c 00
0x574f76c (t2): IN.gnutls: 000c - 30 81 88 02 81 80 ad a5 a5 12 74 ee 3d
a3 ad ee
0x574f76c (t2): IN.gnutls: 000d - e7 00 40 c1 ad a2 7d 85 d8 e4 9f 68 9c
fd 3f c1
0x574f76c (t2): IN.gnutls: 000e - 57 f4 a8 21 2f 7c fc 43 12 41 ec d9 cb
f1 0e 10
0x574f76c (t2): IN.gnutls: 000f - fd b1 ca 9a af da 6c 69 1d 06 f2 7b 61
9c 26 23
0x574f76c (t2): IN.gnutls: 0010 - a7 dd 11 16 1f 93 2f b4 f5 a9 e2 a7 33
3d ea 81
0x574f76c (t2): IN.gnutls: 0011 - 44 b4 ef 26 35 46 62 b2 42 9b c3 f9 fd
f1 71 e0
0x574f76c (t2): IN.gnutls: 0012 - 31 2e 54 aa f8 7c bb 3a 1f 49 51 6e 29
93 27 bc
0x574f76c (t2): IN.gnutls: 0013 - 40 9c f5 0a da 28 94 b8 06 33 61 ae 60
68 3d 52
0x574f76c (t2): IN.gnutls: 0014 - 85 da 09 fc 70 85 02 03 01 00 01 a3 81
95 30 81
0x574f76c (t2): IN.gnutls: 0015 - 92 30 0c 06 03 55 1d 13 01 01 ff 04 02
30 00 30
0x574f76c (t2): IN.gnutls: 0016 - 1c 06 03 55 1d 11 04 15 30 13 82 11 77
77 77 2e
0x574f76c (t2): IN.gnutls: 0017 - 74 65 6b 74 72 6f 6e 69 78 2e 63 6f 6d
30 13 06
0x574f76c (t2): IN.gnutls: 0018 - 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01
05 05 07
0x574f76c (t2): IN.gnutls: 0019 - 03 01 30 0f 06 03 55 1d 0f 01 01 ff 04
05 03 03
0x574f76c (t2): IN.gnutls: 001a - 07 a0 00 30 1d 06 03 55 1d 0e 04 16 04
14 3b a3
0x574f76c (t2): IN.gnutls: 001b - 48 d6 06 19 dd 51 cf 77 4f dd ed 11 31
a1 62 0c
0x574f76c (t2): IN.gnutls: 001c - 68 dd 30 1f 06 03 55 1d 23 04 18 30 16
80 14 57
0x574f76c (t2): IN.gnutls: 001d - aa bc 0a b5 e1 f9 b9 11 76 21 35 6f fa
77 4a ff
0x574f76c (t2): IN.gnutls: 001e - a6 c6 a0 30 0b 06 09 2a 86 48 86 f7 0d
01 01 05
0x574f76c (t2): IN.gnutls: 001f - 03 81 81 00 99 b1 37 f1 23 22 95 85 54
aa 5b ad
0x574f76c (t2): IN.gnutls: 0020 - d1 da 6d 77 71 c1 bb 32 a5 6f 6b 6e b3
33 39 0e
0x574f76c (t2): IN.gnutls: 0021 - 06 73 ea e7 1a 13 05 01 8a 96 1f 73 4d
3a 90 7a
0x574f76c (t2): IN.gnutls: 0022 - 75 dd ec 12 54 86 cc 2d 36 eb f3 57 e9
83 64 fe
0x574f76c (t2): IN.gnutls: 0023 - 8f 65 66 84 a9 d8 75 fc 45 b4 10 d5 74
c2 b1 d3
0x574f76c (t2): IN.gnutls: 0024 - ec b8 78 bb 9b dc b7 bc 48 89 fc db 59
63 fa fa
0x574f76c (t2): IN.gnutls: 0025 - fc 66 f6 46 c4 32 7a 2c 81 ac 93 41 ca
24 43 17
0x574f76c (t2): IN.gnutls: 0026 - 12 81 93 0a 8b 0b 0c 78 a1 f1 a5 b3 93
62 8a cf
0x574f76c (t2): IN.gnutls: 0027 - 53 82 5b 06
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[2] Handshake(22)
with length: 628
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE REQUEST was send
[36 bytes]
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[2] Handshake(22)
with length: 36
0x574f76c (t2): IN.gnutls: WRITE: Will write 41 bytes to 166892884.
0x574f76c (t2): IN.gnutls: WRITE: wrote 41 bytes to 166892884. Left 0
bytes. Total 41 bytes.
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 24 0d 00 00 20 02 01 02 00
1b 00 19
0x574f76c (t2): IN.gnutls: 0001 - 30 17 31 15 30 13 06 03 55 04 03 13 0c
54 65 6b
0x574f76c (t2): IN.gnutls: 0002 - 74 72 6f 6e 69 78 20 43 41
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[3] Handshake(22)
with length: 41
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SERVER HELLO DONE was send [4
bytes]
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[3] Handshake(22)
with length: 4
0x574f76c (t2): IN.gnutls: WRITE: Will write 9 bytes to 166892884.
0x574f76c (t2): IN.gnutls: WRITE: wrote 9 bytes to 166892884. Left 0
bytes. Total 9 bytes.
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 04 0e 00 00 00
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[4] Handshake(22)
with length: 9
0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 02 f8
0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[1]
Handshake(22) with length: 1
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[1]
Handshake(22) with length: 760
0x574f76c (t2): IN.gnutls: READ: Got 760 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 760 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 0b 00 01 e8 00 01 e5 00 01 e2 30 82 01
de 30 82
0x574f76c (t2): IN.gnutls: 0001 - 01 47 a0 03 02 01 02 02 04 48 d9 4f 03
30 0d 06
0x574f76c (t2): IN.gnutls: 0002 - 09 2a 86 48 86 f7 0d 01 01 05 05 00 30
17 31 15
0x574f76c (t2): IN.gnutls: 0003 - 30 13 06 03 55 04 03 13 0c 31 39 32 2e
31 32 38
0x574f76c (t2): IN.gnutls: 0004 - 2e 31 30 2e 32 30 1e 17 0d 30 38 30 39
32 32 32
0x574f76c (t2): IN.gnutls: 0005 - 30 31 38 31 31 5a 17 0d 31 31 30 39 32
33 32 30
0x574f76c (t2): IN.gnutls: 0006 - 31 38 31 31 5a 30 17 31 15 30 13 06 03
55 04 03
0x574f76c (t2): IN.gnutls: 0007 - 13 0c 31 39 32 2e 31 32 38 2e 31 30 2e
32 30 81
0x574f76c (t2): IN.gnutls: 0008 - 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01
01 05 00
0x574f76c (t2): IN.gnutls: 0009 - 03 81 8d 00 30 81 89 02 81 81 00 e1 7b
3d 35 49
0x574f76c (t2): IN.gnutls: 000a - b2 3b cf 22 16 fe ee 6f 6a 82 26 ce 25
cc 63 bf
0x574f76c (t2): IN.gnutls: 000b - b4 7a f2 70 75 dd 13 ed d4 aa 5b 25 91
22 fd 68
0x574f76c (t2): IN.gnutls: 000c - 1a ec 20 1a 44 10 59 86 0f 30 c8 6d 47
19 12 6e
0x574f76c (t2): IN.gnutls: 000d - 4e a1 b4 f4 39 11 a8 5c 55 df 40 65 79
3a 29 4a
0x574f76c (t2): IN.gnutls: 000e - 76 63 60 7b af 20 c8 e2 be af fc a2 17
08 1c 5e
0x574f76c (t2): IN.gnutls: 000f - 1c 57 48 19 56 71 e3 db b6 a9 9e d3 d9
ae 0d c7
0x574f76c (t2): IN.gnutls: 0010 - d4 06 d6 82 38 1a 10 9d 95 47 b4 61 d0
6a 76 0f
0x574f76c (t2): IN.gnutls: 0011 - 1f 70 66 43 d0 f2 5c da 87 56 47 02 03
01 00 01
0x574f76c (t2): IN.gnutls: 0012 - a3 37 30 35 30 0e 06 03 55 1d 0f 01 01
00 04 04
0x574f76c (t2): IN.gnutls: 0013 - 03 02 02 a4 30 0f 06 03 55 1d 11 04 08
30 06 87
0x574f76c (t2): IN.gnutls: 0014 - 04 c0 80 0a 02 30 12 06 03 55 1d 13 01
01 00 04
0x574f76c (t2): IN.gnutls: 0015 - 08 30 06 01 01 ff 02 01 01 30 0d 06 09
2a 86 48
0x574f76c (t2): IN.gnutls: 0016 - 86 f7 0d 01 01 05 05 00 03 81 81 00 1b
df 75 87
0x574f76c (t2): IN.gnutls: 0017 - 1b 69 11 91 6a 69 a7 e1 f2 6c eb 3f 46
84 55 55
0x574f76c (t2): IN.gnutls: 0018 - b6 b9 a3 f5 8e 73 6d 9c ae 63 a1 f3 64
f0 3a b2
0x574f76c (t2): IN.gnutls: 0019 - fd a7 bf c6 0f 46 17 02 f6 84 fe 1c 5e
f3 dd 87
0x574f76c (t2): IN.gnutls: 001a - 3e c4 3d f3 81 d4 ce 56 26 49 13 b1 ef
56 c8 b4
0x574f76c (t2): IN.gnutls: 001b - 22 42 bb 09 83 62 0a e6 76 cd 6e 58 d3
09 30 8c
0x574f76c (t2): IN.gnutls: 001c - cb 0b 17 a4 0e 75 ae e0 02 8f b0 ea 17
5a fc a9
0x574f76c (t2): IN.gnutls: 001d - df 3d 57 c4 3d 4f 2e 0f 87 b0 34 92 18
71 e2 95
0x574f76c (t2): IN.gnutls: 001e - 7b db 8d 0d 89 f7 63 16 61 57 aa ad 10
00 00 82
0x574f76c (t2): IN.gnutls: 001f - 00 80 35 23 dd bc 98 7a f4 db 18 9a e8
33 37 fa
0x574f76c (t2): IN.gnutls: 0020 - 66 30 f7 cf 26 e5 5e 3e 0c ae d2 59 2c
9d 10 46
0x574f76c (t2): IN.gnutls: 0021 - 5b 9b 30 8e 2a de e6 fa 4a b2 8c 74 59
ef b6 66
0x574f76c (t2): IN.gnutls: 0022 - e9 51 33 70 3f 45 b0 8b ad 60 07 59 ac
df d4 04
0x574f76c (t2): IN.gnutls: 0023 - 71 5c 0b 8f 90 25 6d 17 5b 84 d4 44 48
3c 25 0c
0x574f76c (t2): IN.gnutls: 0024 - 56 6d 55 12 40 6b 9f 7f bc ac 26 4d 90
eb 7f e9
0x574f76c (t2): IN.gnutls: 0025 - ee 43 96 11 1e aa 45 72 83 ff 11 1e ea
b5 fb e8
0x574f76c (t2): IN.gnutls: 0026 - 28 45 54 6c 65 7c c3 d7 04 84 46 d5 67
05 49 1f
0x574f76c (t2): IN.gnutls: 0027 - fc 68 0f 00 00 82 00 80 03 ed 00 5d 86
09 69 30
0x574f76c (t2): IN.gnutls: 0028 - e4 c0 86 55 39 c5 08 55 32 54 5b 3d 07
25 09 83
0x574f76c (t2): IN.gnutls: 0029 - 29 62 29 d3 d2 ed b4 a6 7a ad 62 e3 c9
30 8e 6c
0x574f76c (t2): IN.gnutls: 002a - 34 1e 1b e1 3a 54 a9 4d f0 9d b3 4a c9
c9 1a 4f
0x574f76c (t2): IN.gnutls: 002b - ef 92 32 47 ed c9 72 74 0a 71 45 05 46
13 11 42
0x574f76c (t2): IN.gnutls: 002c - 80 b1 49 8f db c0 35 5c bf d9 95 a1 46
77 71 67
0x574f76c (t2): IN.gnutls: 002d - 5c eb 20 99 76 45 1a 65 7a 30 a3 78 93
ad 3b 9a
0x574f76c (t2): IN.gnutls: 002e - 29 6f 14 80 44 cf 14 61 22 ec 97 ac 27
cb 96 fd
0x574f76c (t2): IN.gnutls: 002f - 55 92 2f 31 64 5c 82 ec
0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 760
bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 765 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Decrypted Packet[1]
Handshake(22) with length: 760
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 760 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE was received [492
bytes]
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 488 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 488 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CLIENT KEY EXCHANGE was
received [134 bytes]
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 130 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 492 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 130 bytes of Data
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_pk.c:283
0x574f76c (t2): IN.gnutls: ASSERT: auth_rsa.c:258
0x574f76c (t2): IN.gnutls: auth_rsa: Possible PKCS #1 format attack
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE VERIFY was received
[134 bytes]
0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 130 bytes of Data(22)
0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 134 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 130 bytes of Data
0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 14 03 01 00 01
0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[2] Change
Cipher Spec(20) with length: 1
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[2] Change
Cipher Spec(20) with length: 1
0x574f76c (t2): IN.gnutls: READ: Got 1 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 1 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 01
0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 1 bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 6 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: ChangeCipherSpec Packet was
received
0x574f76c (t2): IN.gnutls: INT: PREMASTER SECRET[48]:
03012b011acc7633cd91bce5d45ffd177adf0193b22ec981f99b30f9fb805d5c409d50cdd8ec5008c058d9
e108bbedce
0x574f76c (t2): IN.gnutls: INT: CLIENT RANDOM[32]:
48d9493ff78370f9340ac33f945765478512e3217e56da073cca9892ee8394be
0x574f76c (t2): IN.gnutls: INT: SERVER RANDOM[32]:
48eb8cfaef942f18006dd557b97a576e795123ee917aa9947461f0380ff19870
0x574f76c (t2): IN.gnutls: INT: MASTER SECRET:
0d454d81f4f5c85b0998c77cb1b469400380d2a613344d089c2646f44c4b341cdf78a3d15d4d87167b8d5385337fa
efb
0x574f76c (t2): IN.gnutls: INT: KEY BLOCK[64]:
d920b45221630b466eab7cba7ae58a86c401e3f8e6ed0fb1db35f6ae0e930cb6
0x574f76c (t2): IN.gnutls: INT: CLIENT WRITE KEY [16]:
41ff237870ee3017051853a568387b63
0x574f76c (t2): IN.gnutls: INT: SERVER WRITE KEY [16]:
d4a51c4e92c663ab205cb8d5ab3eb827
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Cipher Suite: RSA_ARCFOUR_MD5
0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Initializing internal [read]
cipher sessions
0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 20
0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[0]
Handshake(22) with length: 1
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[0]
Handshake(22) with length: 32
0x574f76c (t2): IN.gnutls: READ: Got 32 bytes from 166892884
0x574f76c (t2): IN.gnutls: READ: read 32 bytes from 166892884
0x574f76c (t2): IN.gnutls: 0000 - 50 7d ba 69 15 22 e9 23 c7 e0 69 d7 8e
a5 c7 21
0x574f76c (t2): IN.gnutls: 0001 - 6d 0c 23 17 8b 32 61 2a 5e f4 f7 34 a1
3f e7 0e
0x574f76c (t2): IN.gnutls: 0002 -
0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 32
bytes.
0x574f76c (t2): IN.gnutls: RB: Requested 37 bytes
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_cipher.c:562
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_record.c:982
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_buffers.c:1188
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:962
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:525
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:2472
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:2608
0x574f76c (t2): IN.gnutls: BUF[HSK]: Cleared Data from buffer
0x574f76c (t2): IN.gnutls: REC: Sending Alert[2|20] - Bad record MAC
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[4]  with length:
2
0x574f76c (t2): IN.gnutls: WRITE: Will write 7 bytes to 166892884.
0x574f76c (t2): IN.gnutls: WRITE: wrote 7 bytes to 166892884. Left 0
bytes. Total 7 bytes.
0x574f76c (t2): IN.gnutls: 0000 - 15 03 01 00 02 02 14
0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[5]  with length: 7
0x574f76c (t2): IN.gnutls: ASSERT: gnutls_psk.c:309




Gesendet von freenetMail-
Mehr als nur eine
E-Mail-Adresse
http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6828





From simon at josefsson.org  Tue Oct  7 15:04:47 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 07 Oct 2008 15:04:47 +0200
Subject: [Help-gnutls] Re: Client auth. fails
In-Reply-To: <5b16ca697b67c971780f7596f957d597@email.freenet.de> (kristian
	martens's message of "Tue, 07 Oct 2008 14:37:32 +0200")
References: <5b16ca697b67c971780f7596f957d597@email.freenet.de>
Message-ID: <87zllgv9n4.fsf@mocca.josefsson.org>

kristian.martens at freenet.de writes:

> All,
>
> the gnutls server implementation (I am using gnutls 2.0.1) encounters a
> problem when verifying a client certificate. I saw a strange log entry
> saying " Possible PKCS #1 format attack ". What does this mean? Could
> this be the reason for the failure?  Does anyone know the root cause? 

I think it is a false alarm.  As far as I can tell, your debug log
suggests the handshake is successful, but it fails with a MAC errors
afterwards.  Possibly you are seeing the record padding bug:

http://www.gnu.org/software/gnutls/manual/html_node/On-Record-Padding.html

If so, you'll need to use a modern version of gnutls and follow the
hints in the link.

Or do you see any client certificate related errors on the server side?

/Simon


> Thanks,
> Kris 
>
> Please find attached the handshake log:
>
> 0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 35
> 0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[0]
> Handshake(22) with length: 1
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[0]
> Handshake(22) with length: 53
> 0x574f76c (t2): IN.gnutls: READ: Got 53 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 53 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 01 00 00 31 03 01 48 d9 49 3f f7 83 70
> f9 34 0a
> 0x574f76c (t2): IN.gnutls: 0001 - c3 3f 94 57 65 47 85 12 e3 21 7e 56 da
> 07 3c ca
> 0x574f76c (t2): IN.gnutls: 0002 - 98 92 ee 83 94 be 00 00 0a 00 04 00 05
> 00 0a 00
> 0x574f76c (t2): IN.gnutls: 0003 - 2f 00 35 01 00
> 0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 53
> bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 58 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Decrypted Packet[0]
> Handshake(22) with length: 53
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 53 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CLIENT HELLO was received [53
> bytes]
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 49 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 49 bytes of Data
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Client's version: 3.1
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_db.c:239
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_algorithms.c:1627
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Selected Compression Method:
> NULL
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_extensions.c:162
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> PSK_SHA_ARCFOUR_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> PSK_SHA_3DES_EDE_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> PSK_SHA_AES_128_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> PSK_SHA_AES_256_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_PSK_SHA_ARCFOUR_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_PSK_SHA_3DES_EDE_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_PSK_SHA_AES_128_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_PSK_SHA_AES_256_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
> DHE_DSS_ARCFOUR_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
> DHE_DSS_3DES_EDE_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
> DHE_DSS_AES_128_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Removing ciphersuite:
> DHE_DSS_AES_256_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_RSA_3DES_EDE_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_RSA_AES_128_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> DHE_RSA_AES_256_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> RSA_ARCFOUR_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> RSA_ARCFOUR_MD5
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> RSA_3DES_EDE_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> RSA_AES_128_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Keeping ciphersuite:
> RSA_AES_256_CBC_SHA1
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Selected cipher suite:
> RSA_ARCFOUR_MD5
> 0x574f76c (t2): IN.gnutls: ASSERT: ext_authz.c:180
> 0x574f76c (t2): IN.gnutls: ASSERT: ext_authz.c:237
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SessionID:
> ef942f18006dd557b97a576e795123ee917aa9947461f0380ff19870338e7fe9
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SERVER HELLO was send [74
> bytes]
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 53 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[0] Handshake(22)
> with length: 74
> 0x574f76c (t2): IN.gnutls: WRITE: Will write 79 bytes to 166892884.
> 0x574f76c (t2): IN.gnutls: WRITE: wrote 79 bytes to 166892884. Left 0
> bytes. Total 79 bytes.
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 4a 02 00 00 46 03 01 48 eb
> 8c fa ef
> 0x574f76c (t2): IN.gnutls: 0001 - 94 2f 18 00 6d d5 57 b9 7a 57 6e 79 51
> 23 ee 91
> 0x574f76c (t2): IN.gnutls: 0002 - 7a a9 94 74 61 f0 38 0f f1 98 70 20 ef
> 94 2f 18
> 0x574f76c (t2): IN.gnutls: 0003 - 00 6d d5 57 b9 7a 57 6e 79 51 23 ee 91
> 7a a9 94
> 0x574f76c (t2): IN.gnutls: 0004 - 74 61 f0 38 0f f1 98 70 33 8e 7f e9 00
> 04 00
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[1] Handshake(22)
> with length: 79
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE was send [623
> bytes]
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[1] Handshake(22)
> with length: 623
> 0x574f76c (t2): IN.gnutls: WRITE: Will write 628 bytes to 166892884.
> 0x574f76c (t2): IN.gnutls: WRITE: wrote 628 bytes to 166892884. Left 0
> bytes. Total 628 bytes.
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 02 6f 0b 00 02 6b 00 02 68 00
> 02 65 30
> 0x574f76c (t2): IN.gnutls: 0001 - 82 02 61 30 82 01 cc a0 03 02 01 02 02
> 04 47 27
> 0x574f76c (t2): IN.gnutls: 0002 - 2d 2d 30 0b 06 09 2a 86 48 86 f7 0d 01
> 01 05 30
> 0x574f76c (t2): IN.gnutls: 0003 - 17 31 15 30 13 06 03 55 04 03 13 0c 54
> 65 6b 74
> 0x574f76c (t2): IN.gnutls: 0004 - 72 6f 6e 69 78 20 43 41 30 1e 17 0d 30
> 37 31 30
> 0x574f76c (t2): IN.gnutls: 0005 - 33 30 31 33 31 30 30 35 5a 17 0d 31 37
> 31 30 32
> 0x574f76c (t2): IN.gnutls: 0006 - 37 31 33 31 30 30 35 5a 30 42 31 0b 30
> 09 06 03
> 0x574f76c (t2): IN.gnutls: 0007 - 55 04 06 13 02 55 53 31 17 30 15 06 03
> 55 04 0a
> 0x574f76c (t2): IN.gnutls: 0008 - 13 0e 54 65 6b 74 72 6f 6e 69 78 20 49
> 6e 63 2e
> 0x574f76c (t2): IN.gnutls: 0009 - 31 1a 30 18 06 03 55 04 03 13 11 77 77
> 77 2e 74
> 0x574f76c (t2): IN.gnutls: 000a - 65 6b 74 72 6f 6e 69 78 2e 63 6f 6d 30
> 81 9c 30
> 0x574f76c (t2): IN.gnutls: 000b - 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03
> 81 8c 00
> 0x574f76c (t2): IN.gnutls: 000c - 30 81 88 02 81 80 ad a5 a5 12 74 ee 3d
> a3 ad ee
> 0x574f76c (t2): IN.gnutls: 000d - e7 00 40 c1 ad a2 7d 85 d8 e4 9f 68 9c
> fd 3f c1
> 0x574f76c (t2): IN.gnutls: 000e - 57 f4 a8 21 2f 7c fc 43 12 41 ec d9 cb
> f1 0e 10
> 0x574f76c (t2): IN.gnutls: 000f - fd b1 ca 9a af da 6c 69 1d 06 f2 7b 61
> 9c 26 23
> 0x574f76c (t2): IN.gnutls: 0010 - a7 dd 11 16 1f 93 2f b4 f5 a9 e2 a7 33
> 3d ea 81
> 0x574f76c (t2): IN.gnutls: 0011 - 44 b4 ef 26 35 46 62 b2 42 9b c3 f9 fd
> f1 71 e0
> 0x574f76c (t2): IN.gnutls: 0012 - 31 2e 54 aa f8 7c bb 3a 1f 49 51 6e 29
> 93 27 bc
> 0x574f76c (t2): IN.gnutls: 0013 - 40 9c f5 0a da 28 94 b8 06 33 61 ae 60
> 68 3d 52
> 0x574f76c (t2): IN.gnutls: 0014 - 85 da 09 fc 70 85 02 03 01 00 01 a3 81
> 95 30 81
> 0x574f76c (t2): IN.gnutls: 0015 - 92 30 0c 06 03 55 1d 13 01 01 ff 04 02
> 30 00 30
> 0x574f76c (t2): IN.gnutls: 0016 - 1c 06 03 55 1d 11 04 15 30 13 82 11 77
> 77 77 2e
> 0x574f76c (t2): IN.gnutls: 0017 - 74 65 6b 74 72 6f 6e 69 78 2e 63 6f 6d
> 30 13 06
> 0x574f76c (t2): IN.gnutls: 0018 - 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01
> 05 05 07
> 0x574f76c (t2): IN.gnutls: 0019 - 03 01 30 0f 06 03 55 1d 0f 01 01 ff 04
> 05 03 03
> 0x574f76c (t2): IN.gnutls: 001a - 07 a0 00 30 1d 06 03 55 1d 0e 04 16 04
> 14 3b a3
> 0x574f76c (t2): IN.gnutls: 001b - 48 d6 06 19 dd 51 cf 77 4f dd ed 11 31
> a1 62 0c
> 0x574f76c (t2): IN.gnutls: 001c - 68 dd 30 1f 06 03 55 1d 23 04 18 30 16
> 80 14 57
> 0x574f76c (t2): IN.gnutls: 001d - aa bc 0a b5 e1 f9 b9 11 76 21 35 6f fa
> 77 4a ff
> 0x574f76c (t2): IN.gnutls: 001e - a6 c6 a0 30 0b 06 09 2a 86 48 86 f7 0d
> 01 01 05
> 0x574f76c (t2): IN.gnutls: 001f - 03 81 81 00 99 b1 37 f1 23 22 95 85 54
> aa 5b ad
> 0x574f76c (t2): IN.gnutls: 0020 - d1 da 6d 77 71 c1 bb 32 a5 6f 6b 6e b3
> 33 39 0e
> 0x574f76c (t2): IN.gnutls: 0021 - 06 73 ea e7 1a 13 05 01 8a 96 1f 73 4d
> 3a 90 7a
> 0x574f76c (t2): IN.gnutls: 0022 - 75 dd ec 12 54 86 cc 2d 36 eb f3 57 e9
> 83 64 fe
> 0x574f76c (t2): IN.gnutls: 0023 - 8f 65 66 84 a9 d8 75 fc 45 b4 10 d5 74
> c2 b1 d3
> 0x574f76c (t2): IN.gnutls: 0024 - ec b8 78 bb 9b dc b7 bc 48 89 fc db 59
> 63 fa fa
> 0x574f76c (t2): IN.gnutls: 0025 - fc 66 f6 46 c4 32 7a 2c 81 ac 93 41 ca
> 24 43 17
> 0x574f76c (t2): IN.gnutls: 0026 - 12 81 93 0a 8b 0b 0c 78 a1 f1 a5 b3 93
> 62 8a cf
> 0x574f76c (t2): IN.gnutls: 0027 - 53 82 5b 06
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[2] Handshake(22)
> with length: 628
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE REQUEST was send
> [36 bytes]
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[2] Handshake(22)
> with length: 36
> 0x574f76c (t2): IN.gnutls: WRITE: Will write 41 bytes to 166892884.
> 0x574f76c (t2): IN.gnutls: WRITE: wrote 41 bytes to 166892884. Left 0
> bytes. Total 41 bytes.
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 24 0d 00 00 20 02 01 02 00
> 1b 00 19
> 0x574f76c (t2): IN.gnutls: 0001 - 30 17 31 15 30 13 06 03 55 04 03 13 0c
> 54 65 6b
> 0x574f76c (t2): IN.gnutls: 0002 - 74 72 6f 6e 69 78 20 43 41
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[3] Handshake(22)
> with length: 41
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: SERVER HELLO DONE was send [4
> bytes]
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[3] Handshake(22)
> with length: 4
> 0x574f76c (t2): IN.gnutls: WRITE: Will write 9 bytes to 166892884.
> 0x574f76c (t2): IN.gnutls: WRITE: wrote 9 bytes to 166892884. Left 0
> bytes. Total 9 bytes.
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 04 0e 00 00 00
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[4] Handshake(22)
> with length: 9
> 0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 02 f8
> 0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[1]
> Handshake(22) with length: 1
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[1]
> Handshake(22) with length: 760
> 0x574f76c (t2): IN.gnutls: READ: Got 760 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 760 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 0b 00 01 e8 00 01 e5 00 01 e2 30 82 01
> de 30 82
> 0x574f76c (t2): IN.gnutls: 0001 - 01 47 a0 03 02 01 02 02 04 48 d9 4f 03
> 30 0d 06
> 0x574f76c (t2): IN.gnutls: 0002 - 09 2a 86 48 86 f7 0d 01 01 05 05 00 30
> 17 31 15
> 0x574f76c (t2): IN.gnutls: 0003 - 30 13 06 03 55 04 03 13 0c 31 39 32 2e
> 31 32 38
> 0x574f76c (t2): IN.gnutls: 0004 - 2e 31 30 2e 32 30 1e 17 0d 30 38 30 39
> 32 32 32
> 0x574f76c (t2): IN.gnutls: 0005 - 30 31 38 31 31 5a 17 0d 31 31 30 39 32
> 33 32 30
> 0x574f76c (t2): IN.gnutls: 0006 - 31 38 31 31 5a 30 17 31 15 30 13 06 03
> 55 04 03
> 0x574f76c (t2): IN.gnutls: 0007 - 13 0c 31 39 32 2e 31 32 38 2e 31 30 2e
> 32 30 81
> 0x574f76c (t2): IN.gnutls: 0008 - 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01
> 01 05 00
> 0x574f76c (t2): IN.gnutls: 0009 - 03 81 8d 00 30 81 89 02 81 81 00 e1 7b
> 3d 35 49
> 0x574f76c (t2): IN.gnutls: 000a - b2 3b cf 22 16 fe ee 6f 6a 82 26 ce 25
> cc 63 bf
> 0x574f76c (t2): IN.gnutls: 000b - b4 7a f2 70 75 dd 13 ed d4 aa 5b 25 91
> 22 fd 68
> 0x574f76c (t2): IN.gnutls: 000c - 1a ec 20 1a 44 10 59 86 0f 30 c8 6d 47
> 19 12 6e
> 0x574f76c (t2): IN.gnutls: 000d - 4e a1 b4 f4 39 11 a8 5c 55 df 40 65 79
> 3a 29 4a
> 0x574f76c (t2): IN.gnutls: 000e - 76 63 60 7b af 20 c8 e2 be af fc a2 17
> 08 1c 5e
> 0x574f76c (t2): IN.gnutls: 000f - 1c 57 48 19 56 71 e3 db b6 a9 9e d3 d9
> ae 0d c7
> 0x574f76c (t2): IN.gnutls: 0010 - d4 06 d6 82 38 1a 10 9d 95 47 b4 61 d0
> 6a 76 0f
> 0x574f76c (t2): IN.gnutls: 0011 - 1f 70 66 43 d0 f2 5c da 87 56 47 02 03
> 01 00 01
> 0x574f76c (t2): IN.gnutls: 0012 - a3 37 30 35 30 0e 06 03 55 1d 0f 01 01
> 00 04 04
> 0x574f76c (t2): IN.gnutls: 0013 - 03 02 02 a4 30 0f 06 03 55 1d 11 04 08
> 30 06 87
> 0x574f76c (t2): IN.gnutls: 0014 - 04 c0 80 0a 02 30 12 06 03 55 1d 13 01
> 01 00 04
> 0x574f76c (t2): IN.gnutls: 0015 - 08 30 06 01 01 ff 02 01 01 30 0d 06 09
> 2a 86 48
> 0x574f76c (t2): IN.gnutls: 0016 - 86 f7 0d 01 01 05 05 00 03 81 81 00 1b
> df 75 87
> 0x574f76c (t2): IN.gnutls: 0017 - 1b 69 11 91 6a 69 a7 e1 f2 6c eb 3f 46
> 84 55 55
> 0x574f76c (t2): IN.gnutls: 0018 - b6 b9 a3 f5 8e 73 6d 9c ae 63 a1 f3 64
> f0 3a b2
> 0x574f76c (t2): IN.gnutls: 0019 - fd a7 bf c6 0f 46 17 02 f6 84 fe 1c 5e
> f3 dd 87
> 0x574f76c (t2): IN.gnutls: 001a - 3e c4 3d f3 81 d4 ce 56 26 49 13 b1 ef
> 56 c8 b4
> 0x574f76c (t2): IN.gnutls: 001b - 22 42 bb 09 83 62 0a e6 76 cd 6e 58 d3
> 09 30 8c
> 0x574f76c (t2): IN.gnutls: 001c - cb 0b 17 a4 0e 75 ae e0 02 8f b0 ea 17
> 5a fc a9
> 0x574f76c (t2): IN.gnutls: 001d - df 3d 57 c4 3d 4f 2e 0f 87 b0 34 92 18
> 71 e2 95
> 0x574f76c (t2): IN.gnutls: 001e - 7b db 8d 0d 89 f7 63 16 61 57 aa ad 10
> 00 00 82
> 0x574f76c (t2): IN.gnutls: 001f - 00 80 35 23 dd bc 98 7a f4 db 18 9a e8
> 33 37 fa
> 0x574f76c (t2): IN.gnutls: 0020 - 66 30 f7 cf 26 e5 5e 3e 0c ae d2 59 2c
> 9d 10 46
> 0x574f76c (t2): IN.gnutls: 0021 - 5b 9b 30 8e 2a de e6 fa 4a b2 8c 74 59
> ef b6 66
> 0x574f76c (t2): IN.gnutls: 0022 - e9 51 33 70 3f 45 b0 8b ad 60 07 59 ac
> df d4 04
> 0x574f76c (t2): IN.gnutls: 0023 - 71 5c 0b 8f 90 25 6d 17 5b 84 d4 44 48
> 3c 25 0c
> 0x574f76c (t2): IN.gnutls: 0024 - 56 6d 55 12 40 6b 9f 7f bc ac 26 4d 90
> eb 7f e9
> 0x574f76c (t2): IN.gnutls: 0025 - ee 43 96 11 1e aa 45 72 83 ff 11 1e ea
> b5 fb e8
> 0x574f76c (t2): IN.gnutls: 0026 - 28 45 54 6c 65 7c c3 d7 04 84 46 d5 67
> 05 49 1f
> 0x574f76c (t2): IN.gnutls: 0027 - fc 68 0f 00 00 82 00 80 03 ed 00 5d 86
> 09 69 30
> 0x574f76c (t2): IN.gnutls: 0028 - e4 c0 86 55 39 c5 08 55 32 54 5b 3d 07
> 25 09 83
> 0x574f76c (t2): IN.gnutls: 0029 - 29 62 29 d3 d2 ed b4 a6 7a ad 62 e3 c9
> 30 8e 6c
> 0x574f76c (t2): IN.gnutls: 002a - 34 1e 1b e1 3a 54 a9 4d f0 9d b3 4a c9
> c9 1a 4f
> 0x574f76c (t2): IN.gnutls: 002b - ef 92 32 47 ed c9 72 74 0a 71 45 05 46
> 13 11 42
> 0x574f76c (t2): IN.gnutls: 002c - 80 b1 49 8f db c0 35 5c bf d9 95 a1 46
> 77 71 67
> 0x574f76c (t2): IN.gnutls: 002d - 5c eb 20 99 76 45 1a 65 7a 30 a3 78 93
> ad 3b 9a
> 0x574f76c (t2): IN.gnutls: 002e - 29 6f 14 80 44 cf 14 61 22 ec 97 ac 27
> cb 96 fd
> 0x574f76c (t2): IN.gnutls: 002f - 55 92 2f 31 64 5c 82 ec
> 0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 760
> bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 765 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Decrypted Packet[1]
> Handshake(22) with length: 760
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 760 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE was received [492
> bytes]
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 488 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 0 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 488 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CLIENT KEY EXCHANGE was
> received [134 bytes]
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 130 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 492 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 130 bytes of Data
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_pk.c:283
> 0x574f76c (t2): IN.gnutls: ASSERT: auth_rsa.c:258
> 0x574f76c (t2): IN.gnutls: auth_rsa: Possible PKCS #1 format attack
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 1 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 3 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: CERTIFICATE VERIFY was received
> [134 bytes]
> 0x574f76c (t2): IN.gnutls: BUF[REC][HD]: Read 130 bytes of Data(22)
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Peeked 134 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Emptied buffer
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 4 bytes of Data
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Inserted 130 bytes of Data
> 0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 14 03 01 00 01
> 0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[2] Change
> Cipher Spec(20) with length: 1
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[2] Change
> Cipher Spec(20) with length: 1
> 0x574f76c (t2): IN.gnutls: READ: Got 1 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 1 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 01
> 0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 1 bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 6 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: ChangeCipherSpec Packet was
> received
> 0x574f76c (t2): IN.gnutls: INT: PREMASTER SECRET[48]:
> 03012b011acc7633cd91bce5d45ffd177adf0193b22ec981f99b30f9fb805d5c409d50cdd8ec5008c058d9
> e108bbedce
> 0x574f76c (t2): IN.gnutls: INT: CLIENT RANDOM[32]:
> 48d9493ff78370f9340ac33f945765478512e3217e56da073cca9892ee8394be
> 0x574f76c (t2): IN.gnutls: INT: SERVER RANDOM[32]:
> 48eb8cfaef942f18006dd557b97a576e795123ee917aa9947461f0380ff19870
> 0x574f76c (t2): IN.gnutls: INT: MASTER SECRET:
> 0d454d81f4f5c85b0998c77cb1b469400380d2a613344d089c2646f44c4b341cdf78a3d15d4d87167b8d5385337fa
> efb
> 0x574f76c (t2): IN.gnutls: INT: KEY BLOCK[64]:
> d920b45221630b466eab7cba7ae58a86c401e3f8e6ed0fb1db35f6ae0e930cb6
> 0x574f76c (t2): IN.gnutls: INT: CLIENT WRITE KEY [16]:
> 41ff237870ee3017051853a568387b63
> 0x574f76c (t2): IN.gnutls: INT: SERVER WRITE KEY [16]:
> d4a51c4e92c663ab205cb8d5ab3eb827
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Cipher Suite: RSA_ARCFOUR_MD5
> 0x574f76c (t2): IN.gnutls: HSK[a1407c0]: Initializing internal [read]
> cipher sessions
> 0x574f76c (t2): IN.gnutls: READ: Got 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 5 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 16 03 01 00 20
> 0x574f76c (t2): IN.gnutls: RB: Have 0 bytes into buffer. Adding 5 bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 5 bytes
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Expected Packet[0]
> Handshake(22) with length: 1
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Received Packet[0]
> Handshake(22) with length: 32
> 0x574f76c (t2): IN.gnutls: READ: Got 32 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: READ: read 32 bytes from 166892884
> 0x574f76c (t2): IN.gnutls: 0000 - 50 7d ba 69 15 22 e9 23 c7 e0 69 d7 8e
> a5 c7 21
> 0x574f76c (t2): IN.gnutls: 0001 - 6d 0c 23 17 8b 32 61 2a 5e f4 f7 34 a1
> 3f e7 0e
> 0x574f76c (t2): IN.gnutls: 0002 -
> 0x574f76c (t2): IN.gnutls: RB: Have 5 bytes into buffer. Adding 32
> bytes.
> 0x574f76c (t2): IN.gnutls: RB: Requested 37 bytes
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_cipher.c:562
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_record.c:982
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_buffers.c:1188
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:962
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:525
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:2472
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_handshake.c:2608
> 0x574f76c (t2): IN.gnutls: BUF[HSK]: Cleared Data from buffer
> 0x574f76c (t2): IN.gnutls: REC: Sending Alert[2|20] - Bad record MAC
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sending Packet[4]  with length:
> 2
> 0x574f76c (t2): IN.gnutls: WRITE: Will write 7 bytes to 166892884.
> 0x574f76c (t2): IN.gnutls: WRITE: wrote 7 bytes to 166892884. Left 0
> bytes. Total 7 bytes.
> 0x574f76c (t2): IN.gnutls: 0000 - 15 03 01 00 02 02 14
> 0x574f76c (t2): IN.gnutls: REC[a1407c0]: Sent Packet[5]  with length: 7
> 0x574f76c (t2): IN.gnutls: ASSERT: gnutls_psk.c:309
>
>
>
>
> Gesendet von freenetMail-
> Mehr als nur eine
> E-Mail-Adresse
> http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6828




From teddy at fukt.bsnet.se  Wed Oct  8 03:33:44 2008
From: teddy at fukt.bsnet.se (Teddy Hogeborn)
Date: Wed, 08 Oct 2008 03:33:44 +0200
Subject: [Help-gnutls] Announcement: Yet another GnuTLS-using program: Mandos
Message-ID: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>

Hi there; I just wanted all you GnuTLS folks to know about our project
Mandos' slightly unusual use of GnuTLS.

The goal of the Mandos system is to enable server computers to have an
encrypted root file system and still be able to reboot automatically
without anyone having to be there and type in a password.

What happens is that we run a small Mandos client program at boot time
in the initial RAM disk environment (initrd), before even networking
is configured, using IPv6 link-local addresses.

The Mandos client connects to the Mandos server.  The Mandos clients
each have an OpenPGP key, which they use to handshake as TLS *servers*
to the Mandos server, which in turn handshakes as a TLS *client*.  The
Mandos server does not have a key, but computes the fingerprint of the
OpenPGP key received from the Mandos client and looks up that
fingerprint in an internal list, and, if the fingerprint is found,
sends the corresponding binary blob to the client.

(This binary blob is an OpenPGP-encrypted password necessary to unlock
the client's root file system, but this is no longer GnuTLS-related.)

(The server is written in Python, and uses the python-gnutls library
from <http://pypi.python.org/pypi/python-gnutls>.)

Oh yes, the project's home page:  http://www.fukt.bsnet.se/mandos

I just thought you might find it interesting.

/Teddy, Mandos Maintainer Team




From simon at josefsson.org  Wed Oct  8 10:30:43 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 08 Oct 2008 10:30:43 +0200
Subject: [Help-gnutls] Re: Announcement: Yet another GnuTLS-using program:
	Mandos
In-Reply-To: <87k5cjc1l3.fsf@tower.fukt.bsnet.se> (Teddy Hogeborn's message of
	"Wed, 08 Oct 2008 03:33:44 +0200")
References: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>
Message-ID: <878wszsd3g.fsf@mocca.josefsson.org>

Teddy Hogeborn <teddy at fukt.bsnet.se> writes:

> Hi there; I just wanted all you GnuTLS folks to know about our project
> Mandos' slightly unusual use of GnuTLS.
>
> The goal of the Mandos system is to enable server computers to have an
> encrypted root file system and still be able to reboot automatically
> without anyone having to be there and type in a password.
>
> What happens is that we run a small Mandos client program at boot time
> in the initial RAM disk environment (initrd), before even networking
> is configured, using IPv6 link-local addresses.
>
> The Mandos client connects to the Mandos server.  The Mandos clients
> each have an OpenPGP key, which they use to handshake as TLS *servers*
> to the Mandos server, which in turn handshakes as a TLS *client*.  The
> Mandos server does not have a key, but computes the fingerprint of the
> OpenPGP key received from the Mandos client and looks up that
> fingerprint in an internal list, and, if the fingerprint is found,
> sends the corresponding binary blob to the client.
>
> (This binary blob is an OpenPGP-encrypted password necessary to unlock
> the client's root file system, but this is no longer GnuTLS-related.)

Cool!

I'm not sure you have to do the handshake backwards, couldn't just the
mandos server have a OpenPGP key that the mandos client doesn't need to
validate?

One additional idea I get is to add some mechanism in the Mandos server
to require authorization before sending the blob.  I.e., the
administrator is sent a jabber/e-mail/whatever ping that some machine
needs to reboot, and then she needs to go to a web page and authorize
the operation.  Otherwise, the machine cannot boot.  This might
introduce network timeouts, but if the Mandos client is robust about
that there shouldn't be a problem.

This would protect against someone stealing a server without keeping it
powered.

You'll have a problem if someone also gets control of the Mandos server
though...

Maybe one could extend the scheme, so that N out of M machines have to
participate in reconstructing the blob before any single machine can
boots.  Just getting control of <N of the M machine should not reveal
any information.

Whether this aspect is useful depends on your threat model.  Maybe your
model is different from what I assumed...

> Oh yes, the project's home page:  http://www.fukt.bsnet.se/mandos

Thanks, added to <http://www.gnu.org/software/gnutls/programs.html>.

/Simon




From teddy at fukt.bsnet.se  Wed Oct  8 23:33:03 2008
From: teddy at fukt.bsnet.se (Teddy Hogeborn)
Date: Wed, 08 Oct 2008 23:33:03 +0200
Subject: [Help-gnutls] Re: Announcement: Yet another GnuTLS-using program:
	Mandos
In-Reply-To: <878wszsd3g.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Wed, 08 Oct 2008 10:30:43 +0200")
References: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>
	<878wszsd3g.fsf@mocca.josefsson.org>
Message-ID: <871vyqpyb4.fsf@tower.fukt.bsnet.se>

Simon Josefsson <simon at josefsson.org> writes:

> Cool!

Thank you!

>> The Mandos client connects to the Mandos server.  The Mandos
>> clients each have an OpenPGP key, which they use to handshake as
>> TLS *servers* to the Mandos server, which in turn handshakes as a
>> TLS *client*.  The Mandos server does not have a key, but computes
>> the fingerprint of the OpenPGP key received from the Mandos client
>> and looks up that fingerprint in an internal list, and, if the
>> fingerprint is found, sends the corresponding binary blob to the
>> client.
[...]
> I'm not sure you have to do the handshake backwards, couldn't just
> the mandos server have a OpenPGP key that the mandos client doesn't
> need to validate?

Yeah, but why?  First we'd have to generate a key on the server on
installation, which would take a lot of time and entropy for no
reason.  And then we'd have an extra file to read (extra code) and
manage (more code at installation and uninstallation to make sure the
file is there and preserved, etc.).  We'd also have to make sure the
server requires an OpenPGP certificate from the clients, which would
mean even more code.  But, doing the handshake the other way around
gets us exactly what we want, for free.

Is there a good reason to go though all that trouble to do it the
"normal" way?

> One additional idea I get is to add some mechanism in the Mandos
> server to require authorization before sending the blob.  I.e., the
> administrator is sent a jabber/e-mail/whatever ping that some
> machine needs to reboot, and then she needs to go to a web page and
> authorize the operation.  Otherwise, the machine cannot boot.

That would indeed be a useful feature.  One of the features we are
most likely to implement next (already in our TODO file) is the means
to communicate (locally) with the server and list/edit current
enabled/disabled clients (see below).  This interface could then be
used by some web-accessible program, like you suggest.

> This might introduce network timeouts, but if the Mandos client is
> robust about that there shouldn't be a problem.

I'm not sure what you mean.  Should not a TLS connection over TCP be
alive indefinitely even if no data is sent over it?

> This would protect against someone stealing a server without keeping
> it powered.

What I did not mention in the announcement (because it was not
directly related to GnuTLS) is that the Mandos server periodically
checks the online status of all the clients, and if a client has been
down for too long, it no longer gives out the encrypted key.  The
timings and checking method can be individually configured.

> You'll have a problem if someone also gets control of the Mandos
> server though...

If you by "control" mean "physical access", then no, not if the Mandos
server also has an encrypted file system.  But if you by "control"
mean "root", then yes, if someone gets root on the Mandos server and
*also* physical access to the Mandos clients, the game is lost.  Root
access has always been bad news.

The point is, any one of those things only gives half of the key; an
attacker would need both physical control of a Mandos client *and*
root on the Mandos server to successfully decrypt the clients' disks.

> Maybe one could extend the scheme, so that N out of M machines have
> to participate in reconstructing the blob before any single machine
> can boots.  Just getting control of <N of the M machine should not
> reveal any information.

I don't really see how this could be useful, since the client machine
must be able to construct a file system key using only its OpenPGP key
and a network connection.  Therefore, regardless what hoops you make
it jump through, anyone with access to that key could perform the same
action it does and get the file system key.

Wait a minute, you mean to protect against someone getting root access
on the Mandos server?  Then you are correct, it would lower the
information exposure if that were to happen.  Oh well, that can wait
until version 2.  :-)

Protecting against someone with root access has never been our
priority; our primary goal has always been to protect against physical
removal of the servers.  Not saving the encryption keys in the clear
on the server was just a sudden attack of common sense, not really
meant as a real defense against someone with root on the Mandos
server.

> Whether this aspect is useful depends on your threat model.  Maybe
> your model is different from what I assumed...

I would direct your attention to the FAQ and Security Summary, both of
which are contained within the README file:

http://bzr.fukt.bsnet.se/loggerhead/mandos/trunk/annotate/head:/README

>> Oh yes, the project's home page:  http://www.fukt.bsnet.se/mandos
>
> Thanks, added to <http://www.gnu.org/software/gnutls/programs.html>.

Thank you!

/Teddy Hogeborn & Bj?rn P?hlsson, the Mandos Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: </pipermail/attachments/20081008/33480858/attachment.pgp>

From simon at josefsson.org  Thu Oct  9 08:44:18 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 09 Oct 2008 08:44:18 +0200
Subject: [Help-gnutls] Re: Announcement: Yet another GnuTLS-using program:
	Mandos
In-Reply-To: <871vyqpyb4.fsf@tower.fukt.bsnet.se> (Teddy Hogeborn's message of
	"Wed, 08 Oct 2008 23:33:03 +0200")
References: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>
	<878wszsd3g.fsf@mocca.josefsson.org>
	<871vyqpyb4.fsf@tower.fukt.bsnet.se>
Message-ID: <87od1u469p.fsf@mocca.josefsson.org>

Teddy Hogeborn <teddy at fukt.bsnet.se> writes:

>> I'm not sure you have to do the handshake backwards, couldn't just
>> the mandos server have a OpenPGP key that the mandos client doesn't
>> need to validate?
>
> Yeah, but why?  First we'd have to generate a key on the server on
> installation, which would take a lot of time and entropy for no
> reason.  And then we'd have an extra file to read (extra code) and
> manage (more code at installation and uninstallation to make sure the
> file is there and preserved, etc.).  We'd also have to make sure the
> server requires an OpenPGP certificate from the clients, which would
> mean even more code.  But, doing the handshake the other way around
> gets us exactly what we want, for free.
>
> Is there a good reason to go though all that trouble to do it the
> "normal" way?

No, probably not, and I agree with reducing complexity in this way here.

>> This might introduce network timeouts, but if the Mandos client is
>> robust about that there shouldn't be a problem.
>
> I'm not sure what you mean.  Should not a TLS connection over TCP be
> alive indefinitely even if no data is sent over it?

NAT firewalls tend to drop TCP sessions without any traffic over them
after some time.  Possibly the client could retry after some interval.
Maybe your protocol could contain a ping-function.  This would add some
complexity, so for simplicity might be better to avoid.

>> You'll have a problem if someone also gets control of the Mandos
>> server though...
>
> If you by "control" mean "physical access", then no, not if the Mandos
> server also has an encrypted file system.  But if you by "control"
> mean "root", then yes, if someone gets root on the Mandos server and
> *also* physical access to the Mandos clients, the game is lost.  Root
> access has always been bad news.
>
> The point is, any one of those things only gives half of the key; an
> attacker would need both physical control of a Mandos client *and*
> root on the Mandos server to successfully decrypt the clients' disks.

Right.  The blob sent from the Mandos server is only possible to decrypt
by the particular Mandos client, right?

>> Maybe one could extend the scheme, so that N out of M machines have
>> to participate in reconstructing the blob before any single machine
>> can boots.  Just getting control of <N of the M machine should not
>> reveal any information.
>
> I don't really see how this could be useful, since the client machine
> must be able to construct a file system key using only its OpenPGP key
> and a network connection.  Therefore, regardless what hoops you make
> it jump through, anyone with access to that key could perform the same
> action it does and get the file system key.

Only if the Mandos servers send the blob to the system.

> Wait a minute, you mean to protect against someone getting root access
> on the Mandos server?  Then you are correct, it would lower the
> information exposure if that were to happen.

Yes, protecting against an attacker getting control of the Mandos server
was what I was thinking about.  If you have many Mandos servers, getting
control of sufficient many of them will be practically difficult.  You
can make them run wildly different OS's that are unlikely to suffer from
similar security problems as well.  If the protocol requires that you
need co-operation from >=N Mandos servers to boot a particular server,
this approach would add some assurance for sufficiently paranoid
individuals.

> Oh well, that can wait until version 2.  :-)

Or left as an exercise for the reader. :)

> Protecting against someone with root access has never been our
> priority; our primary goal has always been to protect against physical
> removal of the servers.  Not saving the encryption keys in the clear
> on the server was just a sudden attack of common sense, not really
> meant as a real defense against someone with root on the Mandos
> server.

Understood.

/Simon




From teddy at fukt.bsnet.se  Thu Oct  9 09:42:06 2008
From: teddy at fukt.bsnet.se (Teddy Hogeborn)
Date: Thu, 09 Oct 2008 09:42:06 +0200
Subject: [Help-gnutls] Re: Announcement: Yet another GnuTLS-using program:
	Mandos
In-Reply-To: <87od1u469p.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Thu, 09 Oct 2008 08:44:18 +0200")
References: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>
	<878wszsd3g.fsf@mocca.josefsson.org>
	<871vyqpyb4.fsf@tower.fukt.bsnet.se>
	<87od1u469p.fsf@mocca.josefsson.org>
Message-ID: <87fxn6fc4x.fsf@tower.fukt.bsnet.se>

Simon Josefsson <simon at josefsson.org> writes:

> Teddy Hogeborn <teddy at fukt.bsnet.se> writes:
>
>>> This might introduce network timeouts, but if the Mandos client is
>>> robust about that there shouldn't be a problem.
>>
>> I'm not sure what you mean.  Should not a TLS connection over TCP
>> be alive indefinitely even if no data is sent over it?
>
> NAT firewalls tend to drop TCP sessions without any traffic over
> them after some time.  Possibly the client could retry after some
> interval.  Maybe your protocol could contain a ping-function.  This
> would add some complexity, so for simplicity might be better to
> avoid.

If this really would be a problem for somebody, should not this simply
be solved by setting SO_KEEPALIVE?  Now, the system as it is today is
restricted to the local network (no network configured in the initrd,
so we use IPv6 link-local addresses), so this should never happen.

>> The point is, any one of those things only gives half of the key;
>> an attacker would need both physical control of a Mandos client
>> *and* root on the Mandos server to successfully decrypt the
>> clients' disks.
>
> Right.  The blob sent from the Mandos server is only possible to
> decrypt by the particular Mandos client, right?

Yes, exactly.

>> Oh well, that can wait until version 2.  :-)
>
> Or left as an exercise for the reader. :)

Yes, we created the plugin system partly for this. :)

/Teddy Hogeborn & Bj?rn P?hlsson, the Mandos Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: </pipermail/attachments/20081009/c369b172/attachment.pgp>

From simon at josefsson.org  Thu Oct  9 12:22:57 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 09 Oct 2008 12:22:57 +0200
Subject: [Help-gnutls] Re: Announcement: Yet another GnuTLS-using program:
	Mandos
In-Reply-To: <87fxn6fc4x.fsf@tower.fukt.bsnet.se> (Teddy Hogeborn's message of
	"Thu, 09 Oct 2008 09:42:06 +0200")
References: <87k5cjc1l3.fsf@tower.fukt.bsnet.se>
	<878wszsd3g.fsf@mocca.josefsson.org>
	<871vyqpyb4.fsf@tower.fukt.bsnet.se>
	<87od1u469p.fsf@mocca.josefsson.org>
	<87fxn6fc4x.fsf@tower.fukt.bsnet.se>
Message-ID: <87zlle2hku.fsf@mocca.josefsson.org>

Teddy Hogeborn <teddy at fukt.bsnet.se> writes:

> Simon Josefsson <simon at josefsson.org> writes:
>
>> Teddy Hogeborn <teddy at fukt.bsnet.se> writes:
>>
>>>> This might introduce network timeouts, but if the Mandos client is
>>>> robust about that there shouldn't be a problem.
>>>
>>> I'm not sure what you mean.  Should not a TLS connection over TCP
>>> be alive indefinitely even if no data is sent over it?
>>
>> NAT firewalls tend to drop TCP sessions without any traffic over
>> them after some time.  Possibly the client could retry after some
>> interval.  Maybe your protocol could contain a ping-function.  This
>> would add some complexity, so for simplicity might be better to
>> avoid.
>
> If this really would be a problem for somebody, should not this simply
> be solved by setting SO_KEEPALIVE?

Possibly, although I'm not certain.

> Now, the system as it is today is restricted to the local network (no
> network configured in the initrd, so we use IPv6 link-local
> addresses), so this should never happen.

Ah, that changes the model somewhat.  I guess it could be extended to
use DHCP and talk to a Mandos server somewhere else on the Internet
though.

/Simon




From darkdemun at gmail.com  Sat Oct 11 13:08:00 2008
From: darkdemun at gmail.com (darkdemun)
Date: Sun, 12 Oct 2008 00:08:00 +1300
Subject: [Help-gnutls] Recv timeout
Message-ID: <11d59200810110408w3e1d8416w48d475468d754d76@mail.gmail.com>

Hi, do you set a recv timeout as you normally would when using gnutls,
or is there a special way? (on windows). Thanks
-- 
Cain.




From darkdemun at gmail.com  Sat Oct 11 13:09:03 2008
From: darkdemun at gmail.com (darkdemun)
Date: Sun, 12 Oct 2008 00:09:03 +1300
Subject: [Help-gnutls] Recv timeout
Message-ID: <11d59200810110409x11920f9av8b681fa5f037762e@mail.gmail.com>

Hi, do you set a recv timeout as you normally would when using gnutls,
or is there a special way? (on windows). Thanks
-- 
Cain.




From nmav at gnutls.org  Sun Oct 12 10:15:53 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 12 Oct 2008 11:15:53 +0300
Subject: [Help-gnutls] Recv timeout
In-Reply-To: <11d59200810110408w3e1d8416w48d475468d754d76@mail.gmail.com>
References: <11d59200810110408w3e1d8416w48d475468d754d76@mail.gmail.com>
Message-ID: <48F1B239.3000503@gnutls.org>

darkdemun wrote:
> Hi, do you set a recv timeout as you normally would when using gnutls,
> or is there a special way? (on windows). Thanks

You cannot set a timeout on gnutls. You can set a timeout on the socket,
and this indeed would be done "normally".

regards,
Nikos






From rogge at fgan.de  Thu Oct 30 11:37:45 2008
From: rogge at fgan.de (Henning Rogge)
Date: Thu, 30 Oct 2008 11:37:45 +0100
Subject: [Help-gnutls] Signing multicast traffic with gnutls API ?
Message-ID: <200810301137.51572.rogge@fgan.de>

Hello,

I'm working on a small application to distribute flooding traffic in a mobile 
adhoc network. The application use retransmission and duplicate suppression at 
the moment, but it has no way to authentificate the broadcasted messages.

The easiest sollution seems to sign a hash value of every package with a 
asymmetric public key and check this signature at the receiver/retransmitter.

Can I use the gnutls api for this case ? Each node will have a X509 keyring 
with the public keys of all nodes and signed by a trusted root CA, so key 
distribution is not necessary.

Henning Rogge

*************************************************
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: </pipermail/attachments/20081030/d6be8a7d/attachment.htm>
-------------- 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: </pipermail/attachments/20081030/d6be8a7d/attachment.pgp>

From nmav at gnutls.org  Thu Oct 30 12:01:38 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 13:01:38 +0200
Subject: [Help-gnutls] Signing multicast traffic with gnutls API ?
In-Reply-To: <200810301137.51572.rogge@fgan.de>
References: <200810301137.51572.rogge@fgan.de>
Message-ID: <c331d99a0810300401m754921fcp3da5204ab640345a@mail.gmail.com>

Actually you cannot use TLS as a protocol since you don't have peer to
peer communication to perform a handshake. You could use
gnutls_x509_privkey_sign_data() and verify_data().

regards,
Nikos

On Thu, Oct 30, 2008 at 12:37 PM, Henning Rogge <rogge at fgan.de> wrote:
> Hello,
>
> I'm working on a small application to distribute flooding traffic in a
> mobile adhoc network. The application use retransmission and duplicate
> suppression at the moment, but it has no way to authentificate the
> broadcasted messages.
>
> The easiest sollution seems to sign a hash value of every package with a
> asymmetric public key and check this signature at the
> receiver/retransmitter.
>
> Can I use the gnutls api for this case ? Each node will have a X509 keyring
> with the public keys of all nodes and signed by a trusted root CA, so key
> distribution is not necessary.
>
> Henning Rogge
>
> *************************************************
>
> 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.)
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> http://lists.gnu.org/mailman/listinfo/help-gnutls
>
>




From martin.knappe at gmail.com  Thu Oct 30 13:51:47 2008
From: martin.knappe at gmail.com (Martin Knappe)
Date: Thu, 30 Oct 2008 13:51:47 +0100
Subject: [Help-gnutls] Diffy-Hellman: Regeneration of prime and primitive
	root
Message-ID: <1918c28b0810300551h303cdca6wf232465cc358109f@mail.gmail.com>

Hi

I have seen source code examples of servers implementing Diffie Hellman and
noticed that these often regenerate the prime and primitive root used to
generate the shared secret. My questions:

1) Under what conditions is this necessary?
2) Why is this necessary?
3) How to find out the correct interval at which regeneration becomes
necessary?

Hope someone here can help me...

Thanks

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081030/863f9cb3/attachment.htm>

From mike at reys.be  Thu Oct 30 18:06:51 2008
From: mike at reys.be (mike at reys.be)
Date: Thu, 30 Oct 2008 18:06:51 +0100 (CET)
Subject: [Help-gnutls] Not at home
Message-ID: <20081030170651.16DD038E07371@zulu.openminds.be>

Hi,

thanks for your mail, I'm travelling and reading my mail will not
always be possible. I'll get back to you as soon as possible.

Cheers,

Mike





From martin.knappe at gmail.com  Thu Oct 30 18:14:49 2008
From: martin.knappe at gmail.com (Martin Knappe)
Date: Thu, 30 Oct 2008 18:14:49 +0100
Subject: [Help-gnutls] examples won't compile
Message-ID: <1918c28b0810301014l3ac61c69v545f149ce6ca2e24@mail.gmail.com>

Hi

I'm new to gnutls and I've tried to compile the "Echo server with SRP
authentication" which can be found under *
http://www.gnu.org/software/gnutls/manual/html_node/Echo-Server-with-SRP-authentication.html#Echo-Server-with-SRP-authentication
.
Compiling with

martin at martin-desktop:~/development/examples/srp_server$ gcc main.c
`libgnutls-config --cflags --libs`

gives me:

/tmp/cc2WjvhH.o: In function `initialize_tls_session':
main.c:(.text+0x30): undefined reference to `gnutls_priority_set_direct'
/tmp/cc2WjvhH.o: In function `main':
main.c:(.text+0xd2): undefined reference to `gnutls_global_init_extra'
collect2: ld gab 1 als Ende-Status zur?ck

I reckon this is because I am using an older version of gnutls (2.0.4).

Is there a similar manual like

http://www.gnu.org/software/gnutls/manual/

for my version? I want to use the version I have and not update.

Many thanks

Martin

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20081030/5a22dd84/attachment.htm>

From nmav at gnutls.org  Thu Oct 30 18:56:55 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 19:56:55 +0200
Subject: [Help-gnutls] Signing multicast traffic with gnutls API ?
In-Reply-To: <c331d99a0810300401m754921fcp3da5204ab640345a@mail.gmail.com>
References: <200810301137.51572.rogge@fgan.de>
	<c331d99a0810300401m754921fcp3da5204ab640345a@mail.gmail.com>
Message-ID: <4909F567.8060207@gnutls.org>

Nikos Mavrogiannopoulos wrote:

>> The easiest sollution seems to sign a hash value of every package
with a
>> asymmetric public key and check this signature at the
>> receiver/retransmitter.
> Actually you cannot use TLS as a protocol since you don't have peer to
> peer communication to perform a handshake. You could use
> gnutls_x509_privkey_sign_data() and verify_data().

However you must know that replay/reordering attacks and maybe others
are possible, so care must be taken to avoid those if they apply. It
might be better to check if there is already a protocol for signing
broadcasted data, and follow that.

regards,
Nikos





From nmav at gnutls.org  Thu Oct 30 19:10:26 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 20:10:26 +0200
Subject: [Help-gnutls] Diffy-Hellman: Regeneration of prime and primitive
	root
In-Reply-To: <1918c28b0810300551h303cdca6wf232465cc358109f@mail.gmail.com>
References: <1918c28b0810300551h303cdca6wf232465cc358109f@mail.gmail.com>
Message-ID: <4909F892.4050202@gnutls.org>

Martin Knappe wrote:
> Hi
> 
> I have seen source code examples of servers implementing Diffie Hellman and
> noticed that these often regenerate the prime and primitive root used to
> generate the shared secret. My questions:
> 1) Under what conditions is this necessary?

There are pros and cons with both approaches of generating random
parameters and using the included ones.

The included parameters have no known weakness. However if a weakness is
found it applies to all servers using them.

By generating random parameters (that pass some tests) you are positive
that there are no known weaknesses yet, but because the prime is random,
the group might have properties that will allow an attacker to mount a
group specific attack. To avoid having an attacker trying to break the
specific group you selected randomly you change the random prime often
(once per month/season etc.).

> 2) Why is this necessary?
It is not necessary. For many people the included are ok.

> 3) How to find out the correct interval at which regeneration becomes
> necessary?
The suit answer would be to calculate the probability p(n) of one
breaking your specific prime in n months and multiply with the losses
you might have if he breaks it. This gives you a number you are expected
to lose in that time. If it is acceptable regenerate them every n
months. Otherwise increase the n.

The normal answer would be not to bother. Probabilities such as these
are nice to show in presentations but hardly offer anything in that case.

regards,
Nikos




From nmav at gnutls.org  Thu Oct 30 19:11:45 2008
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 30 Oct 2008 20:11:45 +0200
Subject: [Help-gnutls] examples won't compile
In-Reply-To: <1918c28b0810301014l3ac61c69v545f149ce6ca2e24@mail.gmail.com>
References: <1918c28b0810301014l3ac61c69v545f149ce6ca2e24@mail.gmail.com>
Message-ID: <4909F8E1.6070306@gnutls.org>

Martin Knappe wrote:
> Hi
> 
> I'm new to gnutls and I've tried to compile the "Echo server with SRP
> authentication" which can be found under *
> http://www.gnu.org/software/gnutls/manual/html_node/Echo-Server-with-SRP-authentication.html#Echo-Server-with-SRP-authentication
> .
> Compiling with
> 
> martin at martin-desktop:~/development/examples/srp_server$ gcc main.c
> `libgnutls-config --cflags --libs`
> 
> gives me:
> 
> /tmp/cc2WjvhH.o: In function `initialize_tls_session':
> main.c:(.text+0x30): undefined reference to `gnutls_priority_set_direct'
> /tmp/cc2WjvhH.o: In function `main':
> main.c:(.text+0xd2): undefined reference to `gnutls_global_init_extra'
> collect2: ld gab 1 als Ende-Status zur?ck
> 
> I reckon this is because I am using an older version of gnutls (2.0.4).

Either download gnutls 2.0.4 and use the included manual or download the
manual from your distributor (in debian it is in gnutls-doc).

regards,
Nikos




From kpfleming at digium.com  Thu Oct 30 23:40:26 2008
From: kpfleming at digium.com (Kevin P. Fleming)
Date: Thu, 30 Oct 2008 17:40:26 -0500
Subject: [Help-gnutls] Key usage violation in certificate
Message-ID: <490A37DA.6090400@digium.com>

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.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)




From simon at josefsson.org  Fri Oct 31 00:01:42 2008
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 31 Oct 2008 00:01:42 +0100
Subject: [Help-gnutls] Re: Key usage violation in certificate
In-Reply-To: <490A37DA.6090400@digium.com> (Kevin P. Fleming's message of
	"Thu, 30 Oct 2008 17:40:26 -0500")
References: <490A37DA.6090400@digium.com>
Message-ID: <87skqdelgp.fsf@mocca.josefsson.org>

"Kevin P. Fleming" <kpfleming at digium.com> writes:

> 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.

I can't seem to connect to that server using GnuTLS or OpenSSL.  I don't
think this is a certificate validation error, it seems the handshake
fails.  What does the server logs say?

/Simon

jas at mocca:~$ openssl s_client -connect origsvn.digium.com:443
CONNECTED(00000003)
depth=1 /C=US/ST=Alabama/L=Huntsville/O=Digium, Inc./OU=Asterisk Development Team/CN=Digium SVN CA/emailAddress=asteriskteam at digium.com
verify error:num=19:self signed certificate in certificate chain
verify return:0
16123:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40
16123:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
jas at mocca:~$ gnutls-cli -p 443 origsvn.digium.com -d 4711
Resolving 'origsvn.digium.com'...
Connecting to '216.207.245.42:443'...
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8fdc0f8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8fdc0f8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[8fdc0f8]: Sending extension CERT_TYPE
|<2>| EXT[8fdc0f8]: Sending extension SERVER_NAME
|<3>| HSK[8fdc0f8]: CLIENT HELLO was send [119 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8fdc0f8]: Sending Packet[0] Handshake(22) with length: 119
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 124 bytes to 4.
|<7>| WRITE: wrote 124 bytes to 4. Left 0 bytes. Total 124 bytes.
|<7>| 0000 - 16 03 02 00 77 01 00 00 73 03 02 49 0a 3c 73 b5 
|<7>| 0001 - 22 6a 86 33 0c 1f 5a 38 90 c1 9c 32 07 a2 a4 86 
|<7>| 0002 - 70 c8 fa dd 4b a0 98 5a 59 85 25 00 00 28 00 33 
|<7>| 0003 - 00 39 00 16 00 32 00 38 00 13 00 66 00 90 00 91 
|<7>| 0004 - 00 8f 00 8e 00 2f 00 35 00 0a 00 05 00 04 00 8c 
|<7>| 0005 - 00 8d 00 8b 00 8a 01 00 00 22 00 09 00 03 02 00 
|<7>| 0006 - 01 00 00 00 17 00 15 00 00 12 6f 72 69 67 73 76 
|<7>| 0007 - 6e 2e 64 69 67 69 75 6d 2e 63 6f 6d 
|<4>| REC[8fdc0f8]: Sent Packet[1] Handshake(22) with length: 124
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 4a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8fdc0f8]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[8fdc0f8]: Received Packet[0] Handshake(22) with length: 74
|<7>| READ: Got 74 bytes from 4
|<7>| READ: read 74 bytes from 4
|<7>| 0000 - 02 00 00 46 03 01 49 0a 3c 78 74 52 4b 24 0c 7d 
|<7>| 0001 - 04 cd 14 5f e5 e0 83 be 7a d4 ae 55 01 ef aa e1 
|<7>| 0002 - 2f 0c 35 20 91 7e 20 60 00 29 9d ff 2a bf 7d 21 
|<7>| 0003 - fe 2d f9 c2 c6 06 3f 04 80 47 43 8c a0 77 f7 e9 
|<7>| 0004 - e4 61 94 f2 67 a1 3e 00 33 00 
|<7>| RB: Have 5 bytes into buffer. Adding 74 bytes.
|<7>| RB: Requested 79 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[8fdc0f8]: 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[8fdc0f8]: 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[8fdc0f8]: Server's version: 3.1
|<3>| HSK[8fdc0f8]: SessionID length: 32
|<3>| HSK[8fdc0f8]: SessionID: 6000299dff2abf7d21fe2df9c2c6063f048047438ca077f7e9e46194f267a13e
|<3>| HSK[8fdc0f8]: Selected cipher suite: DHE_RSA_AES_128_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:124
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 0b 1e 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8fdc0f8]: Expected Packet[1] Handshake(22) with length: 1
|<4>| REC[8fdc0f8]: Received Packet[1] Handshake(22) with length: 2846
|<7>| READ: Got 1364 bytes from 4
|<7>| READ: Got 1448 bytes from 4
|<7>| READ: Got 34 bytes from 4
|<7>| READ: read 2846 bytes from 4
|<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 fd 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 30 32 32 31 35 33 32 5a 17 0d 31 
|<7>| 000f - 38 31 30 32 38 32 32 31 35 33 32 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 25 64 44 58 cd 9e 01 42 
|<7>| 004a - 91 76 f4 90 7d 09 4f 59 b7 3d bf 4f cb c1 d1 22 
|<7>| 004b - c5 ad 2c b1 67 f7 71 f5 b0 46 70 bd 92 1c e3 5b 
|<7>| 004c - 75 91 c0 50 b5 c4 b6 0c df 7a a7 1f 8c 0e 20 9b 
|<7>| 004d - 73 b3 cc bf 07 24 92 fd 29 b4 bc 55 38 05 2f 5b 
|<7>| 004e - 90 76 12 53 97 c0 7a 7e d3 01 75 73 ea 74 4f ce 
|<7>| 004f - 43 ab c3 00 47 33 a8 34 39 49 cd 33 93 9e 85 e7 
|<7>| 0050 - 25 2a cd cf aa 59 60 71 52 81 68 71 47 50 2d 78 
|<7>| 0051 - b2 14 59 19 8e 15 98 31 33 11 ff dd 52 c9 4a 1a 
|<7>| 0052 - 20 8d 8d a5 a5 00 2b a2 a3 f2 8c 68 14 7d b3 9d 
|<7>| 0053 - ba 26 82 54 07 ce 24 de 92 ae 71 e9 92 60 15 bc 
|<7>| 0054 - 88 55 28 4f f9 6c 3b 32 f2 3f ed 29 56 03 f2 66 
|<7>| 0055 - fe 40 8f fa 7d 14 bf 26 5a 12 cc 65 a6 d9 0c 93 
|<7>| 0056 - a0 72 64 29 ef 66 91 df dd 70 2e c4 f9 a3 16 81 
|<7>| 0057 - 7b 8e 00 1e bb 89 24 6e e3 99 00 a4 d9 c5 6b ac 
|<7>| 0058 - 71 0d a4 2e b5 14 fc 0c a8 07 59 40 e1 7f c9 8c 
|<7>| 0059 - 74 00 08 eb b7 97 28 fe 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:204
|<4>| REC[8fdc0f8]: 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[8fdc0f8]: 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 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 02 0d 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8fdc0f8]: Expected Packet[2] Handshake(22) with length: 1
|<4>| REC[8fdc0f8]: Received Packet[2] Handshake(22) with length: 525
|<7>| READ: Got 525 bytes from 4
|<7>| READ: read 525 bytes from 4
|<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 3b d5 b3 04 07 
|<7>| 0009 - e1 74 f0 16 7f 07 4c 85 35 cd e5 62 c5 25 42 8e 
|<7>| 000a - f9 89 75 dd 5f 2b 46 79 d7 87 6d 7f 6b b3 d3 e8 
|<7>| 000b - 41 34 cc cf f1 5f 51 c0 72 a3 83 e1 c5 f2 14 16 
|<7>| 000c - 48 3b 6e b6 d9 bb 57 9e 3f e8 22 5c f0 52 9c 60 
|<7>| 000d - f8 fb ec 16 53 dd a5 80 43 a0 02 b5 cc 43 7e 68 
|<7>| 000e - bf 1d 5d c3 b3 65 ec 29 90 2e a7 0b 63 51 70 f5 
|<7>| 000f - d7 c8 59 d7 2e 30 33 9e 2e 05 6b fc 62 f8 18 c6 
|<7>| 0010 - 38 65 4b ce 3a 4b 47 d2 b9 75 c6 01 00 64 92 a1 
|<7>| 0011 - 4d d6 98 00 93 9b 1d d8 a4 01 80 c1 d3 de 08 b8 
|<7>| 0012 - db 07 66 7f aa 93 45 8d 48 bb ae 2f 6e df 26 bc 
|<7>| 0013 - 8e ba 3f e1 e1 96 d1 6a 67 d8 73 11 ed 0f d8 36 
|<7>| 0014 - 30 ba c6 ba d7 af 09 08 9e d3 9c ae 6b d3 b8 3e 
|<7>| 0015 - f0 f5 b6 7d e6 2e 07 15 e2 49 a0 bd b4 4d 17 f3 
|<7>| 0016 - eb bc 3c 21 f2 4f 34 3d 44 5e bc 77 44 95 a6 19 
|<7>| 0017 - d3 62 1c 2f 78 e6 3f 53 dd 6f 41 69 65 f0 63 47 
|<7>| 0018 - 8a 98 f5 40 35 26 c2 ad f9 f8 5b 9a 19 4a 7f cd 
|<7>| 0019 - f4 72 25 4d c2 ac b3 94 da 1b a3 22 8b f8 c8 07 
|<7>| 001a - 68 b8 bd 29 3c e8 8d d0 06 1c 62 a9 fb 49 89 52 
|<7>| 001b - aa af f4 93 27 84 28 2a d5 8b d1 80 8b 65 88 7b 
|<7>| 001c - 3a 86 21 c2 25 f8 0f 03 32 72 c6 59 11 24 05 1b 
|<7>| 001d - 50 4c 23 6e 6b b2 cf bf 00 24 b1 c1 98 d9 84 c7 
|<7>| 001e - 01 50 33 5b e3 f4 94 1e d4 52 4e c8 90 83 fd 84 
|<7>| 001f - ef e5 3a bc 12 1e c0 08 ca cf b1 cb 23 84 be 25 
|<7>| 0020 - 30 ca e5 15 84 ac c1 4a f5 80 4b b1 ba 
|<7>| RB: Have 5 bytes into buffer. Adding 525 bytes.
|<7>| RB: Requested 530 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[8fdc0f8]: 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[8fdc0f8]: 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 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 16 03 01 00 c3 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8fdc0f8]: Expected Packet[3] Handshake(22) with length: 1
|<4>| REC[8fdc0f8]: Received Packet[3] Handshake(22) with length: 195
|<7>| READ: Got 195 bytes from 4
|<7>| READ: read 195 bytes from 4
|<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:204
|<4>| REC[8fdc0f8]: 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[8fdc0f8]: 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
- Successfully sent 0 certificate(s) to server.
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[8fdc0f8]: 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[8fdc0f8]: CERTIFICATE was send [7 bytes]
|<6>| BUF[HSK]: Peeked 4 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8fdc0f8]: Sending Packet[1] Handshake(22) with length: 7
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 12 bytes to 4.
|<7>| WRITE: wrote 12 bytes to 4. Left 0 bytes. Total 12 bytes.
|<7>| 0000 - 16 03 01 00 07 0b 00 00 03 00 00 00 
|<4>| REC[8fdc0f8]: Sent Packet[2] Handshake(22) with length: 12
|<3>| HSK[8fdc0f8]: CLIENT KEY EXCHANGE was send [134 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8fdc0f8]: Sending Packet[2] Handshake(22) with length: 134
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 139 bytes to 4.
|<7>| WRITE: wrote 139 bytes to 4. Left 0 bytes. Total 139 bytes.
|<7>| 0000 - 16 03 01 00 86 10 00 00 82 00 80 ca 3e 42 62 97 
|<7>| 0001 - 21 6e 2e 44 70 e0 58 42 d3 11 ce 1c 51 2d c3 30 
|<7>| 0002 - da c0 c3 de 8a 01 8d 58 18 4f 9e 2c 3b 74 99 69 
|<7>| 0003 - 15 d4 11 d9 7a 81 62 e8 64 62 04 cf df 58 17 5c 
|<7>| 0004 - 9e 46 fd f4 5f 32 f6 cf 9e 6c e3 d6 a1 c1 68 aa 
|<7>| 0005 - d6 71 11 ff 63 13 c0 be 41 d4 70 eb 81 b0 47 41 
|<7>| 0006 - 69 43 46 08 bf 7f 45 31 df f4 cb 79 29 23 43 2a 
|<7>| 0007 - b1 08 b1 39 50 fe 6a 86 dc 03 e9 f7 3e cc 36 96 
|<7>| 0008 - be 1d 2a 57 40 c3 d9 62 e5 89 18 
|<4>| REC[8fdc0f8]: Sent Packet[3] Handshake(22) with length: 139
|<3>| REC[8fdc0f8]: Sent ChangeCipherSpec
|<4>| REC[8fdc0f8]: Sending Packet[3] Change Cipher Spec(20) with length: 1
|<2>| ASSERT: gnutls_cipher.c:204
|<7>| WRITE: Will write 6 bytes to 4.
|<7>| WRITE: wrote 6 bytes to 4. Left 0 bytes. Total 6 bytes.
|<7>| 0000 - 14 03 01 00 01 01 
|<4>| REC[8fdc0f8]: Sent Packet[4] Change Cipher Spec(20) with length: 6
|<9>| INT: PREMASTER SECRET[128]: b50ee5a149b39392810f07608e830b8912d1c5f8081d5fb88766a366849cf95f51ab8d75d91e4b2ea32f93c5f1ce2be70a39921587040c9d2a8fb1392118e7e58da7aa78928a2848b936b34683a12c370d37342297e92bde90ed54c6704abb11ede1c2b82c3c7fd454651250903a7a11072f3319e2989b417bcc5ee03a3daaff
|<9>| INT: CLIENT RANDOM[32]: 490a3c73b5226a86330c1f5a3890c19c3207a2a48670c8fadd4ba0985a598525
|<9>| INT: SERVER RANDOM[32]: 490a3c7874524b240c7d04cd145fe5e083be7ad4ae5501efaae12f0c3520917e
|<9>| INT: MASTER SECRET: 9ab14ca65000091bbadf7532d049645c70fe9c61a4970534ea061faa95a618e9cbfd918cd444706319fa364d45d1e5fe
|<9>| INT: KEY BLOCK[104]: 16d7324e089ae1d8c9bc4d75df25366fa636725a06456dffedd9d6ee34f6466c
|<9>| INT: CLIENT WRITE KEY [16]: d54f4f9f5d347e6f25f9ff614d11854b
|<9>| INT: SERVER WRITE KEY [16]: 849f55a75236fde17d05f7b65a1b5ca2
|<3>| HSK[8fdc0f8]: Cipher Suite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8fdc0f8]: Initializing internal [write] cipher sessions
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<3>| HSK[8fdc0f8]: FINISHED was send [16 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8fdc0f8]: Sending Packet[0] Handshake(22) with length: 16
|<7>| WRITE: Will write 245 bytes to 4.
|<7>| WRITE: wrote 245 bytes to 4. Left 0 bytes. Total 245 bytes.
|<7>| 0000 - 16 03 01 00 f0 ab 31 11 14 5b 06 3b 9c 37 9e 4f 
|<7>| 0001 - d9 12 dc eb 6b 32 7a 75 ee f8 e7 30 9c 88 15 4b 
|<7>| 0002 - d1 89 24 f8 c1 1e 88 c9 60 b6 e9 66 75 b1 25 bd 
|<7>| 0003 - 8e 42 37 d1 38 c9 2a 8c 6e 48 58 cd 22 8d e6 e9 
|<7>| 0004 - 5c 08 52 ee 17 29 1d 6e dc b9 cf a7 cd 39 e6 e8 
|<7>| 0005 - a7 de 51 97 74 b3 a6 44 a0 ea 15 3c f6 a8 eb 4e 
|<7>| 0006 - aa 21 80 15 a7 0b 50 55 63 56 88 e9 40 18 5d 74 
|<7>| 0007 - b6 b2 dc b3 70 88 25 3f 2b bb d1 89 3b 3f da 4c 
|<7>| 0008 - 5c 6c 6d 69 74 24 5e d9 51 63 92 cb ef 7f 13 b3 
|<7>| 0009 - e4 93 9b 0c 1c ab 55 51 48 39 e9 b0 82 35 95 47 
|<7>| 000a - 03 0e 84 a1 61 e3 fc 8d 8c 4d 42 bd 51 9d d4 8b 
|<7>| 000b - cc c8 cd 6c 3d 92 dc ad f6 58 19 da f7 19 94 b3 
|<7>| 000c - 45 ad 28 8a 8b b0 f6 29 af 50 e1 92 3a 8d ea b2 
|<7>| 000d - a7 24 96 4b a0 31 bd ba a3 47 9e e5 93 74 32 5d 
|<7>| 000e - bc b7 c7 59 61 b0 02 f2 9b 12 4c f2 5e b8 9b 37 
|<7>| 000f - 25 5e e1 8f 2e 
|<4>| REC[8fdc0f8]: Sent Packet[1] Handshake(22) with length: 245
|<7>| READ: Got 5 bytes from 4
|<7>| READ: read 5 bytes from 4
|<7>| 0000 - 15 03 01 00 02 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[8fdc0f8]: Expected Packet[4] Change Cipher Spec(20) with length: 1
|<4>| REC[8fdc0f8]: Received Packet[4] Alert(21) with length: 2
|<7>| READ: Got 2 bytes from 4
|<7>| READ: read 2 bytes from 4
|<7>| 0000 - 02 28 
|<7>| RB: Have 5 bytes into buffer. Adding 2 bytes.
|<7>| RB: Requested 7 bytes
|<2>| ASSERT: gnutls_cipher.c:204
|<4>| REC[8fdc0f8]: Decrypted Packet[4] Alert(21) with length: 2
|<4>| REC[8fdc0f8]: Alert[2|40] - Handshake failed - was received
|<2>| ASSERT: gnutls_record.c:695
|<2>| ASSERT: gnutls_record.c:1048
|<2>| ASSERT: gnutls_handshake.c:2507
|<2>| ASSERT: gnutls_handshake.c:2679
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
jas at mocca:~$ 





From mike at reys.be  Fri Oct 31 00:03:03 2008
From: mike at reys.be (mike at reys.be)
Date: Fri, 31 Oct 2008 00:03:03 +0100 (CET)
Subject: [Help-gnutls] Not at home
Message-ID: <20081030230303.7654138E07371@zulu.openminds.be>

Hi,

thanks for your mail, I'm travelling and reading my mail will not
always be possible. I'll get back to you as soon as possible.

Cheers,

Mike





From dkg at fifthhorseman.net  Fri Oct 31 01:27:45 2008
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 30 Oct 2008 20:27:45 -0400
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <490A37DA.6090400@digium.com> (Kevin P. Fleming's message of
	"Thu\, 30 Oct 2008 17\:40\:26 -0500")
References: <490A37DA.6090400@digium.com>
Message-ID: <87od11ham6.fsf@squeak.fifthhorseman.net>

On Thu 2008-10-30 18:40:26 -0400, Kevin P. Fleming wrote:

> 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.

I can't seem to connect to your server with either openssl or gnutls,
actually.  Can you?  

[0 dkg at squeak ~]$ openssl s_client -showcerts -verify 5 -connect origsvn.digium.com:443
verify depth is 5
CONNECTED(00000003)
depth=1 /C=US/ST=Alabama/L=Huntsville/O=Digium, Inc./OU=Asterisk Development Team/CN=Digium SVN CA/emailAddress=asteriskteam at digium.com
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 /C=US/ST=Alabama/L=Huntsville/O=Digium, Inc./OU=Asterisk Development Team/CN=Digium SVN CA/emailAddress=asteriskteam at digium.com
verify return:1
depth=0 /C=US/ST=Alabama/L=Huntsville/O=Digium/OU=Asterisk Development Team/CN=origsvn.digium.com/emailAddress=asteriskteam at digium.com
verify return:1
28424:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40
28424:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
[0 dkg at squeak ~]$ gnutls-cli --verbose  origsvn.digium.com --port 443
Resolving 'origsvn.digium.com'...
Connecting to '216.207.245.42:443'...
- Server's trusted authorities:
   [0]: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com
- Successfully sent 0 certificate(s) to server.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.
[1 dkg at squeak ~]$ 

I can apparently connect to it with LibNSS-based clients (ssltap and
iceweasel), but that's it. :(

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </pipermail/attachments/20081030/40fb7774/attachment.pgp>

From kpfleming at digium.com  Fri Oct 31 01:32:26 2008
From: kpfleming at digium.com (Kevin P. Fleming)
Date: Thu, 30 Oct 2008 19:32:26 -0500
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <87od11ham6.fsf@squeak.fifthhorseman.net>
References: <490A37DA.6090400@digium.com>
	<87od11ham6.fsf@squeak.fifthhorseman.net>
Message-ID: <490A521A.4020707@digium.com>

Daniel Kahn Gillmor wrote:

> I can't seem to connect to your server with either openssl or gnutls,
> actually.  Can you?  

Sorry, I forgot to mention that the server requires the presentation of
a client certificate, and will only accept one that we generated from
our CA :-) I'm not at the office right now so I can't send a cert that
people can use to test access, will have to do that tomorrow.

-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)




From rogge at fgan.de  Fri Oct 31 07:29:09 2008
From: rogge at fgan.de (Henning Rogge)
Date: Fri, 31 Oct 2008 07:29:09 +0100
Subject: [Help-gnutls] Signing multicast traffic with gnutls API ?
In-Reply-To: <4909F567.8060207@gnutls.org>
References: <200810301137.51572.rogge@fgan.de>
	<c331d99a0810300401m754921fcp3da5204ab640345a@mail.gmail.com>
	<4909F567.8060207@gnutls.org>
Message-ID: <200810310729.15306.rogge@fgan.de>

Am Thursday 30 October 2008 18:56:55 schrieb Nikos Mavrogiannopoulos:
> Nikos Mavrogiannopoulos wrote:
> > The easiest sollution seems to sign a hash value of every package
> > with a
>
> >> asymmetric public key and check this signature at the
> >> receiver/retransmitter.
> >
> > Actually you cannot use TLS as a protocol since you don't have peer to
> > peer communication to perform a handshake. You could use
> > gnutls_x509_privkey_sign_data() and verify_data().
>
> However you must know that replay/reordering attacks and maybe others
> are possible, so care must be taken to avoid those if they apply.
The flooding service already put a sequence number into the data, which should 
block replay/reordering attacks.

> It
> might be better to check if there is already a protocol for signing
> broadcasted data, and follow that.

Unfortunately I was unable to track down a good way to authenticate multihop 
flooding broadcasts.

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: </pipermail/attachments/20081031/c24bc840/attachment.htm>
-------------- 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: </pipermail/attachments/20081031/c24bc840/attachment.pgp>

From kpfleming at digium.com  Fri Oct 31 16:29:04 2008
From: kpfleming at digium.com (Kevin P. Fleming)
Date: Fri, 31 Oct 2008 10:29:04 -0500
Subject: [Help-gnutls] Key usage violation in certificate
In-Reply-To: <87od11ham6.fsf@squeak.fifthhorseman.net>
References: <490A37DA.6090400@digium.com>
	<87od11ham6.fsf@squeak.fifthhorseman.net>
Message-ID: <490B2440.4070105@digium.com>

Daniel Kahn Gillmor wrote:

> I can't seem to connect to your server with either openssl or gnutls,
> actually.  Can you?  
> 
> [0 dkg at squeak ~]$ openssl s_client -showcerts -verify 5 -connect origsvn.digium.com:443
> verify depth is 5
> CONNECTED(00000003)
> depth=1 /C=US/ST=Alabama/L=Huntsville/O=Digium, Inc./OU=Asterisk Development Team/CN=Digium SVN CA/emailAddress=asteriskteam at digium.com
> verify error:num=19:self signed certificate in certificate chain
> verify return:1
> depth=1 /C=US/ST=Alabama/L=Huntsville/O=Digium, Inc./OU=Asterisk Development Team/CN=Digium SVN CA/emailAddress=asteriskteam at digium.com
> verify return:1
> depth=0 /C=US/ST=Alabama/L=Huntsville/O=Digium/OU=Asterisk Development Team/CN=origsvn.digium.com/emailAddress=asteriskteam at digium.com
> verify return:1
> 28424:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1053:SSL alert number 40
> 28424:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
> [0 dkg at squeak ~]$ gnutls-cli --verbose  origsvn.digium.com --port 443
> Resolving 'origsvn.digium.com'...
> Connecting to '216.207.245.42:443'...
> - Server's trusted authorities:
>    [0]: C=US,ST=Alabama,L=Huntsville,O=Digium\, Inc.,OU=Asterisk Development Team,CN=Digium SVN CA,EMAIL=asteriskteam at digium.com
> - Successfully sent 0 certificate(s) to server.
> *** Fatal error: A TLS fatal alert has been received.
> *** Received alert [40]: Handshake failed
> *** Handshake has failed
> GNUTLS ERROR: A TLS fatal alert has been received.
> [1 dkg at squeak ~]$ 

OK, I've attached (hopefully it will make it through the list) a client
cert that will allow TLS negotiation to complete on
https://origsvn.digium.com (although the resulting connection won't be
authorized to do anything).

If the GNUTLS experts can try connecting with this as the client cert
and inform me why GNUTLS reports a key usage violation on the server
cert that would be awesome :-)


-- 
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutlstest-cert.p12
Type: application/octet-stream
Size: 5853 bytes
Desc: not available
URL: </pipermail/attachments/20081031/f53a5f4c/attachment.obj>

From mike at reys.be  Fri Oct 31 16:30:28 2008
From: mike at reys.be (mike at reys.be)
Date: Fri, 31 Oct 2008 16:30:28 +0100 (CET)
Subject: [Help-gnutls] Not at home
Message-ID: <20081031153028.11E4638E0A1F0@zulu.openminds.be>

Hi,

thanks for your mail, I'm travelling and reading my mail will not
always be possible. I'll get back to you as soon as possible.

Cheers,

Mike