From addarathbone at googlemail.com Thu Apr 8 12:32:24 2010 From: addarathbone at googlemail.com (Adda Rathbone) Date: Thu, 8 Apr 2010 12:32:24 +0200 Subject: Bug: Use of srp with gnutlsxx Message-ID: <20100408103224.GA19101@debbie> Hello, if you compile version 2.8.5 or 2.8.6 and try to use gnutls::srp_server_credentials or gnutls::srp_client_credentials the compiler will complain about the constructor and destructor of the srp class Fix is descriped here: http://markmail.org/message/vu3da76lrlz6icvl For people who don't follow links in an email: diff -u a/lib/gnutlsxx.cpp b/lib/gnutlsxx.cpp --- a/lib/gnutlsxx.cpp 2010-04-08 12:22:37.000000000 +0200 +++ b/lib/gnutlsxx.cpp 2010-04-08 00:27:08.000000000 +0200 @@ -1,3 +1,7 @@ +#ifdef HAVE_CONFIG_H +#include +#endif + #include namespace gnutls diff -u a/lib/libgnutlsxx.map b/lib/libgnutlsxx.map --- a/lib/libgnutlsxx.map 2010-04-08 12:22:28.000000000 +0200 +++ b/lib/libgnutlsxx.map 2010-04-08 00:29:18.000000000 +0200 @@ -24,7 +24,9 @@ { global: extern "C++" { - gnutls*; + gnutls::*; }; + # export typeinfo names and structures + _ZTI*; local: *; }; Adda From gonzagueddr at yahoo.fr Tue Apr 13 19:18:40 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Tue, 13 Apr 2010 19:18:40 +0200 Subject: nOOb Error : No certificates found! Message-ID: <4BC4A770.503@yahoo.fr> Hi all, and first excuse me to be totaly noob about gnutls. It's one week i'm trying to stream an mp3 over https using vlc, and i get the error "TLS handshake error: The peer did not send any certificate". So after a week on the vlc forum, i thing you're my only hope now (they say it's a gnutls' bug, but i can't believe that). Trying to understand how to test gnutls, i ran "gnutls-serv -p 22222 -d 1 --x509certfile /path/servercert.pem --x509keyfile /path/serverkey.pem --x509cafile /path/cacert.pem" and then on another box "gnutls-cli -d 1 -p 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem domain.org" and get from the client : Processed 1 CA certificate(s). Resolving 'domain.org'... Connecting to 'xxx.xxx.xxx.xxx:22222'... - Successfully sent 0 certificate(s) to server. - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'domain.org'. # valid since: Wed Apr 7 18:39:46 CEST 2010 # expires at: Thu Apr 7 18:39:46 CEST 2011 # fingerprint: 37:12:84:F2:E2:0C:A6:DC:4C:93:B1:18:57:8E:8A:0C # Subject's DN: O=domain.org,CN=domain.org # Issuer's DN: CN=domain.org - Peer's certificate is trusted - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: So everything looks ok, am i wrong ? But from the server i got: Set static Diffie-Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). HTTP Server listening on 0.0.0.0 port 22222 family 2...done HTTP Server listening on :: port 22222 family 10...done * connection from xx.xx.xx.xxx, port 50091 - Given server name[1]: domain.org - Certificate type: X.509 No certificates found! - Could not verify certificate (err: The peer did not send any certificate.) - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL I can not find help about this on the web, i mean something that i can understand ... If someone know what can i do for this, it would be very apreciate. Thanks for your time, and for moreover for those great tools . Gonzague From nmav at gnutls.org Tue Apr 13 19:57:43 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Apr 2010 19:57:43 +0200 Subject: Bug: Use of srp with gnutlsxx In-Reply-To: <20100408103224.GA19101@debbie> References: <20100408103224.GA19101@debbie> Message-ID: <4BC4B097.5030107@gnutls.org> Adda Rathbone wrote: > Hello, > if you compile version 2.8.5 or 2.8.6 and try to use > gnutls::srp_server_credentials or gnutls::srp_client_credentials > the compiler will complain about the constructor and > destructor of the srp class > > Fix is descriped here: http://markmail.org/message/vu3da76lrlz6icvl > > For people who don't follow links in an email: Hi, Thanks. I see that a similar patch is applied on 2.9.x. Does 2.9.x works for you? regards, Nikos From nmav at gnutls.org Tue Apr 13 20:03:10 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 13 Apr 2010 20:03:10 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <4BC4A770.503@yahoo.fr> References: <4BC4A770.503@yahoo.fr> Message-ID: <4BC4B1DE.9090202@gnutls.org> gonzagueddr wrote: > Hi all, and first excuse me to be totaly noob about gnutls. > It's one week i'm trying to stream an mp3 over https using vlc, and i > get the error "TLS handshake error: The peer did not send any certificate". > So after a week on the vlc forum, i thing you're my only hope now (they > say it's a gnutls' bug, but i can't believe that). Please be more precise. What is your scenario, who is the tls server and who is the client. [...] > * connection from xx.xx.xx.xxx, port 50091 > - Given server name[1]: domain.org > - Certificate type: X.509 > No certificates found! > - Could not verify certificate (err: The peer did not send any > certificate.) > - Version: TLS1.1 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > > I can not find help about this on the web, i mean something that i can > understand ... > If someone know what can i do for this, it would be very apreciate. The peer did not send any certificate is normal. A TLS client is not obliged to send a certificate and in your case didn't. That's why the server cannot verify it. If you want the client to send a certificate you have to specify a certificate and a key, that are suitable for signing. regards, Nikos From gonzagueddr at yahoo.fr Wed Apr 14 09:15:14 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Wed, 14 Apr 2010 09:15:14 +0200 Subject: nOOb Error : No certificates found! Message-ID: <4BC56B82.1000709@yahoo.fr> Hi, the server (gnutls 2.8.6) is running on a debian sid distrib (domain.org ), in my home, and the client (2.4.2 ) is on a debian lenny in my office, both commands were ran over ssh. I also tried to run serv and cli on the same machine, for the same result ... I used certtool to make the .pem : certtool --generate-privkey > cakey.pem certtool --generate-self-signed --load-privkey cakey.pem --template ca.info --outfile cacert.pem certtool --generate-privkey > serverkey.pem certtool --generate-certificate --load-privkey serverkey.pem --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem --template server.info --outfile servercert.pem Here is my ca.info : cn = domain.org ca cert_signing_key and the server.info : organization = domain.org cn = domain.org tls_www_server encryption_key signing_key Looking the log whith the "-d 9" option, i notice a packet's length trouble, but don't know what it's mean. Here is the full log for the server : Processed 1 CA certificate(s). Echo Server listening on 0.0.0.0 port 22222 family 2...done Echo Server listening on :: port 22222 family 10...done |<4>| REC[0x9369438]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9369438]: Received Packet[0] Handshake(22) with length: 134 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Decrypted Packet[0] Handshake(22) with length: 134 |<3>| HSK[0x9369438]: CLIENT HELLO was received [134 bytes] |<3>| HSK[0x9369438]: Client's version: 3.2 |<2>| ASSERT: gnutls_db.c:326 |<2>| ASSERT: gnutls_db.c:246 |<2>| EXT[0x9369438]: Received extension 'CERT_TYPE/9' |<2>| EXT[0x9369438]: Received extension 'SERVER_NAME/0' |<2>| EXT[0x9369438]: Received extension 'CERT_TYPE/9' |<2>| EXT[0x9369438]: Received extension 'SERVER_NAME/0' |<2>| ASSERT: gnutls_x509.c:948 |<2>| ASSERT: gnutls_x509.c:948 |<2>| ASSERT: gnutls_x509.c:948 |<3>| HSK[0x9369438]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9369438]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x9369438]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x9369438]: Selected cipher suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Selected Compression Method: NULL |<3>| HSK[0x9369438]: SessionID: 224e3445cff4013fe0549f2154eacb8489f7ccc2210c634c6358e61868d1b594 |<3>| HSK[0x9369438]: SERVER HELLO was send [74 bytes] |<4>| REC[0x9369438]: Sending Packet[0] Handshake(22) with length: 74 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Sent Packet[1] Handshake(22) with length: 79 |<3>| HSK[0x9369438]: CERTIFICATE was send [859 bytes] |<4>| REC[0x9369438]: Sending Packet[1] Handshake(22) with length: 859 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Sent Packet[2] Handshake(22) with length: 864 |<3>| HSK[0x9369438]: CERTIFICATE REQUEST was send [45 bytes] |<4>| REC[0x9369438]: Sending Packet[2] Handshake(22) with length: 45 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Sent Packet[3] Handshake(22) with length: 50 |<3>| HSK[0x9369438]: SERVER HELLO DONE was send [4 bytes] |<4>| REC[0x9369438]: Sending Packet[3] Handshake(22) with length: 4 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Sent Packet[4] Handshake(22) with length: 9 |<2>| ASSERT: gnutls_buffers.c:322 |<2>| ASSERT: gnutls_buffers.c:1032 |<2>| ASSERT: gnutls_handshake.c:1045 |<4>| REC[0x9369438]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[0x9369438]: Received Packet[1] Handshake(22) with length: 7 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Decrypted Packet[1] Handshake(22) with length: 7 |<3>| HSK[0x9369438]: CERTIFICATE was received [7 bytes] |<2>| ASSERT: auth_cert.c:965 |<2>| ASSERT: gnutls_buffers.c:322 |<2>| ASSERT: gnutls_buffers.c:1032 |<2>| ASSERT: gnutls_handshake.c:1045 |<4>| REC[0x9369438]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[0x9369438]: Received Packet[2] Handshake(22) with length: 262 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Decrypted Packet[2] Handshake(22) with length: 262 |<3>| HSK[0x9369438]: CLIENT KEY EXCHANGE was received [262 bytes] |<4>| REC[0x9369438]: Expected Packet[3] Change Cipher Spec(20) with length: 1 |<4>| REC[0x9369438]: Received Packet[3] Change Cipher Spec(20) with length: 1 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: ChangeCipherSpec Packet was received |<9>| INT: PREMASTER SECRET[48]: 03020cec5416555698ddbc9d1c55b56e14bf071a99a17bdf554667d3b29073fc8d2906579db9c576f6fca3d4162e1724 |<9>| INT: CLIENT RANDOM[32]: 4bc55be32cd9c4da765c8ab4eddfc32249f0653a1a6166b0da65b45a104c8c55 |<9>| INT: SERVER RANDOM[32]: 4bc561a58e7da6b709e08d01fba0bb072897a19560083b65db8d7b6a26be3fe8 |<9>| INT: MASTER SECRET: 0ba4d5e3a7f793db36218a273f07731bbd9dd13616d53492e6219c5be07d84cf4b7cc6e48d31b88bf1610d8160a53265 |<9>| INT: KEY BLOCK[104]: bf90261ed2912882a4aa9af453bb9fe60ad65814338a22071e8f6cf67d652740 |<9>| INT: CLIENT WRITE KEY [16]: e60ce295037d521507710b409a90ab2f |<9>| INT: SERVER WRITE KEY [16]: a2d6d70f11df6e0fcd5c534f906b5bbf |<3>| HSK[0x9369438]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Initializing internal [read] cipher sessions |<4>| REC[0x9369438]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[0x9369438]: Received Packet[0] Handshake(22) with length: 176 |<4>| REC[0x9369438]: Decrypted Packet[0] Handshake(22) with length: 16 |<3>| HSK[0x9369438]: FINISHED was received [16 bytes] |<3>| REC[0x9369438]: Sent ChangeCipherSpec |<4>| REC[0x9369438]: Sending Packet[4] Change Cipher Spec(20) with length: 1 |<2>| ASSERT: gnutls_cipher.c:204 |<4>| REC[0x9369438]: Sent Packet[5] Change Cipher Spec(20) with length: 6 |<3>| HSK[0x9369438]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x9369438]: Initializing internal [write] cipher sessions |<3>| HSK[0x9369438]: FINISHED was send [16 bytes] |<4>| REC[0x9369438]: Sending Packet[0] Handshake(22) with length: 16 |<4>| REC[0x9369438]: Sent Packet[1] Handshake(22) with length: 149 * connection from xxx.xx.xxx.xx, port 38662 - Given server name[1]: domain.org - Certificate type: X.509 No certificates found! - Could not verify certificate (err: The peer did not send any certificate.) - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL |<2>| ASSERT: gnutls_buffers.c:322 And the full log of the client : Processed 1 CA certificate(s). Resolving 'domain.org'... Connecting to 'xx.xxx.xxx.xx:22222'... |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[80752d8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[80752d8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[80752d8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<2>| EXT[80752d8]: Sending extension CERT_TYPE |<2>| EXT[80752d8]: Sending extension SERVER_NAME |<3>| HSK[80752d8]: CLIENT HELLO was send [134 bytes] |<4>| REC[80752d8]: Sending Packet[0] Handshake(22) with length: 134 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Sent Packet[1] Handshake(22) with length: 139 |<4>| REC[80752d8]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[80752d8]: Received Packet[0] Handshake(22) with length: 74 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Decrypted Packet[0] Handshake(22) with length: 74 |<3>| HSK[80752d8]: SERVER HELLO was received [74 bytes] |<3>| HSK[80752d8]: Server's version: 3.2 |<3>| HSK[80752d8]: SessionID length: 32 |<3>| HSK[80752d8]: SessionID: 224e3445cff4013fe0549f2154eacb8489f7ccc2210c634c6358e61868d1b594 |<3>| HSK[80752d8]: Selected cipher suite: RSA_AES_128_CBC_SHA1 |<2>| ASSERT: gnutls_extensions.c:165 |<4>| REC[80752d8]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[80752d8]: Received Packet[1] Handshake(22) with length: 859 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Decrypted Packet[1] Handshake(22) with length: 859 |<3>| HSK[80752d8]: CERTIFICATE was received [859 bytes] |<4>| REC[80752d8]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[80752d8]: Received Packet[2] Handshake(22) with length: 45 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Decrypted Packet[2] Handshake(22) with length: 45 |<3>| HSK[80752d8]: CERTIFICATE REQUEST was received [45 bytes] - Successfully sent 0 certificate(s) to server. |<4>| REC[80752d8]: Expected Packet[3] Handshake(22) with length: 1 |<4>| REC[80752d8]: Received Packet[3] Handshake(22) with length: 4 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Decrypted Packet[3] Handshake(22) with length: 4 |<3>| HSK[80752d8]: SERVER HELLO DONE was received [4 bytes] |<3>| HSK[80752d8]: CERTIFICATE was send [7 bytes] |<4>| REC[80752d8]: Sending Packet[1] Handshake(22) with length: 7 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Sent Packet[2] Handshake(22) with length: 12 |<3>| HSK[80752d8]: CLIENT KEY EXCHANGE was send [262 bytes] |<4>| REC[80752d8]: Sending Packet[2] Handshake(22) with length: 262 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Sent Packet[3] Handshake(22) with length: 267 |<3>| REC[80752d8]: Sent ChangeCipherSpec |<4>| REC[80752d8]: Sending Packet[3] Change Cipher Spec(20) with length: 1 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: Sent Packet[4] Change Cipher Spec(20) with length: 6 |<9>| INT: PREMASTER SECRET[48]: 03020cec5416555698ddbc9d1c55b56e14bf071a99a17bdf554667d3b29073fc8d2906579db9c576f6fca3d4162e1724 |<9>| INT: CLIENT RANDOM[32]: 4bc55be32cd9c4da765c8ab4eddfc32249f0653a1a6166b0da65b45a104c8c55 |<9>| INT: SERVER RANDOM[32]: 4bc561a58e7da6b709e08d01fba0bb072897a19560083b65db8d7b6a26be3fe8 |<9>| INT: MASTER SECRET: 0ba4d5e3a7f793db36218a273f07731bbd9dd13616d53492e6219c5be07d84cf4b7cc6e48d31b88bf1610d8160a53265 |<9>| INT: KEY BLOCK[104]: bf90261ed2912882a4aa9af453bb9fe60ad65814338a22071e8f6cf67d652740 |<9>| INT: CLIENT WRITE KEY [16]: e60ce295037d521507710b409a90ab2f |<9>| INT: SERVER WRITE KEY [16]: a2d6d70f11df6e0fcd5c534f906b5bbf |<3>| HSK[80752d8]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Initializing internal [write] cipher sessions |<3>| HSK[80752d8]: FINISHED was send [16 bytes] |<4>| REC[80752d8]: Sending Packet[0] Handshake(22) with length: 16 |<4>| REC[80752d8]: Sent Packet[1] Handshake(22) with length: 181 |<4>| REC[80752d8]: Expected Packet[4] Change Cipher Spec(20) with length: 1 |<4>| REC[80752d8]: Received Packet[4] Change Cipher Spec(20) with length: 1 |<2>| ASSERT: gnutls_cipher.c:205 |<4>| REC[80752d8]: ChangeCipherSpec Packet was received |<3>| HSK[80752d8]: Cipher Suite: RSA_AES_128_CBC_SHA1 |<3>| HSK[80752d8]: Initializing internal [read] cipher sessions |<4>| REC[80752d8]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[80752d8]: Received Packet[0] Handshake(22) with length: 144 |<4>| REC[80752d8]: Decrypted Packet[0] Handshake(22) with length: 16 |<3>| HSK[80752d8]: FINISHED was received [16 bytes] |<2>| ASSERT: ext_server_name.c:257 - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: # The hostname in the certificate matches 'domain.org'. # valid since: Wed Apr 7 18:39:46 CEST 2010 # expires at: Thu Apr 7 18:39:46 CEST 2011 # fingerprint: 37:12:84:F2:E2:0C:A6:DC:4C:93:B1:18:57:8E:8A:0C # Subject's DN: O=domain.org,CN=domain.org # Issuer's DN: CN=domain.org |<2>| ASSERT: mpi.c:587 |<2>| ASSERT: dn.c:1212 - Peer's certificate is trusted - Version: TLS1.1 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL |<2>| ASSERT: mpi.c:587 |<2>| ASSERT: dn.c:1212 - Handshake was completed - Simple Client Mode: Sorry to hide the name and ip, but i don't want this server to be known, of course if you need it, i'll give it. Moreover, i'm not sure if the full logs was what you mean by "more precise" ... Thanks, Gonzague Nikos Mavrogiannopoulos a ?crit : > gonzagueddr wrote: > > >> Hi all, and first excuse me to be totaly noob about gnutls. >> It's one week i'm trying to stream an mp3 over https using vlc, and i >> get the error "TLS handshake error: The peer did not send any >> certificate". >> So after a week on the vlc forum, i thing you're my only hope now (they >> say it's a gnutls' bug, but i can't believe that). >> > > Please be more precise. What is your scenario, who is the tls server and > who is the client. > > [...] > >> * connection from xx.xx.xx.xxx, port 50091 >> - Given server name[1]: domain.org >> - Certificate type: X.509 >> No certificates found! >> - Could not verify certificate (err: The peer did not send any >> certificate.) >> - Version: TLS1.1 >> - Key Exchange: RSA >> - Cipher: AES-128-CBC >> - MAC: SHA1 >> - Compression: NULL >> >> I can not find help about this on the web, i mean something that i can >> understand ... >> If someone know what can i do for this, it would be very apreciate. >> > > The peer did not send any certificate is normal. A TLS client is not > obliged to send a certificate and in your case didn't. That's why > the server cannot verify it. If you want the client to send a > certificate you have to specify a certificate and a key, that are > suitable for signing. > > > regards, > Nikos From gonzagueddr at yahoo.fr Wed Apr 14 11:51:01 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Wed, 14 Apr 2010 11:51:01 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: References: <4BC4A770.503@yahoo.fr> Message-ID: <4BC59005.3000702@yahoo.fr> I've tried "gnutls-cli -d 1 -p 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem --x509keyfile /path/serverkey.pem domain.org " and the client returns : *** Fatal error: Key usage violation in certificate has been detected. *** Handshake has failed GNUTLS ERROR: Key usage violation in certificate has been detected. I've also tried with clientcert.pem and clientkey.pem, acording to an example i found on the web ( http://libvirt.org/remote.html ), because i understood that the cert and key can/must be different on the server and client, but i get the same error. Regards Gonzague Nikos Mavrogiannopoulos a ?crit : > On Tue, Apr 13, 2010 at 7:18 PM, gonzagueddr wrote: > > >> "gnutls-cli -d 1 -p >> 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem >> > > The issue is here. You must also specify the --x509keyfile parameter. > Otherwise the > x509certfile parameter is being ignored. > > regards, > Nikos From lfinsto at gwdg.de Wed Apr 14 12:17:26 2010 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Wed, 14 Apr 2010 12:17:26 +0200 (CEST) Subject: nOOb Error : No certificates found! In-Reply-To: <4BC59005.3000702@yahoo.fr> References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> Message-ID: <43081.134.76.5.25.1271240246.squirrel@mailbox.gwdg.de> Is your private key encrypted? This may be the problem. At any rate, it was a problem I ran into when I was trying to get my server-client pair working. I don't recall all of the details I learned at the time, so I apologize if this suggestion is wrong or of no use. However, if this is the problem, you'll have to generate an unencrypted key. This is how I generated an unencrypted key from a p12 file using openssl. I'd have to look up whether it's possible to do it with a command from the GNUTLS package and if so, how: openssl pkcs12 -nodes -nocerts -in usercred.p12 -out userkey.pem I would expect that it would be possible to generate an unencrypted key from an encrypted one. Laurence Finston On Wed, April 14, 2010 11:51 am, gonzagueddr wrote: > I've tried "gnutls-cli -d 1 -p 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem --x509keyfile /path/serverkey.pem domain.org > " > > and the client returns : > > *** Fatal error: Key usage violation in certificate has been detected. *** Handshake has failed > GNUTLS ERROR: Key usage violation in certificate has been detected. > > I've also tried with clientcert.pem and clientkey.pem, acording to an example i found on the web ( http://libvirt.org/remote.html ), because i understood that the cert and key can/must be different on the server and client, but i get the same error. > > > Regards > Gonzague > > > > > Nikos Mavrogiannopoulos a ?crit : >> On Tue, Apr 13, 2010 at 7:18 PM, gonzagueddr wrote: >>> "gnutls-cli -d 1 -p >>> 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem >> The issue is here. You must also specify the --x509keyfile parameter. Otherwise the >> x509certfile parameter is being ignored. >> regards, >> Nikos > > > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > ------------------------------------------------------------- Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From nmav at gnutls.org Wed Apr 14 12:22:14 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Apr 2010 12:22:14 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <4BC59005.3000702@yahoo.fr> References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> Message-ID: On Wed, Apr 14, 2010 at 11:51 AM, gonzagueddr wrote: > I've tried "gnutls-cli -d 1 -p 22222 --x509certfile /path/servercert.pem > --x509cafile /path/cacert.pem --x509keyfile /path/serverkey.pem domain.org " > > and the client returns : > > *** Fatal error: Key usage violation in certificate has been detected. > *** Handshake has failed > GNUTLS ERROR: Key usage violation in certificate has been detected. In the creation of the server keys you specifically asked for a tls www server, thus it is normal for gnutls to detect a violation. However I believe something is missing here. What do you actually want to do? (not what you did, but what you want to do). If you simply want to stream an mp3 over https you don't really need a client certificate. Given that, what is the actual error you see? regards, Nikos From nmav at gnutls.org Wed Apr 14 09:28:53 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Apr 2010 09:28:53 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <4BC4A770.503@yahoo.fr> References: <4BC4A770.503@yahoo.fr> Message-ID: On Tue, Apr 13, 2010 at 7:18 PM, gonzagueddr wrote: > "gnutls-cli -d 1 -p > 22222 --x509certfile /path/servercert.pem --x509cafile /path/cacert.pem The issue is here. You must also specify the --x509keyfile parameter. Otherwise the x509certfile parameter is being ignored. regards, Nikos From gonzagueddr at yahoo.fr Wed Apr 14 14:05:38 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Wed, 14 Apr 2010 14:05:38 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> Message-ID: <4BC5AF92.1090003@yahoo.fr> > In the creation of the server keys you specifically asked for a tls > www server, thus it is normal for gnutls to detect a violation. Yes, but i also tried "gnutls-serv --http", so it supose to act as an http server isn't it ?, and using a netbrowser to get https://domain.org:22222/ returns the same error from the server ("No certificates found!") > What do you actually want to do? (not what you did, but what you > want to do). > If you simply want to stream an mp3 over https you don't really need a > client certificate. > Given that, what is the actual error you see? > That's it : stream an mp3 over https using vlc , so the vlc server's command is "vlc --sout-http-cert="/path/servercert.pem" --sout-http-key="/path/serverkey.pem" --sout-http-ca="/path/cacert.pem --sout '#standard{access=https,mux=ts,dst=192.168.1.15:22222/test.mp3}' my.mp3" ( vlc server must be run with the ca, cert and key files, or it returns fatal error (cannot set certificate chain or private key)) And when i open the stream, vlc server returns "TLS handshake error: The peer did not send any certificate", while the client returns "TLS handshake error: Error in the push function". I've been said on the vlc's forum that the CA file must be present on the client's machine, so i've copy/paste the cacert.pem to ca-certificates.crt (if this file is not present, client returns a warning (can not add credidential x509 ), and then the same TLS handshake error If i run the vlc server without the "--sout-http-ca", client returns : gnutls error: TLS session: access denied gnutls error: Certificate could not be verified gnutls error: Certificate's signer was not found main error: TLS client session handshake error So specifying those 3 files (ca, cert and key) on the server and the ca on the client gave me the less errors ... Sorry for this, and thanks again for your time. Gonzague From gonzagueddr at yahoo.fr Wed Apr 14 14:20:55 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Wed, 14 Apr 2010 14:20:55 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <43081.134.76.5.25.1271240246.squirrel@mailbox.gwdg.de> References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> <43081.134.76.5.25.1271240246.squirrel@mailbox.gwdg.de> Message-ID: <4BC5B327.2010901@yahoo.fr> I've converted my key into a .p12, then ran your command. Result is strictly the same ... lfinsto at gwdg.de a ?crit : > Is your private key encrypted? This may be the problem. At any rate, it > was a problem I ran into when I was trying to get my server-client pair > working. I don't recall all of the details I learned at the time, so I > apologize if this suggestion is wrong or of no use. > > However, if this is the problem, you'll have to generate an unencrypted > key. This is how I generated an unencrypted key from a p12 file using > openssl. I'd have to look up whether it's possible to do it with a > command from the GNUTLS package and if so, how: > > openssl pkcs12 -nodes -nocerts -in usercred.p12 -out userkey.pem > > I would expect that it would be possible to generate an unencrypted key > from an encrypted one. > > Laurence Finston > From nmav at gnutls.org Wed Apr 14 14:39:27 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 Apr 2010 14:39:27 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <4BC5AF92.1090003@yahoo.fr> References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> <4BC5AF92.1090003@yahoo.fr> Message-ID: On Wed, Apr 14, 2010 at 2:05 PM, gonzagueddr wrote: > >> In the creation of the server keys you specifically asked for a tls >> www server, thus it is normal for gnutls to detect a violation. > > Yes, but i also tried "gnutls-serv --http", so it supose to act as an http > server isn't it ?, and using a netbrowser to get https://domain.org:22222/ > returns the same error from the server ("No certificates found!") Yes the --http runs a test https server. However the error you mention is a non fatal error. The TLS handshake completes and you can view the page. It is legal for a client to not send any certificate to the server. > That's it : stream an mp3 over https using vlc , so the vlc server's command > is "vlc --sout-http-cert="/path/servercert.pem" > --sout-http-key="/path/serverkey.pem" --sout-http-ca="/path/cacert.pem > --sout '#standard{access=https,mux=ts,dst=192.168.1.15:22222/test.mp3}' > my.mp3" ( vlc server must be run with the ca, cert and key files, or it > returns fatal error (cannot set certificate chain or private key)) > And when i open the stream, vlc server returns ?"TLS handshake error: The > peer did not send any certificate", while the client returns "TLS handshake > error: Error in the push function". > I've been said on the vlc's forum that the CA file must be present on the > client's machine, so i've copy/paste the cacert.pem to ca-certificates.crt > (if this file is not present, client returns a warning (can not add > credidential x509 ), and then the same TLS handshake error > > If i run the vlc server without the "--sout-http-ca", client returns : > > gnutls error: TLS session: access denied > gnutls error: Certificate could not be verified > gnutls error: Certificate's signer was not found > main error: TLS client session handshake error Here the client cannot verify the server's certificate. You have to tell how he's going to find it. In http://mailman.videolan.org/pipermail/vlc/2006-January/012777.html they mention .vlc/ssl/certs directory as a place to put the CA certifcate. > So specifying those 3 files (ca, cert and key) on the server and the ca on > the client gave me the less errors ... Most probably specifying the http-ca option forces the sever to require for a certifcate. You might get more information at a vlc related list though. Your issue has mostly to do with how vlc uses gnutls that I don't really know much of. regards, Nikos From gonzagueddr at yahoo.fr Wed Apr 14 16:09:12 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Wed, 14 Apr 2010 16:09:12 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> <4BC5AF92.1090003@yahoo.fr> Message-ID: <4BC5CC88.5010105@yahoo.fr> I think you're wright, i'll tri, but i'm on this list because i can not get help from the vlc list ... Thank you for everything Kind regards Gonzague > Most probably specifying the http-ca option forces the sever to require > for a certifcate. You might get more information at a vlc related list > though. Your issue has mostly to do with how vlc uses gnutls that I > don't really know much of. > > regards, > Nikos From gonzagueddr at yahoo.fr Fri Apr 16 20:21:14 2010 From: gonzagueddr at yahoo.fr (gonzagueddr) Date: Fri, 16 Apr 2010 20:21:14 +0200 Subject: nOOb Error : No certificates found! In-Reply-To: <4BC5CC88.5010105@yahoo.fr> References: <4BC4A770.503@yahoo.fr> <4BC59005.3000702@yahoo.fr> <4BC5AF92.1090003@yahoo.fr> <4BC5CC88.5010105@yahoo.fr> Message-ID: <4BC8AA9A.6030304@yahoo.fr> You were totaly right : if i don't specifie the ca on the server, the session is correctly opened. No problem ... Thanks again Nikos, and thank to gnutls' team gonzagueddr a ?crit : > I think you're wright, i'll tri, but i'm on this list because i can > not get help from the vlc list ... > Thank you for everything > > Kind regards > > Gonzague >> Most probably specifying the http-ca option forces the sever to require >> for a certifcate. You might get more information at a vlc related list >> though. Your issue has mostly to do with how vlc uses gnutls that I >> don't really know much of. >> >> regards, >> Nikos > > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > ------------------------------------------------------------------------ > > > Ce message entrant est certifi? sans virus connu. > Analyse effectu?e par AVG - www.avg.fr > Version: 9.0.801 / Base de donn?es virale: 271.1.1/2809 - Date: 04/13/10 22:22:00 > > From simon at josefsson.org Tue Apr 20 08:51:07 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 20 Apr 2010 08:51:07 +0200 Subject: GNU Libtasn1 2.6 Message-ID: <87zl0yliqs.fsf@mocca.josefsson.org> GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. NOTE! Future release announcements will not be cross-posted to help-gnutls, gnutls-devel or help-shishi. Please subscribe to info-gnu or join our new mailing list help-libtasn1: http://lists.gnu.org/mailman/listinfo/info-gnu http://lists.gnu.org/mailman/listinfo/help-libtasn1 * Noteworthy changes in release 2.6 (2010-04-20) [stable] - Fix build failure on platforms without support for GNU LD version scripts. - libtasn1: Simplified implementation of asn1_check_version. - tests: Improved self-checks. - Update gnulib files, fix many syntax-check nits, indent code, fix license templates. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.7MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.6.tar.gz.sig A ZIP archive containing the Windows binaries (268KB): http://josefsson.org/gnutls4win/libtasn1-2.6.zip http://josefsson.org/gnutls4win/libtasn1-2.6.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.6-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-libtasn1 mailing list, see: http://lists.gnu.org/mailman/listinfo/help-libtasn1 All manuals are available from: http://www.gnu.org/software/libtasn1/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/libtasn1/manual/libtasn1.html PDF: http://www.gnu.org/software/libtasn1/manual/libtasn1.pdf API Reference manual: http://www.gnu.org/software/libtasn1/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/libtasn1/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/libtasn1/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: dd02f3c8aaa0a1500d65c1e4ae690b76085f621e libtasn1-2.6.tar.gz ba6d50d1e7340f8d1ce07880381afd990ea700c6c4c1cacdba0c2ffd libtasn1-2.6.tar.gz a53c27e245c31be7bdf340dc7ec89cafb758c715 libtasn1-2.6.zip ecbdb08988c28041b98a2373b43fda47cc459d4116719f96cf8f3e76 libtasn1-2.6.zip db5400688eff7c36c3f0baa57f13afda842d665b mingw32-libtasn1_2.6-1_all.deb 7a446b8404e715abb2ec1a24dbe38d3a54169537ad4172ddbf62afdb mingw32-libtasn1_2.6-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From ali.khalfan at gmail.com Tue Apr 20 17:06:30 2010 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Tue, 20 Apr 2010 11:06:30 -0400 Subject: trying to find the cipher functions Message-ID: <4BCDC2F6.7060005@gmail.com> Hi, I'm trying to locate the cipher functions (spefically, AES, and ARCFour) since I want to run them by themselves (I'm trying to run the same cipher functions from different SSL libraries) so I found the following const: GNUTLS_CIPHER_AES_256_CBC, which from the documentation I'm assuming will be used in the record layer, to be called by _gnutls_encrypt, yet, I can't seem to find a function that handles the AES encryption (or ARCFour), Is there something I'm missing here about gnutls's architecture? It doesn't seem to be logical that there would be one generic function that would take care of all the different algorithm types, and I don't believe that gnutls is relying on openssl From dkg at fifthhorseman.net Tue Apr 20 19:00:38 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Apr 2010 13:00:38 -0400 Subject: trying to find the cipher functions In-Reply-To: <4BCDC2F6.7060005@gmail.com> References: <4BCDC2F6.7060005@gmail.com> Message-ID: <4BCDDDB6.5080508@fifthhorseman.net> On 04/20/2010 11:06 AM, Ali Khalfan wrote: > Is there something I'm missing here about gnutls's architecture? It > doesn't seem to be logical that there would be one generic function that > would take care of all the different algorithm types, and I don't > believe that gnutls is relying on openssl GnuTLS relies on gcrypt for its low-level crypto-primitives. There has als been some discussion in the recent past about making gnutls flexible enough to use an alternate low-level library (such as nettle), but i don't think that's in place at the moment. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From carolin.latze at unifr.ch Fri Apr 23 15:11:16 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Fri, 23 Apr 2010 15:11:16 +0200 Subject: My own TLS Extension - Hello World :-) Message-ID: <4BD19C74.3080000@unifr.ch> Hi everybody, I tried to write my own TLS extension and ran into problems when trying to define an API for that extension. But let me explain step-by-step: I use gnutls 2.9.11 and followed http://www.gnu.org/software/gnutls/devel/manual/gnutls.html#TLS-Extension-Handling to add an extension that sends a fix HelloWorld message from client to server and vice versa and prints it (using printf). In order to do so, I modified and added the following files: lib/m4/hooks.m4 lib/gnutls_int.h lib/gnutls_extensions.c lib/ext_helloworld.{h|c} lib/Makefile.am That worked pretty well. My very simple client and server application (they do a standard handshake) print out the HelloWorld as expected. Now, I wanted to add an API to be able to specify the HelloWorld message within the client and server application. In order to do so, I added the following line to lib/includes/gnutls/gnutls.h: int gnutls_helloworld_set_msg(gnutls_session_t session, const char *msg); The function itself is defined in lib/gnutls_helloworld.c. Furthermore I added gnutls_helloworld.c to lib/Makefile.am. Running make and make install does not show any problems but when I try to call gnutls_helloworld_set_msg in my client application, I run into linker problems: undefined reference to `gnutls_helloworld_set_msg' However when I run nm with my GnuTLS library, gnutls_helloworld_set_msg is listed. Does anybody have an idea whats going wrong here? I assume I missed on modification that is needed to export API methods, but I have no idea where.... Any help would be appreciated. Carolin From nmav at gnutls.org Fri Apr 23 15:32:10 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Apr 2010 15:32:10 +0200 Subject: My own TLS Extension - Hello World :-) In-Reply-To: <4BD19C74.3080000@unifr.ch> References: <4BD19C74.3080000@unifr.ch> Message-ID: Hello, We hide all functions by default unless they are exported (in the gnu linker at least). If I remember well it is the libgnutls.map file that you need to change. Just from curiosity, which extension are you trying to add? btw. I plan to augment the extension API to automatically store extensions to session resumption db (for the moment this only affect you in the sense that you will not see your extension in a resumed session, unless you dig deeper in libgnutls). regards, Nikos On Fri, Apr 23, 2010 at 3:11 PM, Carolin Latze wrote: > Hi everybody, > > I tried to write my own TLS extension and ran into problems when trying > to define an API for that extension. But let me explain step-by-step: > > I use gnutls 2.9.11 and followed > http://www.gnu.org/software/gnutls/devel/manual/gnutls.html#TLS-Extension-Handling > to add an extension that sends a fix HelloWorld message from client to > server and vice versa and prints it (using printf). In order to do so, I > modified and added the following files: > > lib/m4/hooks.m4 > lib/gnutls_int.h > lib/gnutls_extensions.c > lib/ext_helloworld.{h|c} > lib/Makefile.am > > That worked pretty well. My very simple client and server application > (they do a standard handshake) print out the HelloWorld as expected. > > Now, I wanted to add an API to be able to specify the HelloWorld message > within the client and server application. In order to do so, I added the > following line to lib/includes/gnutls/gnutls.h: > > int gnutls_helloworld_set_msg(gnutls_session_t session, const char *msg); > > The function itself is defined in lib/gnutls_helloworld.c. Furthermore I > added gnutls_helloworld.c to lib/Makefile.am. Running make and make > install does not show any problems but when I try to call > gnutls_helloworld_set_msg in my client application, I run into linker > problems: > > undefined reference to `gnutls_helloworld_set_msg' > > However when I run nm with my GnuTLS library, gnutls_helloworld_set_msg > is listed. > > Does anybody have an idea whats going wrong here? I assume I missed on > modification that is needed to export API methods, but I have no idea > where.... Any help would be appreciated. > > Carolin > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From lfinsto at gwdg.de Fri Apr 23 15:35:05 2010 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Fri, 23 Apr 2010 15:35:05 +0200 (CEST) Subject: My own TLS Extension - Hello World :-) In-Reply-To: <4BD19C74.3080000@unifr.ch> References: <4BD19C74.3080000@unifr.ch> Message-ID: <42839.134.76.5.25.1272029705.squirrel@mailbox.gwdg.de> On Fri, April 23, 2010 3:11 pm, Carolin Latze wrote: > > The function itself is defined in lib/gnutls_helloworld.c. Furthermore I added gnutls_helloworld.c to lib/Makefile.am. Running make and make install does not show any problems but when I try to call > gnutls_helloworld_set_msg in my client application, I run into linker problems: > > undefined reference to `gnutls_helloworld_set_msg' > > However when I run nm with my GnuTLS library, gnutls_helloworld_set_msg is listed. > > Does anybody have an idea whats going wrong here? I assume I missed on modification that is needed to export API methods, but I have no idea where.... Any help would be appreciated. > Is the linker finding your modified version of the library? Are the environment variables `LDFLAGS', `LIBS', `LIBPATH' and `LD_LIBRARY_PATH' set appropriately? `LIBPATH' may not be used, I don't know, and `LD_LIBRARY_PATH' is used at run-time, but it doesn't hurt to set them to sensible values. This is what `configure --help' has to say on the subject: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L if you have libraries in a nonstandard directory LIBS libraries to pass to the linker, e.g. -l CPPFLAGS C/C++/Objective C preprocessor flags, e.g. -I if you have headers in a nonstandard directory PKG_CONFIG path to pkg-config utility CPP C preprocessor CXX C++ compiler command CXXFLAGS C++ compiler flags CXXCPP C++ preprocessor Laurence Finston From carolin.latze at unifr.ch Fri Apr 23 16:10:38 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Fri, 23 Apr 2010 16:10:38 +0200 Subject: My own TLS Extension - Hello World :-) In-Reply-To: References: <4BD19C74.3080000@unifr.ch> Message-ID: <4BD1AA5E.4050701@unifr.ch> Hi Nikos, thanks a lot, that did it! In the end, I want to implement a proof-of-concept of the following draft: http://tools.ietf.org/html/draft-latze-tls-tpm-extns-01 However I decided to start with some simple HelloWorld examples first. Next step will be to implement a supplemental data handshake message ... (after the API works since I get segfaults now, but I assume those are a result of my great programming skills :)) Thanks a lot! Carolin On 04/23/10 15:32, Nikos Mavrogiannopoulos wrote: > Hello, > We hide all functions by default unless they are exported (in the gnu > linker at least). If I remember well it is the libgnutls.map file that > you need to change. Just from curiosity, which extension are you > trying to add? > > btw. I plan to augment the extension API to automatically store > extensions to session resumption db (for the moment this only affect > you in the sense that you will not see your extension in a resumed > session, unless you dig deeper in libgnutls). > > regards, > Nikos > > On Fri, Apr 23, 2010 at 3:11 PM, Carolin Latze wrote: > >> Hi everybody, >> >> I tried to write my own TLS extension and ran into problems when trying >> to define an API for that extension. But let me explain step-by-step: >> >> I use gnutls 2.9.11 and followed >> http://www.gnu.org/software/gnutls/devel/manual/gnutls.html#TLS-Extension-Handling >> to add an extension that sends a fix HelloWorld message from client to >> server and vice versa and prints it (using printf). In order to do so, I >> modified and added the following files: >> >> lib/m4/hooks.m4 >> lib/gnutls_int.h >> lib/gnutls_extensions.c >> lib/ext_helloworld.{h|c} >> lib/Makefile.am >> >> That worked pretty well. My very simple client and server application >> (they do a standard handshake) print out the HelloWorld as expected. >> >> Now, I wanted to add an API to be able to specify the HelloWorld message >> within the client and server application. In order to do so, I added the >> following line to lib/includes/gnutls/gnutls.h: >> >> int gnutls_helloworld_set_msg(gnutls_session_t session, const char *msg); >> >> The function itself is defined in lib/gnutls_helloworld.c. Furthermore I >> added gnutls_helloworld.c to lib/Makefile.am. Running make and make >> install does not show any problems but when I try to call >> gnutls_helloworld_set_msg in my client application, I run into linker >> problems: >> >> undefined reference to `gnutls_helloworld_set_msg' >> >> However when I run nm with my GnuTLS library, gnutls_helloworld_set_msg >> is listed. >> >> Does anybody have an idea whats going wrong here? I assume I missed on >> modification that is needed to export API methods, but I have no idea >> where.... Any help would be appreciated. >> >> Carolin >> >> >> _______________________________________________ >> Help-gnutls mailing list >> Help-gnutls at gnu.org >> http://lists.gnu.org/mailman/listinfo/help-gnutls >> >> -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de P?rolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From simon at josefsson.org Sun Apr 25 17:06:16 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 25 Apr 2010 17:06:16 +0200 Subject: My own TLS Extension - Hello World :-) In-Reply-To: <4BD1AA5E.4050701@unifr.ch> (Carolin Latze's message of "Fri, 23 Apr 2010 16:10:38 +0200") References: <4BD19C74.3080000@unifr.ch> <4BD1AA5E.4050701@unifr.ch> Message-ID: <87tyqzmv13.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi Nikos, > > thanks a lot, that did it! Great. I have improved the manual so that others won't run into that issue too. Btw, if you noticed any discrepancy between what's in the manual regarding adding a new extension and what you did, please let me know so I can improve the manual. You are the first to follow these instructions as far as I know. > In the end, I want to implement a proof-of-concept of the following > draft: http://tools.ietf.org/html/draft-latze-tls-tpm-extns-01 Good luck! /Simon From ali.khalfan at gmail.com Mon Apr 26 09:17:22 2010 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Mon, 26 Apr 2010 03:17:22 -0400 Subject: value is always different Message-ID: <4BD53E02.9030302@gmail.com> Hi, I've been trying to use gcrypt to calculate a MAC using sha256. It surprises me however, that everytime I run the script a different value comes int even though I'm using the same key and plain text. Is there somethigng i'm missing here? err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); gcry_md_setkey (ctx, key, 32); gcry_md_write(ctx, &plain_text,sizeof plain_text); unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); From bradh at frogmouth.net Mon Apr 26 10:38:09 2010 From: bradh at frogmouth.net (Brad Hards) Date: Mon, 26 Apr 2010 18:38:09 +1000 Subject: value is always different In-Reply-To: <4BD53E02.9030302@gmail.com> References: <4BD53E02.9030302@gmail.com> Message-ID: <201004261838.10102.bradh@frogmouth.net> On Monday 26 April 2010 05:17:22 pm Ali Khalfan wrote: > err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); > gcry_md_setkey (ctx, key, 32); > gcry_md_write(ctx, &plain_text,sizeof plain_text); > unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); This looks roughly right. Can you post a minimal compilable example that shows what the rest of the code looks like? Brad From ali.khalfan at gmail.com Mon Apr 26 17:06:39 2010 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Mon, 26 Apr 2010 11:06:39 -0400 Subject: value is always different In-Reply-To: <201004261838.10102.bradh@frogmouth.net> References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> Message-ID: <4BD5ABFF.7070309@gmail.com> The full code is just a few lines more I'll just post it all...., seems some sort of randomization is being added.......thanks for your help #include #include int main() { int err; gcry_md_hd_t ctx; char key[32] ="The fish is under the water"; char plain_text[256]; strcpy(plain_text,"It was the best of times it was the worst of times it was the happiest "); err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); gcry_md_setkey (ctx, key, 32); gcry_md_write(ctx, &plain_text,sizeof plain_text); unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); int index = 0; for (index; index<32; index++) printf("%02X", (unsigned char)digest[index]); gcry_md_close (ctx); return 0; } -------- Original Message -------- Subject: Re: value is always different From: Brad Hards To: help-gnutls at gnu.org Date: Mon Apr 26 2010 04:38:09 GMT-0400 (EDT) > On Monday 26 April 2010 05:17:22 pm Ali Khalfan wrote: > >> err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); >> gcry_md_setkey (ctx, key, 32); >> gcry_md_write(ctx, &plain_text,sizeof plain_text); >> unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); >> > This looks roughly right. Can you post a minimal compilable example that shows > what the rest of the code looks like? > > Brad > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From nmav at gnutls.org Mon Apr 26 18:37:14 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 26 Apr 2010 18:37:14 +0200 Subject: value is always different In-Reply-To: <4BD5ABFF.7070309@gmail.com> References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> <4BD5ABFF.7070309@gmail.com> Message-ID: <4BD5C13A.5080308@gnutls.org> Ali Khalfan wrote: > The full code is just a few lines more I'll just post it all...., seems > some sort of randomization is being added.......thanks for your help > gcry_md_write(ctx, &plain_text,sizeof plain_text); Be careful with pointers... Here "plain_text" should be used instead of "&plain_text". regards, Nikos From dkg at fifthhorseman.net Mon Apr 26 21:05:11 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 26 Apr 2010 15:05:11 -0400 Subject: value is always different In-Reply-To: <4BD5ABFF.7070309@gmail.com> References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> <4BD5ABFF.7070309@gmail.com> Message-ID: <4BD5E3E7.4080704@fifthhorseman.net> On 04/26/2010 11:06 AM, Ali Khalfan wrote: > char plain_text[256]; > strcpy(plain_text,"It was the best of times it was the worst of times it was the happiest "); > err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); > gcry_md_setkey (ctx, key, 32); > gcry_md_write(ctx, &plain_text,sizeof plain_text); > unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); In addition to Nikos' observation about misuse of pointers, i note that a big chunk of the plain_text buffer is not initialized by your code. That is, everything after the null byte following "happiest " is in whatever state it was in when plain_text[256] was allocated on the stack. Since you're passing the entire plain_text buffer (all 256 bytes) to the digest function, you're potentially digesting some arbitrary noise, depending on how your compiler cleans/prepares (or doesn't) the stack for use, and what was in that memory position in the first place. You could memset() or bzero() the buffer before strcpy() to ensure that it is a predictable value. hope this helps, --dkg PS this question might be better asked on a gcrypt-specific list, since it has nothing to do with gnutls itself. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From ali.khalfan at gmail.com Tue Apr 27 08:03:33 2010 From: ali.khalfan at gmail.com (Ali Khalfan) Date: Tue, 27 Apr 2010 02:03:33 -0400 Subject: value is always different In-Reply-To: <4BD5E3E7.4080704@fifthhorseman.net> References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> <4BD5ABFF.7070309@gmail.com> <4BD5E3E7.4080704@fifthhorseman.net> Message-ID: <4BD67E35.60000@gmail.com> thanks...all of you ..it works now -------- Original Message -------- Subject: Re: value is always different From: Daniel Kahn Gillmor To: Ali Khalfan Cc: help-gnutls at gnu.org Date: Mon Apr 26 2010 15:05:11 GMT-0400 (EDT) > On 04/26/2010 11:06 AM, Ali Khalfan wrote: > >> char plain_text[256]; >> strcpy(plain_text,"It was the best of times it was the worst of times it was the happiest "); >> err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); >> gcry_md_setkey (ctx, key, 32); >> gcry_md_write(ctx, &plain_text,sizeof plain_text); >> unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); >> > > In addition to Nikos' observation about misuse of pointers, i note that > a big chunk of the plain_text buffer is not initialized by your code. > > That is, everything after the null byte following "happiest " is in > whatever state it was in when plain_text[256] was allocated on the stack. > > Since you're passing the entire plain_text buffer (all 256 bytes) to the > digest function, you're potentially digesting some arbitrary noise, > depending on how your compiler cleans/prepares (or doesn't) the stack > for use, and what was in that memory position in the first place. > > You could memset() or bzero() the buffer before strcpy() to ensure that > it is a predictable value. > > hope this helps, > > --dkg > > PS this question might be better asked on a gcrypt-specific list, since > it has nothing to do with gnutls itself. > > From simon at josefsson.org Wed Apr 28 14:27:53 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 28 Apr 2010 14:27:53 +0200 Subject: value is always different In-Reply-To: <4BD5ABFF.7070309@gmail.com> (Ali Khalfan's message of "Mon, 26 Apr 2010 11:06:39 -0400") References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> <4BD5ABFF.7070309@gmail.com> Message-ID: <87eihzvk1i.fsf@mocca.josefsson.org> You also need to initialize libgcrypt properly before calling its functions. /Simon Ali Khalfan writes: > The full code is just a few lines more I'll just post it all...., seems > some sort of randomization is being added.......thanks for your help > > > > #include > > #include > > > int main() > { > int err; > gcry_md_hd_t ctx; > > char key[32] ="The fish is under the water"; > > char plain_text[256]; > > > > strcpy(plain_text,"It was the best of times it was the worst of > times it was the happiest "); > > err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); > > gcry_md_setkey (ctx, key, 32); > > gcry_md_write(ctx, &plain_text,sizeof plain_text); > > unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); > > > int index = 0; > for (index; index<32; index++) > printf("%02X", (unsigned char)digest[index]); > > gcry_md_close (ctx); > > > return 0; > } > > -------- Original Message -------- > Subject: Re: value is always different > From: Brad Hards > To: help-gnutls at gnu.org > Date: Mon Apr 26 2010 04:38:09 GMT-0400 (EDT) >> On Monday 26 April 2010 05:17:22 pm Ali Khalfan wrote: >> >>> err = gcry_md_open(&ctx,GCRY_MD_SHA256, GCRY_MD_FLAG_HMAC); >>> gcry_md_setkey (ctx, key, 32); >>> gcry_md_write(ctx, &plain_text,sizeof plain_text); >>> unsigned char *digest = gcry_md_read (ctx, GCRY_MD_SHA256); >>> >> This looks roughly right. Can you post a minimal compilable example that shows >> what the rest of the code looks like? >> >> Brad >> >> >> _______________________________________________ >> Help-gnutls mailing list >> Help-gnutls at gnu.org >> http://lists.gnu.org/mailman/listinfo/help-gnutls >> From dkg at fifthhorseman.net Wed Apr 28 20:12:48 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 28 Apr 2010 14:12:48 -0400 Subject: value is always different In-Reply-To: <87eihzvk1i.fsf@mocca.josefsson.org> References: <4BD53E02.9030302@gmail.com> <201004261838.10102.bradh@frogmouth.net> <4BD5ABFF.7070309@gmail.com> <87eihzvk1i.fsf@mocca.josefsson.org> Message-ID: <4BD87AA0.9080103@fifthhorseman.net> On 04/28/2010 08:27 AM, Simon Josefsson wrote: > You also need to initialize libgcrypt properly before calling its > functions. In particular, Simon is referring to this: http://www.gnupg.org/documentation/manuals/gcrypt/Initializing-the-library.html Recent versions of gcrypt grudgingly perform their own initialization if the caller does not do so, but it is strongly recommended to initialize the library explicitly instead. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From mrsam at courier-mta.com Thu Apr 29 02:30:01 2010 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Wed, 28 Apr 2010 20:30:01 -0400 Subject: Problem using the server name extension Message-ID: My client is compiled against gnutls 2.8.5. I am connecting to a server that's built against OpenSSL 1.0.0. The OpenSSL server is failing the handshake with the following error message: error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext After some Googling around, I remove my client's call to gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes OpenSSL happy. If I do not invoke gnutls_server_name_set(), we have a happy conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out during the handshake. Has anyone seen this before? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From simon at josefsson.org Thu Apr 29 10:03:24 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 29 Apr 2010 10:03:24 +0200 Subject: Problem using the server name extension In-Reply-To: (Sam Varshavchik's message of "Wed, 28 Apr 2010 20:30:01 -0400") References: Message-ID: <87aasmptwz.fsf@mocca.josefsson.org> Sam Varshavchik writes: > My client is compiled against gnutls 2.8.5. I am connecting to a > server that's built against OpenSSL 1.0.0. > > The OpenSSL server is failing the handshake with the following error > message: > > error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext > > After some Googling around, I remove my client's call to > gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes > OpenSSL happy. > > If I do not invoke gnutls_server_name_set(), we have a happy > conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out > during the handshake. > > Has anyone seen this before? We've seen it for very old implementations, notably some IBM-derived variant of OpenSSL, that cannot handle any extensions. But it is very surprising to see it for a recent OpenSSL. Are you sure OpenSSL 1.0.0 is used? Can you reproduce this using 'openssl s_server'? Maybe the application server is requesting SSLv2 from OpenSSL? /Simon From simon at josefsson.org Thu Apr 29 10:10:07 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 29 Apr 2010 10:10:07 +0200 Subject: safe renegotiation in client side In-Reply-To: <1268688690.24408.284.camel@vespa.frost.loc> (Tomas Mraz's message of "Mon, 15 Mar 2010 22:31:30 +0100") References: <4B9E9CA9.4070901@gnutls.org> <1268688690.24408.284.camel@vespa.frost.loc> Message-ID: <8739yeptls.fsf@mocca.josefsson.org> Tomas Mraz writes: > On Mon, 2010-03-15 at 21:46 +0100, Nikos Mavrogiannopoulos wrote: >> As you may have noticed there was a big fuss lately about a bug in the >> TLS protocol that could cause a client to connect to the wrong server >> via a renegotiation. There is a fix to the protocol that is >> unfortunately incompatible with previous versions (if security is >> required). Thus a gnutls client implementing the fix cannot connect to >> any non-patched server[0]. To achieve compatibility one has to to >> explicitly allow unsafe renegotiation with a priority string. This is >> not always possible since gnutls might be used unintentionally by a >> program via another library. >> >> With some trials in my system I noticed that the current behavior causes >> denial of service and a simple user might not even have control over the >> priority string for gnutls. >> >> Given your experiences (as system packager, user, implementor or so), >> what do you think is the adoption of priority strings in programs? Given >> a program that uses gnutls is it easy to set a string with the >> algorithms etc. needed for the negotiation? > > The OpenSSL upstream decided to allow the client to talk to the > unpatched servers by default. Of course it means that if the client > talks to such server it is vulnerable to the attack. They've also added > a function call so an application can query whether the connection is > protected by the safe renegotiation or not. GnuTLS will behave the same. > I, as maintainer of OpenSSL and gnutls packages in Fedora and Red Hat > Enterprise Linux, decided when backporting the safe renegotiation > patches to the old gnutls packages in released distributions, that the > client has to be tolerant to missing safe renegotiation support on > connected servers for now and so I have removed the strict client side > check from the backported patches. If the adoption of the safe > renegotiation extension gets better, we will release updated packages > which will contain the strict client side check. What is your opinion on whether servers should refuse renegotiation attempts from clients that doesn't support the extension? /Simon From carolin.latze at unifr.ch Thu Apr 29 13:41:16 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Thu, 29 Apr 2010 13:41:16 +0200 Subject: My own TLS Extension - Hello World :-) In-Reply-To: <87tyqzmv13.fsf@mocca.josefsson.org> References: <4BD19C74.3080000@unifr.ch> <4BD1AA5E.4050701@unifr.ch> <87tyqzmv13.fsf@mocca.josefsson.org> Message-ID: <4BD9705C.5050108@unifr.ch> Hi Simon, the manuel is pretty good. With Niko's little help, I was able to finish my helloworld extension without any further GnuTLS problems. Even the API is running now. I will go on with the supplemental data handshake message part now :) Carolin On 04/25/10 17:06, Simon Josefsson wrote: > Carolin Latze writes: > > >> Hi Nikos, >> >> thanks a lot, that did it! >> > Great. I have improved the manual so that others won't run into that > issue too. > > Btw, if you noticed any discrepancy between what's in the manual > regarding adding a new extension and what you did, please let me know so > I can improve the manual. You are the first to follow these > instructions as far as I know. > > >> In the end, I want to implement a proof-of-concept of the following >> draft: http://tools.ietf.org/html/draft-latze-tls-tpm-extns-01 >> > Good luck! > > /Simon > -- Carolin Latze PhD Student ICT Engineer Department of Computer Science Swisscom Strategy and Innovation Boulevard de P?rolles 90 Ostermundigenstrasse 93 CH-1700 Fribourg CH-3006 Bern phone: +41 26 300 83 30 +41 79 72 965 27 homepage: http://diuf.unifr.ch/people/latzec From mrsam at courier-mta.com Fri Apr 30 03:54:57 2010 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 29 Apr 2010 21:54:57 -0400 Subject: Problem using the server name extension References: <87aasmptwz.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > Sam Varshavchik writes: > >> My client is compiled against gnutls 2.8.5. I am connecting to a >> server that's built against OpenSSL 1.0.0. >> >> The OpenSSL server is failing the handshake with the following error >> message: >> >> error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext >> >> After some Googling around, I remove my client's call to >> gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes >> OpenSSL happy. >> >> If I do not invoke gnutls_server_name_set(), we have a happy >> conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out >> during the handshake. >> >> Has anyone seen this before? > > We've seen it for very old implementations, notably some IBM-derived > variant of OpenSSL, that cannot handle any extensions. But it is very > surprising to see it for a recent OpenSSL. Are you sure OpenSSL 1.0.0 > is used? Can you reproduce this using 'openssl s_server'? Maybe the > application server is requesting SSLv2 from OpenSSL? The application is the client, and since the application is GnuTLS, it can't be asking for SSLv2. Yes, Fedora 12, OpenSSL 1.0.0 is the server side. It's configured to accept all protocols (SSLv23_method() in OpenSSL's API), but I also tried TLSv1_method() as well, no difference. On the GnuTLS client side, I'm specifying GNUTLS_TLS1_1, GNUTLS_TLS1_0, and GNUTLS_SSL3 in that order. This is not a direct SSL/TLS connection, this is IMAP STARTTLS, so I can't easily drop in s_server in the server's place. I'll explore what debugging messages are available on the OpenSSL side. I gave up on the debugger. Debugging optimized code, on either the server or the client side, just doesn't work very well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nmav at gnutls.org Fri Apr 30 09:05:04 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 30 Apr 2010 09:05:04 +0200 Subject: Problem using the server name extension In-Reply-To: References: Message-ID: <4BDA8120.3000707@gnutls.org> Sam Varshavchik wrote: > My client is compiled against gnutls 2.8.5. I am connecting to a server > that's built against OpenSSL 1.0.0. > The OpenSSL server is failing the handshake with the following error > message: > error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext > After some Googling around, I remove my client's call to > gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes OpenSSL > happy. Cannot verify it with openssl s_server and gnutls 2.9.x (name server indication code hasn't changed since 2.8). Can you provide a reproducible example? regards, Nikos From carolin.latze at unifr.ch Fri Apr 30 16:06:40 2010 From: carolin.latze at unifr.ch (Carolin Latze) Date: Fri, 30 Apr 2010 16:06:40 +0200 Subject: supplemental data handshake message Message-ID: <4BDAE3F0.6070804@unifr.ch> Hi everybody, since there seems to be no documentation about how to implement a new supplemental data handshake message (except for some comments in lib/gnutls_supplemental.c), I have to come up with a new question: According to lib/gnutls_supplemental.c, an extension that wants to send supplemental data has to set the do_send_supplemental flag. Furthermore the party expecting supplemental data has to set do_recv_supplemental. For my little helloworld extension, I did that in lib/ext_helloworld.c in the extension's send and recv method. That seems to work, since the debug out tells me, gnutls expects supplemental data. Furthermore, I add those two methods to ext_helloworld.c: int _gnutls_helloworld_supp_recv_params(gnutls_session_t session,const opaque *data,size_t _data_size) { uint8_t len; ssize_t data_size = _data_size; unsigned char *msg; if (data_size > 0) { len = data[0]; DECR_LEN (data_size, len); msg=(unsigned char*)malloc(len*sizeof(unsigned char)); memcpy(msg,&data[1],len); msg[len]='\0'; printf("supp data: %s\n",msg); } return 0; } int _gnutls_helloworld_supp_send_params(gnutls_session_t session,gnutls_buffer *buf) { unsigned char *msg = "supp hello"; int len = strlen(msg); _gnutls_buffer_init(buf); _gnutls_buffer_append(buf,msg,(uint8_t) len); return len; } I am sure, I missed something since my GnuTLS client crashes: EXT[0x8c30378]: Found extension 'SAFE_RENEGOTIATION/65281' EXT[0x8c30378]: Found extension 'HELLOWORLD/40' received msg: Hello little one Safe renegotiation succeeded. EXT[0x8c30378]: Expecting supplemental data REC[0x8c30378]: Expected Packet[1] Handshake(22) with length: 1 REC[0x8c30378]: Received Packet[1] Handshake(22) with length: 7 REC[0x8c30378]: Decrypted Packet[1] Handshake(22) with length: 7 HSK[0x8c30378]: SUPPLEMENTAL was received [7 bytes] ASSERT: gnutls_supplemental.c:183 ASSERT: gnutls_handshake.c:2650 ASSERT: gnutls_handshake.c:2783 ERROR: Handshake failed Why does he expect a message with length 1? I suspect, that is the problem here, right? Any ideas or hints? Carolin From simon at josefsson.org Fri Apr 30 17:01:20 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 30 Apr 2010 17:01:20 +0200 Subject: Problem using the server name extension In-Reply-To: (Sam Varshavchik's message of "Thu, 29 Apr 2010 21:54:57 -0400") References: <87aasmptwz.fsf@mocca.josefsson.org> Message-ID: <8739ydf0hr.fsf@mocca.josefsson.org> Sam Varshavchik writes: > Simon Josefsson writes: > >> Sam Varshavchik writes: >> >>> My client is compiled against gnutls 2.8.5. I am connecting to a >>> server that's built against OpenSSL 1.0.0. >>> >>> The OpenSSL server is failing the handshake with the following error >>> message: >>> >>> error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext >>> >>> After some Googling around, I remove my client's call to >>> gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes >>> OpenSSL happy. >>> >>> If I do not invoke gnutls_server_name_set(), we have a happy >>> conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out >>> during the handshake. >>> >>> Has anyone seen this before? >> >> We've seen it for very old implementations, notably some IBM-derived >> variant of OpenSSL, that cannot handle any extensions. But it is very >> surprising to see it for a recent OpenSSL. Are you sure OpenSSL 1.0.0 >> is used? Can you reproduce this using 'openssl s_server'? Maybe the >> application server is requesting SSLv2 from OpenSSL? > > The application is the client, and since the application is GnuTLS, it > can't be asking for SSLv2. > > Yes, Fedora 12, OpenSSL 1.0.0 is the server side. It's configured to > accept all protocols (SSLv23_method() in OpenSSL's API), but I also > tried TLSv1_method() as well, no difference. > > On the GnuTLS client side, I'm specifying GNUTLS_TLS1_1, > GNUTLS_TLS1_0, and GNUTLS_SSL3 in that order. This is not a direct > SSL/TLS connection, this is IMAP STARTTLS, so I can't easily drop in > s_server in the server's place. > > I'll explore what debugging messages are available on the OpenSSL > side. I gave up on the debugger. Debugging optimized code, on either > the server or the client side, just doesn't work very well. Maybe you can reproduce this using 'gnutls-cli'? It supports STARTTLS by using --starttls and entering ^D when you want to start the TLS handshake. Please post output from 'gnutls-cli -d 4711' if you can reproduce it. Maybe the server name you provide is simply the wrong one, and that's why the server refuses to talk with you? /Simon From simon at josefsson.org Fri Apr 30 17:08:12 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 30 Apr 2010 17:08:12 +0200 Subject: supplemental data handshake message In-Reply-To: <4BDAE3F0.6070804@unifr.ch> (Carolin Latze's message of "Fri, 30 Apr 2010 16:06:40 +0200") References: <4BDAE3F0.6070804@unifr.ch> Message-ID: <87vdb9dllv.fsf@mocca.josefsson.org> Carolin Latze writes: > Hi everybody, > > since there seems to be no documentation about how to implement a new > supplemental data handshake message (except for some comments in > lib/gnutls_supplemental.c), I have to come up with a new question: > > According to lib/gnutls_supplemental.c, an extension that wants to send > supplemental data has to set the do_send_supplemental flag. Furthermore > the party expecting supplemental data has to set do_recv_supplemental. > For my little helloworld extension, I did that in lib/ext_helloworld.c > in the extension's send and recv method. That seems to work, since the > debug out tells me, gnutls expects supplemental data. Furthermore, I add > those two methods to ext_helloworld.c: > > int _gnutls_helloworld_supp_recv_params(gnutls_session_t session,const > opaque *data,size_t _data_size) > { > uint8_t len; > ssize_t data_size = _data_size; > unsigned char *msg; > > if (data_size > 0) > { > len = data[0]; > DECR_LEN (data_size, len); > msg=(unsigned char*)malloc(len*sizeof(unsigned char)); > memcpy(msg,&data[1],len); > msg[len]='\0'; > printf("supp data: %s\n",msg); > } > > return 0; Shouldn't you return the length of parsed data here? Look at gnutls_supplemental.c, the function _gnutls_parse_supplemental trusts your function to return the proper length for incrementing the length pointer for its parsing code. Just a quick response, haven't looked into this in detail. /Simon > > } > > int _gnutls_helloworld_supp_send_params(gnutls_session_t > session,gnutls_buffer *buf) > { > > unsigned char *msg = "supp hello"; > int len = strlen(msg); > > _gnutls_buffer_init(buf); > _gnutls_buffer_append(buf,msg,(uint8_t) len); > > return len; > > } > > I am sure, I missed something since my GnuTLS client crashes: > > EXT[0x8c30378]: Found extension 'SAFE_RENEGOTIATION/65281' > EXT[0x8c30378]: Found extension 'HELLOWORLD/40' > received msg: Hello little one > Safe renegotiation succeeded. > EXT[0x8c30378]: Expecting supplemental data > REC[0x8c30378]: Expected Packet[1] Handshake(22) with length: 1 > REC[0x8c30378]: Received Packet[1] Handshake(22) with length: 7 > REC[0x8c30378]: Decrypted Packet[1] Handshake(22) with length: 7 > HSK[0x8c30378]: SUPPLEMENTAL was received [7 bytes] > ASSERT: gnutls_supplemental.c:183 > ASSERT: gnutls_handshake.c:2650 > ASSERT: gnutls_handshake.c:2783 > ERROR: Handshake failed > > Why does he expect a message with length 1? I suspect, that is the > problem here, right? Any ideas or hints? > > Carolin From mrsam at courier-mta.com Fri Apr 30 23:58:52 2010 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 30 Apr 2010 17:58:52 -0400 Subject: Problem using the server name extension References: <87aasmptwz.fsf@mocca.josefsson.org> <8739ydf0hr.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > Sam Varshavchik writes: > >> Simon Josefsson writes: >> >>> Sam Varshavchik writes: >>> >>>> My client is compiled against gnutls 2.8.5. I am connecting to a >>>> server that's built against OpenSSL 1.0.0. >>>> >>>> The OpenSSL server is failing the handshake with the following error >>>> message: >>>> >>>> error:1408A0E3:SSL routines:SSL3_GET_CLIENT_HELLO:parse tlsext >>>> >>>> After some Googling around, I remove my client's call to >>>> gnutls_server_name_set( .. GNUTLS_NAME_DNS .. ), and that makes >>>> OpenSSL happy. >>>> >>>> If I do not invoke gnutls_server_name_set(), we have a happy >>>> conversation. If I invoke gnutls_server_name_set(), OpenSSL bombs out >>>> during the handshake. >>>> >>>> Has anyone seen this before? >>> >>> We've seen it for very old implementations, notably some IBM-derived >>> variant of OpenSSL, that cannot handle any extensions. But it is very >>> surprising to see it for a recent OpenSSL. Are you sure OpenSSL 1.0.0 >>> is used? Can you reproduce this using 'openssl s_server'? Maybe the >>> application server is requesting SSLv2 from OpenSSL? >> >> The application is the client, and since the application is GnuTLS, it >> can't be asking for SSLv2. >> >> Yes, Fedora 12, OpenSSL 1.0.0 is the server side. It's configured to >> accept all protocols (SSLv23_method() in OpenSSL's API), but I also >> tried TLSv1_method() as well, no difference. >> >> On the GnuTLS client side, I'm specifying GNUTLS_TLS1_1, >> GNUTLS_TLS1_0, and GNUTLS_SSL3 in that order. This is not a direct >> SSL/TLS connection, this is IMAP STARTTLS, so I can't easily drop in >> s_server in the server's place. >> >> I'll explore what debugging messages are available on the OpenSSL >> side. I gave up on the debugger. Debugging optimized code, on either >> the server or the client side, just doesn't work very well. > > Maybe you can reproduce this using 'gnutls-cli'? It supports STARTTLS > by using --starttls and entering ^D when you want to start the TLS > handshake. Please post output from 'gnutls-cli -d 4711' if you can > reproduce it. Well now, that seems to work. The handshake appears to complete successfully with gnutls-cli. Perusing gnutls-cli's source, it does seem to use gnutls_server_name_set() by default, so this is a valid, working baseline. So, it appears that I'm doing something on the client side, with GnuTLS, that's making OpenSSL on the server side crap out. Looks like I have something that I can dig into. Stay tuned. > Maybe the server name you provide is simply the wrong one, and that's > why the server refuses to talk with you? I don't think that's it. It's "localhost" in both cases. I'm not certain that OpenSSL implements this extension. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: