From david.hubner at smoothwall.net Tue Dec 3 15:35:36 2013 From: david.hubner at smoothwall.net (David Hubner) Date: Tue, 3 Dec 2013 14:35:36 +0000 Subject: [gnutls-help] gnutls cert chain for tesco not being verified. Message-ID: <201312031435.36667.david.hubner@smoothwall.net> Hi, I am having a certificate chain issue. Going to the site https://www.tescobank.com/sss/auth which gets the intermediate cert as well as the site cert. We have the CA cert in the certificate store. It seems gnutls is not verifiying the cert chain and I cannot seem to find out why. I am using gnutls 3.1.16. Thanks -- David Hubner Software Developer david.hubner at smoothwall.net Smoothwall Ltd 1 John Charles Way, Leeds, LS12 6QA United Kingdom Telephone: USA: 1 800 959 3760 Europe: +44 (0) 8701 999500 www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247. This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of Smoothwall Limited. Any opinions stated in this message are solely those of the author. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Dec 3 16:22:26 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 03 Dec 2013 10:22:26 -0500 Subject: [gnutls-help] gnutls cert chain for tesco not being verified. In-Reply-To: <201312031435.36667.david.hubner@smoothwall.net> References: <201312031435.36667.david.hubner@smoothwall.net> Message-ID: <529DF732.8080606@fifthhorseman.net> On 12/03/2013 09:35 AM, David Hubner wrote: > I am having a certificate chain issue. Going to the site > https://www.tescobank.com/sss/auth which gets the intermediate cert as well as > the site cert. We have the CA cert in the certificate store. > > It seems gnutls is not verifiying the cert chain and I cannot seem to find out > why. I am using gnutls 3.1.16. the certificate seems to validate for me (using gnutls 3.2.6) with "gnutls-cli www.tescobank.com" -- can you show the full output of the above command when you try with 3.1.16 ? --dkg 0 dkg at alice:~$ echo | gnutls-cli www.tescobank.com Processed 156 CA certificate(s). Resolving 'www.tescobank.com'... Connecting to '178.17.64.12:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=GB,ST=Midlothian,L=Haymarket Yards,jurisdictionOfIncorporationCountryName=GB,O=Tesco Personal Finance PLC,businessCategory=Private Organization,serialNumber=SC173199+CN=www.tescobank.com', issuer `C=US,O=Entrust\, Inc.,OU=www.entrust.net/rpa is incorporated by reference,OU=(c) 2009 Entrust\, Inc.,CN=Entrust Certification Authority - L1E', RSA key 2048 bits, signed using RSA-SHA1, activated `2013-01-15 13:49:50 UTC', expires `2015-01-15 15:04:14 UTC', SHA-1 fingerprint `f10ba36343860643ffabbd78ce4bacc79572fab0' Public Key ID: 0526e859a4c5614ae325df3bd26c260b51b826b1 Public key's random art: +--[ RSA 2048]----+ | +=O.o | | .oo at o+ . | | +=+. . . | | E =. o o | | o. o S | | . * . | | . | | | | | +-----------------+ - Certificate[1] info: - subject `C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root Certification Authority', issuer `C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2007-01-05 19:20:39 UTC', expires `2017-01-05 19:50:39 UTC', SHA-1 fingerprint `bee772b3190ac84bf831f9607d9889ec6a966c16' - Certificate[2] info: - subject `C=US,O=Entrust\, Inc.,OU=www.entrust.net/rpa is incorporated by reference,OU=(c) 2009 Entrust\, Inc.,CN=Entrust Certification Authority - L1E', issuer `C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS is incorporated by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-12-10 20:55:43 UTC', expires `2019-12-10 21:25:43 UTC', SHA-1 fingerprint `179a7696db4322813f1c9572b85033841dec020e' - Status: The certificate is trusted. - Description: (TLS1.0-PKIX)-(RSA)-(AES-128-CBC)-(SHA1) - Session ID: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:01:64:58:52:9D:F9:67:00:00:00:00:57:1E:31:AC - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-128-CBC - MAC: SHA1 - Compression: NULL - Handshake was completed - Simple Client Mode: 0 dkg at alice:~$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From david.hubner at smoothwall.net Tue Dec 3 16:34:58 2013 From: david.hubner at smoothwall.net (David Hubner) Date: Tue, 3 Dec 2013 15:34:58 +0000 Subject: [gnutls-help] gnutls cert chain for tesco not being verified. In-Reply-To: <529DF732.8080606@fifthhorseman.net> References: <201312031435.36667.david.hubner@smoothwall.net> <529DF732.8080606@fifthhorseman.net> Message-ID: <201312031534.58539.david.hubner@smoothwall.net> Hi, Output is at http://pastebin.com/zeEzaqA0 Thanks -- David Hubner Software Developer david.hubner at smoothwall.net Smoothwall Ltd 1 John Charles Way, Leeds, LS12 6QA United Kingdom Telephone: USA: 1 800 959 3760 Europe: +44 (0) 8701 999500 www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247. This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of Smoothwall Limited. Any opinions stated in this message are solely those of the author. > On 12/03/2013 09:35 AM, David Hubner wrote: > > I am having a certificate chain issue. Going to the site > > https://www.tescobank.com/sss/auth which gets the intermediate cert as > > well as the site cert. We have the CA cert in the certificate store. > > > > It seems gnutls is not verifiying the cert chain and I cannot seem to > > find out why. I am using gnutls 3.1.16. > > the certificate seems to validate for me (using gnutls 3.2.6) with > "gnutls-cli www.tescobank.com" -- can you show the full output of the > above command when you try with 3.1.16 ? > > --dkg > > > 0 dkg at alice:~$ echo | gnutls-cli www.tescobank.com > Processed 156 CA certificate(s). > Resolving 'www.tescobank.com'... > Connecting to '178.17.64.12:443'... > - Certificate type: X.509 > - Got a certificate list of 3 certificates. > - Certificate[0] info: > - subject `C=GB,ST=Midlothian,L=Haymarket > Yards,jurisdictionOfIncorporationCountryName=GB,O=Tesco Personal Finance > PLC,businessCategory=Private > Organization,serialNumber=SC173199+CN=www.tescobank.com', issuer > `C=US,O=Entrust\, Inc.,OU=www.entrust.net/rpa is incorporated by > reference,OU=(c) 2009 Entrust\, Inc.,CN=Entrust Certification Authority > - L1E', RSA key 2048 bits, signed using RSA-SHA1, activated `2013-01-15 > 13:49:50 UTC', expires `2015-01-15 15:04:14 UTC', SHA-1 fingerprint > `f10ba36343860643ffabbd78ce4bacc79572fab0' > Public Key ID: > 0526e859a4c5614ae325df3bd26c260b51b826b1 > Public key's random art: > +--[ RSA 2048]----+ > > | +=O.o | > | > | .oo at o+ . | > | > | +=+. . . | > | > | E =. o o | > | > | o. o S | > | > | . * . | > | > | . | > > +-----------------+ > > - Certificate[1] info: > - subject `C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS is incorporated > by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root Certification > Authority', issuer `C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by > ref. (limits liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net > Secure Server Certification Authority', RSA key 2048 bits, signed using > RSA-SHA1, activated `2007-01-05 19:20:39 UTC', expires `2017-01-05 > 19:50:39 UTC', SHA-1 fingerprint `bee772b3190ac84bf831f9607d9889ec6a966c16' > - Certificate[2] info: > - subject `C=US,O=Entrust\, Inc.,OU=www.entrust.net/rpa is incorporated > by reference,OU=(c) 2009 Entrust\, Inc.,CN=Entrust Certification > Authority - L1E', issuer `C=US,O=Entrust\, Inc.,OU=www.entrust.net/CPS > is incorporated by reference,OU=(c) 2006 Entrust\, Inc.,CN=Entrust Root > Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, > activated `2009-12-10 20:55:43 UTC', expires `2019-12-10 21:25:43 UTC', > SHA-1 fingerprint `179a7696db4322813f1c9572b85033841dec020e' > - Status: The certificate is trusted. > - Description: (TLS1.0-PKIX)-(RSA)-(AES-128-CBC)-(SHA1) > - Session ID: > 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:01:64:58:52:9D:F9:67:00: > 00:00:00:57:1E:31:AC - Version: TLS1.0 > - Key Exchange: RSA > - Cipher: AES-128-CBC > - MAC: SHA1 > - Compression: NULL > - Handshake was completed > > - Simple Client Mode: > > 0 dkg at alice:~$ From dkg at fifthhorseman.net Tue Dec 3 17:07:31 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 03 Dec 2013 11:07:31 -0500 Subject: [gnutls-help] gnutls cert chain for tesco not being verified. In-Reply-To: <201312031534.58539.david.hubner@smoothwall.net> References: <201312031435.36667.david.hubner@smoothwall.net> <529DF732.8080606@fifthhorseman.net> <201312031534.58539.david.hubner@smoothwall.net> Message-ID: <529E01C3.8060409@fifthhorseman.net> On 12/03/2013 10:34 AM, David Hubner wrote: > Output is at http://pastebin.com/zeEzaqA0 line 1 of that output is: Error setting the x509 trust file Your output does not show the command you ran; can you indicate that explicitly? (in general, when showing a terminal transcript for purposes of debugging, it's helpful to show the specific command you ran, as well as the output it produced) your original message says "We have the CA cert in the certificate store." -- what does that mean specifically? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From david.hubner at smoothwall.net Wed Dec 4 10:50:41 2013 From: david.hubner at smoothwall.net (David Hubner) Date: Wed, 4 Dec 2013 09:50:41 +0000 Subject: [gnutls-help] gnutls cert chain for tesco not being verified. In-Reply-To: <529E01C3.8060409@fifthhorseman.net> References: <201312031435.36667.david.hubner@smoothwall.net> <201312031534.58539.david.hubner@smoothwall.net> <529E01C3.8060409@fifthhorseman.net> Message-ID: <201312040950.41200.david.hubner@smoothwall.net> Hi, Ignore this. I was not being to smart and was using the completely broken cert for --x509cafile. Sorry about that. Thanks -- David Hubner Software Developer david.hubner at smoothwall.net Smoothwall Ltd 1 John Charles Way, Leeds, LS12 6QA United Kingdom Telephone: USA: 1 800 959 3760 Europe: +44 (0) 8701 999500 www.smoothwall.net Smoothwall Limited is registered in England, Company Number: 4298247. This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of Smoothwall Limited. Any opinions stated in this message are solely those of the author. > On 12/03/2013 10:34 AM, David Hubner wrote: > > Output is at http://pastebin.com/zeEzaqA0 > > line 1 of that output is: > > Error setting the x509 trust file > > Your output does not show the command you ran; can you indicate that > explicitly? (in general, when showing a terminal transcript for > purposes of debugging, it's helpful to show the specific command you > ran, as well as the output it produced) > > your original message says "We have the CA cert in the certificate > store." -- what does that mean specifically? > > Regards, > > --dkg From thomas at habets.se Thu Dec 5 15:53:20 2013 From: thomas at habets.se (Thomas Habets) Date: Thu, 5 Dec 2013 14:53:20 +0000 Subject: [gnutls-help] Using TPM with PKCS#11 applications Message-ID: Hi. Reading http://www.gnutls.org/manual/html_node/Hardware-security-modules-and-abstract-key-types.html I understand the situation to be that GnuTLS has support for TPM chips via libtspi, and GnuTLS supports *using* PKCS#11, but doesn't support being used as a PKCS#11 provider. Is that right? I want TPM behind a PKCS11 provider to protect SSH client keys, and have written a pkcs11 module that works directly with libtspi. I'm trying to find out if GnuTLS has code for this already: http://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From nmav at gnutls.org Thu Dec 5 17:25:41 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 5 Dec 2013 17:25:41 +0100 Subject: [gnutls-help] Using TPM with PKCS#11 applications In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 3:53 PM, Thomas Habets wrote: > Hi. > > Reading http://www.gnutls.org/manual/html_node/Hardware-security-modules-and-abstract-key-types.html > I understand the situation to be that GnuTLS has support for TPM chips > via libtspi, Hello, The above is correct. > and GnuTLS supports *using* PKCS#11, but doesn't support > being used as a PKCS#11 provider. Is that right? No. GnuTLS doesn't provide a PKCS #11 module. > I want TPM behind a PKCS11 provider to protect SSH client keys, and > have written a pkcs11 module that works directly with libtspi. I'm > trying to find out if GnuTLS has code for this already: > http://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly The trousers library provides a PKCS #11 front-end. I've never managed to set it up though. If you are using gnutls I'd suggest to use directly the TPM interface or simply the TPM urls. regards, Nikos From thomas at habets.se Thu Dec 5 17:45:36 2013 From: thomas at habets.se (Thomas Habets) Date: Thu, 5 Dec 2013 16:45:36 +0000 Subject: [gnutls-help] Using TPM with PKCS#11 applications In-Reply-To: References: Message-ID: On 5 December 2013 16:25, Nikos Mavrogiannopoulos wrote: >> and GnuTLS supports *using* PKCS#11, but doesn't support >> being used as a PKCS#11 provider. Is that right? > No. GnuTLS doesn't provide a PKCS #11 module. I'm not sure if you misread what I wrote. What do you mean by "PKCS #11 module"? It looks on this illustration like it can interface with PKCS#11 providers at least: http://www.gnutls.org/manual/html_node/Smart-cards-and-HSMs.html but I don't see evidence of being able to act as a PKCS#11 provider. > The trousers library provides a PKCS #11 front-end. I've never managed > to set it up though. Do you mean libopencryptoki.so? I've deliberately chosen not to use that one for various reasons. > If you are using gnutls I'd suggest to use directly the TPM interface > or simply the TPM urls. I'm leaning more towards going over PKCS#11, maybe via p11-kit. If nothing else so that I get the ability of using the same key pair for SSH and SSL, if I so choose. But I'm aware of the API for using TPM with SSL that GnuTLS has. -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From nmav at gnutls.org Thu Dec 5 18:19:51 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 5 Dec 2013 18:19:51 +0100 Subject: [gnutls-help] Using TPM with PKCS#11 applications In-Reply-To: References: Message-ID: On Thu, Dec 5, 2013 at 5:45 PM, Thomas Habets wrote: >>> and GnuTLS supports *using* PKCS#11, but doesn't support >>> being used as a PKCS#11 provider. Is that right? >> No. GnuTLS doesn't provide a PKCS #11 module. > I'm not sure if you misread what I wrote. What do you mean by "PKCS #11 module"? A .so library that provides the PKCS #11 interface. > It looks on this illustration like it can interface with PKCS#11 > providers at least: > http://www.gnutls.org/manual/html_node/Smart-cards-and-HSMs.html > but I don't see evidence of being able to act as a PKCS#11 provider. Indeed, it can read from other providers, but itself is not one. If I understood correctly, gnome-keyring may be closer to what you're looking for - https://wiki.gnome.org/Projects/GnomeKeyring/Architecture. I don't know the status of its TPM support though. >> The trousers library provides a PKCS #11 front-end. I've never managed >> to set it up though. > Do you mean libopencryptoki.so? I've deliberately chosen not to use > that one for various reasons. Would you mind sharing them? regards, Nikos From thomas at habets.se Thu Dec 5 18:37:06 2013 From: thomas at habets.se (Thomas Habets) Date: Thu, 5 Dec 2013 17:37:06 +0000 Subject: [gnutls-help] Using TPM with PKCS#11 applications In-Reply-To: References: Message-ID: On 5 December 2013 17:19, Nikos Mavrogiannopoulos wrote: >> Do you mean libopencryptoki.so? I've deliberately chosen not to use >> that one for various reasons. > Would you mind sharing them? They're on http://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly * It generates at least some keys in software. * It generates migratable keys. This is hardcoded, and some people obviously want migratable keys (for backup purposes). So a fix would have to involve supporting both. * Opencryptoki has no way to send such parameters from the command line key generator to the PKCS11 library. So not only would I have to implement the setting, but the whole settings subsystem. * The code is big, because it supports a lot of features. Features I don't need or want. They get in the way of me as a user, and of me fixing the other issues. * The code is of pretty poor quality. So it seems that I could use gnutls as a layer between libtspi and my PKCS#11 provider, adding nice things like a standard tool for generating keys (tpmtool) into a standard format. It would add a dependency though, especially since e.g. Debian doesn't have a new enough gnutls. -- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From lavr at ncbi.nlm.nih.gov Tue Dec 17 20:01:05 2013 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Tue, 17 Dec 2013 19:01:05 +0000 Subject: [gnutls-help] Can't get ANON auth working per the documentation example Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> Hi All, I'm new here in this list, and I have a question about GNUTLS that I do not understand. Per the documentation example, I'm creating a client session like this: gnutls_anon_client_credentials_t acred; gnutls_anon_allocate_client_credentials(&acred); gnutls_set_default_priority(session); gnutls_priority_set_direct(session, "PERFORMANCE:+ANON-DH", NULL); gnutls_credentials_set(session, GNUTLS_CRD_ANON, acred); But I get the following error (wherever I tried to connect to, whether real HTTP servers or gnutls-serv starter locally), from gnutls_handshake(): error=-12,A TLS fatal alert has been received I use the following command to launch gnutls-serv: gnutls-serv.exe -d 99 -a --http Here's what I see on the server side, followed by what's going on at the client's. The question is why does not it work? What I'm doing wrong? SERVER: |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/pkcs11.c:456 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/x509/mpi.c:246 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_dh_primes.c:289 Set static Diffie-Hellman parameters, consider --dhparams. HTTP Server listening on IPv6 :: port 5556...done HTTP Server listening on IPv4 0.0.0.0 port 5556...done |<4>| REC[0x800ac470]: Allocating epoch #0 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/ext/session_ticket.c:546 * Accepted connection from IPv4 127.0.0.1 port 52175 on Tue Dec 17 13:52:20 2013 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_constate.c:715 |<4>| REC[0x800ac470]: Allocating epoch #1 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_buffers.c:1018 |<7>| READ: Got 5 bytes from 0x6 |<7>| READ: read 5 bytes from 0x6 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[0x800ac470]: SSL 3.0 Handshake packet received. Epoch 0, length: 135 |<4>| REC[0x800ac470]: Expected Packet Handshake(22) |<4>| REC[0x800ac470]: Received Packet Handshake(22) with length: 135 |<7>| READ: Got 135 bytes from 0x6 |<7>| READ: read 135 bytes from 0x6 |<7>| RB: Have 5 bytes into buffer. Adding 135 bytes. |<7>| RB: Requested 140 bytes |<4>| REC[0x800ac470]: Decrypted Packet[0] Handshake(22) with length: 135 |<6>| BUF[REC]: Inserted 135 bytes of Data(22) |<3>| HSK[0x800ac470]: CLIENT HELLO (1) was received. Length 131[131], frag offset 0, frag length: 131, sequence: 0 |<3>| HSK[0x800ac470]: Client's version: 3.3 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_db.c:265 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_db.c:297 |<3>| EXT[0x800ac470]: Found extension 'STATUS REQUEST/5' |<3>| EXT[0x800ac470]: Found extension 'SAFE RENEGOTIATION/65281' |<3>| EXT[0x800ac470]: Found extension 'SESSION TICKET/35' |<3>| EXT[0x800ac470]: Found extension 'SUPPORTED ECC/10' |<3>| EXT[0x800ac470]: Found extension 'SUPPORTED ECC POINT FORMATS/11' |<3>| EXT[0x800ac470]: Found extension 'SIGNATURE ALGORITHMS/13' |<3>| EXT[0x800ac470]: Found extension 'STATUS REQUEST/5' |<3>| EXT[0x800ac470]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<3>| EXT[0x800ac470]: Parsing extension 'SESSION TICKET/35' (0 bytes) |<3>| EXT[0x800ac470]: Found extension 'SUPPORTED ECC/10' |<3>| EXT[0x800ac470]: Found extension 'SUPPORTED ECC POINT FORMATS/11' |<3>| EXT[0x800ac470]: Found extension 'SIGNATURE ALGORITHMS/13' |<3>| EXT[0x800ac470]: Parsing extension 'STATUS REQUEST/5' (5 bytes) |<3>| EXT[0x800ac470]: Found extension 'SAFE RENEGOTIATION/65281' |<3>| EXT[0x800ac470]: Found extension 'SESSION TICKET/35' |<3>| EXT[0x800ac470]: Parsing extension 'SUPPORTED ECC/10' (12 bytes) |<3>| HSK[0x800ac470]: Selected ECC curve SECP192R1 (5) |<3>| EXT[0x800ac470]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11' (2 bytes) |<3>| EXT[0x800ac470]: Parsing extension 'SIGNATURE ALGORITHMS/13' (28 bytes) |<3>| EXT[0x800ac470]: rcvd signature algo (4.1) RSA-SHA256 |<3>| EXT[0x800ac470]: rcvd signature algo (4.2) DSA-SHA256 |<3>| EXT[0x800ac470]: rcvd signature algo (4.3) ECDSA-SHA256 |<3>| EXT[0x800ac470]: rcvd signature algo (5.1) RSA-SHA384 |<3>| EXT[0x800ac470]: rcvd signature algo (5.3) ECDSA-SHA384 |<3>| EXT[0x800ac470]: rcvd signature algo (6.1) RSA-SHA512 |<3>| EXT[0x800ac470]: rcvd signature algo (6.3) ECDSA-SHA512 |<3>| EXT[0x800ac470]: rcvd signature algo (3.1) RSA-SHA224 |<3>| EXT[0x800ac470]: rcvd signature algo (3.2) DSA-SHA224 |<3>| EXT[0x800ac470]: rcvd signature algo (3.3) ECDSA-SHA224 |<3>| EXT[0x800ac470]: rcvd signature algo (2.1) RSA-SHA1 |<3>| EXT[0x800ac470]: rcvd signature algo (2.2) DSA-SHA1 |<3>| EXT[0x800ac470]: rcvd signature algo (2.3) ECDSA-SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 |<3>| HSK[0x800ac470]: Removing ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_AES_128_GCM_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[0x800ac470]: Removing ciphersuite: RSA_ARCFOUR_MD5 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_handshake.c:866 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_handshake.c:586 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_handshake.c:2093 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_handshake.c:1317 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_handshake.c:2906 Error in handshake Error: Could not negotiate a supported cipher suite. |<4>| REC: Sending Alert[2|40] - Handshake failed |<4>| REC[0x800ac470]: Preparing Packet Alert(21) with length: 2 |<9>| ENC[0x800ac470]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 7 bytes for 0x6. Total 7 bytes. |<7>| WRITE FLUSH: 7 bytes in buffer. |<7>| WRITE: wrote 7 bytes, 0 bytes left. |<4>| REC[0x800ac470]: Sent Packet[1] Alert(21) in epoch 0 and length: 7 |<2>| ASSERT: /cygdrive/d/misc/src/release/gnutls-3.1.4-1/src/gnutls-3.1.4/lib/gnutls_record.c:240 |<4>| REC[0x800ac470]: Start of epoch cleanup |<4>| REC[0x800ac470]: End of epoch cleanup |<4>| REC[0x800ac470]: Epoch #0 freed |<4>| REC[0x800ac470]: Epoch #1 freed CLIENT: 12/17/13 13:52:20 GNUTLS V3.1.4 (Loglevel=10) 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Allocating epoch #0 12/17/13 13:52:20 SSOCK#1000[4]@127.0.0.1:5556: Connecting @:52175 12/17/13 13:52:20 TRACE: SSOCK#1000[4]@127.0.0.1:5556: Connection established 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Allocating epoch #1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_ARCFOUR_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_ARCFOUR_MD5 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_AES_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_AES_128_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_AES_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_AES_256_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_3DES_EDE_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: RSA_AES_128_GCM_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_AES_128_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_AES_256_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_RSA_AES_128_GCM_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_ARCFOUR_MD5 (00.18) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_AES_128_CBC_SHA1 (00.34) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_AES_128_CBC_SHA256 (00.6C) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_CAMELLIA_128_CBC_SHA1 (00.46) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_AES_256_CBC_SHA1 (00.3A) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_AES_256_CBC_SHA256 (00.6D) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_CAMELLIA_256_CBC_SHA1 (00.89) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_3DES_EDE_CBC_SHA1 (00.1B) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: Keeping ciphersuite: DH_ANON_AES_128_GCM_SHA256 (00.A6) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension STATUS REQUEST (5 bytes) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension SAFE RENEGOTIATION (1 bytes) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension SESSION TICKET (0 bytes) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension SUPPORTED ECC (12 bytes) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes) 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (4.1) RSA-SHA256 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (4.2) DSA-SHA256 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (4.3) ECDSA-SHA256 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (5.1) RSA-SHA384 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (5.3) ECDSA-SHA384 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (6.1) RSA-SHA512 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (6.3) ECDSA-SHA512 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (3.1) RSA-SHA224 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (3.2) DSA-SHA224 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (3.3) ECDSA-SHA224 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (2.1) RSA-SHA1 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (2.2) DSA-SHA1 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: sent signature algo (2.3) ECDSA-SHA1 12/17/13 13:52:20 GNUTLS3: EXT[0x80057958]: Sending extension SIGNATURE ALGORITHMS (28 bytes) 12/17/13 13:52:20 GNUTLS3: HSK[0x80057958]: CLIENT HELLO was queued [135 bytes] 12/17/13 13:52:20 GNUTLS7: HWRITE: enqueued [CLIENT HELLO] 135. Total 135 bytes. 12/17/13 13:52:20 GNUTLS7: HWRITE FLUSH: 135 bytes in buffer. 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Preparing Packet Handshake(22) with length: 135 12/17/13 13:52:20 GNUTLS9: ENC[0x80057958]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 12/17/13 13:52:20 GNUTLS7: WRITE: enqueued 140 bytes for 0x80015308. Total 140 bytes. 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Sent Packet[1] Handshake(22) in epoch 0 and length: 140 12/17/13 13:52:20 GNUTLS7: HWRITE: wrote 1 bytes, 0 bytes left. 12/17/13 13:52:20 GNUTLS7: WRITE FLUSH: 140 bytes in buffer. 12/17/13 13:52:20 GNUTLS7: WRITE: wrote 140 bytes, 0 bytes left. 12/17/13 13:52:20 GNUTLS7: READ: Got 5 bytes from 0x80015308 12/17/13 13:52:20 GNUTLS7: READ: read 5 bytes from 0x80015308 12/17/13 13:52:20 GNUTLS7: RB: Have 0 bytes into buffer. Adding 5 bytes. 12/17/13 13:52:20 GNUTLS7: RB: Requested 5 bytes 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: SSL 3.3 Alert packet received. Epoch 0, length: 2 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Expected Packet Handshake(22) 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Received Packet Alert(21) with length: 2 12/17/13 13:52:20 GNUTLS7: READ: Got 2 bytes from 0x80015308 12/17/13 13:52:20 GNUTLS7: READ: read 2 bytes from 0x80015308 12/17/13 13:52:20 GNUTLS7: RB: Have 5 bytes into buffer. Adding 2 bytes. 12/17/13 13:52:20 GNUTLS7: RB: Requested 7 bytes 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Decrypted Packet[0] Alert(21) with length: 2 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Alert[2|40] - Handshake failed - was received 12/17/13 13:52:20 ERROR: Failed SSL hello: Closed {error=-12,A TLS fatal alert has been received} 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Start of epoch cleanup 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: End of epoch cleanup 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Epoch #0 freed 12/17/13 13:52:20 GNUTLS4: REC[0x80057958]: Epoch #1 freed Thanks in advance for any help! Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Wed Dec 18 15:26:04 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Dec 2013 15:26:04 +0100 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> Message-ID: On Tue, Dec 17, 2013 at 8:01 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Hi All, > I'm new here in this list, and I have a question about GNUTLS > that I do not understand. > Per the documentation example, I'm creating a client session like this: > gnutls_credentials_set(session, GNUTLS_CRD_ANON, acred); > But I get the following error (wherever I tried to connect to, whether > real HTTP servers or gnutls-serv starter locally), from gnutls_handshake(): > error=-12,A TLS fatal alert has been received Hello, A gnutls server doesn't support anonymous authentication by default. You need to enable it using the priority string. For example you need to something like "NORMAL:+ANON-DH:+ANON-ECDH" to both client and server. In general there is no reason to use anonymous authentication. If you don't have a trusted CA you can use, it is better to use certificates and trust on first use [0]. [0]. http://www.gnutls.org/manual/gnutls.html#Verifying-a-certificate-using-trust-on-first-use-authentication regards, Nikos From lavr at ncbi.nlm.nih.gov Wed Dec 18 15:53:21 2013 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Wed, 18 Dec 2013 14:53:21 +0000 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> > A gnutls server doesn't support anonymous authentication by default. Thanks for responding! Documentation contradicts with what you're saying, however. And it must be the source of my confusion. Presumably, it needs to be revised (outdated?): --begin quote-- gnutls-serv Examples Running your own TLS server based on GnuTLS can be useful when debugging clients and/or GnuTLS itself. This section describes how to use gnutls-serv as a simple HTTPS server. The most basic server can be started as: gnutls-serv --http It will only support anonymous ciphersuites, which many TLS clients refuse to use. --end quote-- Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Wed Dec 18 16:50:03 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Dec 2013 16:50:03 +0100 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> Message-ID: On Wed, Dec 18, 2013 at 3:53 PM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: >> A gnutls server doesn't support anonymous authentication by default. > Thanks for responding! > Documentation contradicts with what you're saying, however. And it must be the > source of my confusion. Presumably, it needs to be revised (outdated?): > --begin quote-- > gnutls-serv Examples > Running your own TLS server based on GnuTLS can be useful when debugging clients and/or GnuTLS itself. This section describes how to use gnutls-serv as a simple HTTPS server. > The most basic server can be started as: > gnutls-serv --http > It will only support anonymous ciphersuites, which many TLS clients refuse to use. You got a point. That's very old behavior. I've updated the document to reflect the current behavior. regards, Nikos From lavr at ncbi.nlm.nih.gov Wed Dec 18 19:13:55 2013 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Wed, 18 Dec 2013 18:13:55 +0000 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C451E77@MLBXv04.nih.gov> >I've updated the document to reflect the current behavior. Thanks! These do not seem to be working any longer, either (from certtool template description): # Alternatively you may set concrete dates and time. The GNU date string # formats are accepted. See: # http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html #activation_date = "2004-02-29 16:21:42" #expiration_date = "2025-02-29 16:24:41" Anton Lavrentiev Contractor NIH/NLM/NCBI From nmav at gnutls.org Wed Dec 18 22:38:59 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Dec 2013 22:38:59 +0100 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D0C451E77@MLBXv04.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451E77@MLBXv04.nih.gov> Message-ID: <1387402739.1930.9.camel@aspire.lan> On Wed, 2013-12-18 at 18:13 +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > >I've updated the document to reflect the current behavior. > > Thanks! These do not seem to be working any longer, either (from > certtool template description): > > # Alternatively you may set concrete dates and time. The GNU date string > # formats are accepted. See: > # http://www.gnu.org/software/tar/manual/html_node/Date-input-formats.html > #activation_date = "2004-02-29 16:21:42" > #expiration_date = "2025-02-29 16:24:41" These were added on the latest released version (3.2.7), so it may be that you are not using that version. regards, Nikos From lavr at ncbi.nlm.nih.gov Wed Dec 18 23:53:36 2013 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Wed, 18 Dec 2013 22:53:36 +0000 Subject: [gnutls-help] Can't get ANON auth working per the documentation example In-Reply-To: <1387402739.1930.9.camel@aspire.lan> References: <5F8AAC04F9616747BC4CC0E803D5907D0C4519C2@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451DBC@MLBXv04.nih.gov> <5F8AAC04F9616747BC4CC0E803D5907D0C451E77@MLBXv04.nih.gov> <1387402739.1930.9.camel@aspire.lan> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C45358C@MLBXv04.nih.gov> > These were added on the latest released version (3.2.7), so it may be > that you are not using that version. I see, indeed I'm using certtool from 3.1.17 (because stock certtool from 3.1.4 installed with our CentOS distro did not work with --to-p12 -- could not load a private key file with only a single key in it, said "0 keys loaded")... Thanks again for your quick response and explanations! Anton Lavrentiev Contractor NIH/NLM/NCBI From hongyi.zhao at gmail.com Fri Dec 20 05:17:34 2013 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Fri, 20 Dec 2013 12:17:34 +0800 Subject: [gnutls-help] The issue when compiling gnutls-3.2.6. Message-ID: Hi all, I use Debian Wheezy, and downloading the gnutls-3.2.6 from here: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz When I compile it with make, I meet the following error: --------- CCLD psktool ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_crypt' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_update' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_nonce' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_set_nonce' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_digest' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_set_iv' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_digest' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20r12_crypt' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_update' collect2: error: ld returned 1 exit status make[4]: *** [psktool] Error 1 --------- Any hints? Thanks -- Hongyi Zhao Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Dec 20 19:46:21 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Dec 2013 19:46:21 +0100 Subject: [gnutls-help] gnutls 3.2.8 Message-ID: <1387565181.12920.2.camel@aspire.lan> Hello, I've just released gnutls 3.2.8. This release fixes bugs, adds optimizations and some few new features on next stable branch. * Version 3.2.8 (released 2013-12-20) ** libgnutls: Updated code for AES-NI. That prevents an uninitialized variable complaint from valgrind. ** libgnutls: Enforce a maximum size for DH primes. ** libgnutls: Added SSSE3 optimized SHA1, and SHA256, using Andy Polyakov's code. ** libgnutls: Added SSSE3 optimized AES using Mike Hamburg's code. ** libgnutls: It only links to librt if the required functions are not present in libc. This also prevents an indirect linking to libpthread. ** libgnutls: Fixed issue with gnulib strerror replacement by adding the strerror gnulib module. ** libgnutls: The time provided in the TLS random values is only precise on its first 3 bytes. That prevents leakage of the precise system time (at least on the client side when only few connections are done on a single server). ** certtool: The --verify option will use the system CAs if the load-ca-certificate option is not provided. ** configure: Added option --with-default-blacklist-file to allow specifying a certificate blacklist file. ** configure: Added --disable-non-suiteb-curves option. This option restricts the supported curves to SuiteB curves. ** API and ABI modifications: gnutls_record_check_corked: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Dec 20 19:47:42 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Dec 2013 19:47:42 +0100 Subject: [gnutls-help] gnutls 3.1.18 Message-ID: <1387565262.12920.4.camel@aspire.lan> Hello, I've just released gnutls 3.1.18. This is a bug fix release on the current stable branch. * Version 3.1.18 (released 2013-12-20) ** libgnutls: Updated code for AES-NI. That prevents an uninitialized variable complaint from valgrind. ** libgnutls: Enforce a maximum size for DH primes. ** configure: Added option --with-default-blacklist-file to allow specifying a certificate blacklist file. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sat Dec 21 12:37:14 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Dec 2013 12:37:14 +0100 Subject: [gnutls-help] gnutls 3.2.8 In-Reply-To: <1387565181.12920.2.camel@aspire.lan> References: <1387565181.12920.2.camel@aspire.lan> Message-ID: <1387625834.2690.7.camel@aspire.lan> On Fri, 2013-12-20 at 19:46 +0100, Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 3.2.8. This release fixes bugs, adds > optimizations and some few new features on next stable branch. Note, that I've realized that this release has issues with the assembly files in win32 and macosx systems. In these systems use gnutls 3.2.8.1. regards, Nikos From tzz at lifelogs.com Sat Dec 21 22:17:26 2013 From: tzz at lifelogs.com (Ted Zlatanov) Date: Sat, 21 Dec 2013 16:17:26 -0500 Subject: [gnutls-help] gnutls_dh_set_prime_bits question References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> Message-ID: <871u15dhuh.fsf@flea.lifelogs.com> On Tue, 09 Jul 2013 15:46:56 +0200 Nikos Mavrogiannopoulos wrote: NM> On 07/09/2013 03:13 PM, Ted Zlatanov wrote: NM> On 07/02/2013 08:31 PM, Ted Zlatanov wrote: >>>> I think negotiating the connection twice is unacceptable for >>>> performance. We have to find a way to do it in one attempt, even if the >>>> user has to configure something about the exceptional servers. Can we >>>> always try ECDHE and only do DHE if the user tells us so? >> NM> You can always disable DHE. That way ECDHE will be negotiated with RSA NM> as fallback. >> >> I'm sorry to keep asking, but I can't find this explicitly in the >> manual. Maybe I'm looking in the wrong places. From >> http://gnutls.org/manual/html_node/Priority-Strings.html I am guessing >> that: >> >> 1) Including ANON-ECDH enables ECDHE NM> No. Anon-ECDH is for anonymous authentication. ECDHE-RSA and ECDHE-ECDSA NM> are for certificate authentication and are already enabled by NORMAL. >> 2) !DHE-RSA:!DHE-DSS disables DHE (not sure if DHE-RSA should be enabled for us) NM> Correct. >> 3) NORMAL enables DHE and ECDHE NM> Yes. >> It would be very nice if the initial keywords' description in that >> documentation page actually showed what's enabled by each one, >> especially "NORMAL". NM> Indeed, this may be useful. I should update that at some time. NM> You can see that using gnutls-cli -l --priority xxx. >> I also can't tell how to set the DH minimum prime bits in a priority >> string, if that's possible at all. NM> The initial keyword of the string sets the acceptable security level, NM> which at some later point it is translated on the minimum size of the NM> prime. Currently normal sets the value GNUTLS_SEC_PARAM_VERY_WEAK, which NM> is 727 bits of a prime. SECURE128 and 256 increase that value. NM> The idea was to have some consistency in the security levels, but given NM> the security levels offered by real-world servers, that would take some NM> time to occur. >> I can write additions to the manual to explain any of the above if you >> think they are needed. NM> That would be really helpful. Hi Nikos, I was about to submit a patch against the manual based on this e-mail from July and wanted to quickly check if the answers to (1), (2), (3) have changed (since I know there have been some issues with EC since then). Ted From nmav at gnutls.org Sun Dec 22 09:05:12 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Dec 2013 09:05:12 +0100 Subject: [gnutls-help] gnutls_dh_set_prime_bits question In-Reply-To: <871u15dhuh.fsf@flea.lifelogs.com> References: <8761wulavz.fsf@lifelogs.com> <51D1EA5D.7070003@gnutls.org> <87txkehrun.fsf@lifelogs.com> <51D20131.5040705@fifthhorseman.net> <87mwq44xvw.fsf@lifelogs.com> <51D9A712.8070000@gnutls.org> <874nc3x4dk.fsf@lifelogs.com> <51DC1450.9070405@gnutls.org> <871u15dhuh.fsf@flea.lifelogs.com> Message-ID: <1387699512.3650.2.camel@aspire.lan> On Sat, 2013-12-21 at 16:17 -0500, Ted Zlatanov wrote: > On Tue, 09 Jul 2013 15:46:56 +0200 Nikos Mavrogiannopoulos wrote: > > NM> On 07/02/2013 08:31 PM, Ted Zlatanov wrote: > >>>> I think negotiating the connection twice is unacceptable for > >>>> performance. We have to find a way to do it in one attempt, even if the > >>>> user has to configure something about the exceptional servers. Can we > >>>> always try ECDHE and only do DHE if the user tells us so? > NM> You can always disable DHE. That way ECDHE will be negotiated with RSA > NM> as fallback. Hello, The above still holds. > >> I'm sorry to keep asking, but I can't find this explicitly in the > >> manual. Maybe I'm looking in the wrong places. From > >> http://gnutls.org/manual/html_node/Priority-Strings.html I am guessing > >> that: > >> 1) Including ANON-ECDH enables ECDHE > NM> No. Anon-ECDH is for anonymous authentication. ECDHE-RSA and ECDHE-ECDSA > NM> are for certificate authentication and are already enabled by NORMAL. > >> 2) !DHE-RSA:!DHE-DSS disables DHE (not sure if DHE-RSA should be enabled for us) > NM> Correct. > >> 3) NORMAL enables DHE and ECDHE > NM> Yes. Correct. > >> It would be very nice if the initial keywords' description in that > >> documentation page actually showed what's enabled by each one, > >> especially "NORMAL". > NM> Indeed, this may be useful. I should update that at some time. > NM> You can see that using gnutls-cli -l --priority xxx. Still there. > >> I also can't tell how to set the DH minimum prime bits in a priority > >> string, if that's possible at all. > NM> The initial keyword of the string sets the acceptable security level, > NM> which at some later point it is translated on the minimum size of the > NM> prime. Currently normal sets the value GNUTLS_SEC_PARAM_VERY_WEAK, which > NM> is 727 bits of a prime. SECURE128 and 256 increase that value. > NM> The idea was to have some consistency in the security levels, but given > NM> the security levels offered by real-world servers, that would take some > NM> time to occur. Still holds. > I was about to submit a patch against the manual based on this e-mail > from July and wanted to quickly check if the answers to (1), (2), (3) > have changed (since I know there have been some issues with EC since > then). What issues are you referring to? regards, Nikos From davidrogers at usf.edu Mon Dec 23 23:53:05 2013 From: davidrogers at usf.edu (Rogers, David) Date: Mon, 23 Dec 2013 17:53:05 -0500 Subject: [gnutls-help] Problem Using gnutls_openpgp_crt_verify_ring .. cdk_pk_check_sigs Message-ID: <6D9A2D35-69CA-41E1-BB8F-6F995B563A30@usf.edu> Hello! I'm trying to write server code to verify a client's OpenPGP key inside gnutls. The key exchange works fine, but the server's call to gnutls_openpgp_crt_verify_ring always returns CDK_KEY_NOSIGNER. (on GNUTLS_DEBUG_LEVEL=9) gnutls[9]: signature good: signer 03357392 keyid 03357392 gnutls[2]: ASSERT: keydb.c:866 gnutls[2]: ASSERT: keydb.c:1237 gnutls[9]: signature good: signer 262B259C keyid 03357392 gnutls[2]: status: 8 gnutls[2]: ASSERT: keydb.c:866 gnutls[2]: ASSERT: keydb.c:1237 gnutls[2]: PGP: key not found 03357392 gnutls_certificate_verification_status_print --> The certificate is NOT trusted. The certificate is not trusted. Could not find a signer of the certificate. gnutls_openpgp_crt_verify_ring(crt, keyring, flag, &status) attempts to verify all the signatures in the crt against the public keys listed in "keyring" It calls: lib/openpgp/pgpverify.c:68 : rc = cdk_pk_check_sigs(key->knode, keyring->db, &status); (lib/opencdk/sig-check.c:454) which steps through all CDK_PKT_SIGNATURE-s in the key packet, running rc = _cdk_pk_check_sig(keydb, key, node, &is_selfsig, &uid_name); on each. Those calls are the sources of the individual "GOOD" verification signatures above. I think the trouble is that it has some impossible requirements on the signers (line 509): verification must be ok AND the signature must not be a self-sig. But the self-sigs have to be good, or else the algo. fails. So, the self-sigs it adds to the "uid_list" make the final "uid_list_all_signed" check (on line 522) fail, resulting in CDK_KEY_NOSIGNER. For the algo to be correct, the self-sigs should not be added to the final list check. I'm not even sure what the uid_list check is for... FWIW, I would rather see a "int gnutls_openpgp_crt_verify_signer(gnutls_openpgp_crt_t key, gnutls_openpgp_crt_t signer, unsigned int *verify)" test that would take an gnutls_openpgp_crt_t 'cert' from the client and an gnutls_openpgp_crt_t 'signer' holding the signer's public key and check that 1) the client cert's self-signs are valid 2) the client cert has at least one valid signature from the provided 'signer' pubkey ~ David. (both client and server) #define KEYFILE "/Users/rogers/.gnupg/kubotan-key.asc" #define CERTFILE "/Users/rogers/.gnupg/kubotan.asc" #define RINGFILE "/Users/rogers/.gnupg/pubring.gpg" pub 2048R/262B259C 2013-12-20 uid David M. Rogers > sig 3 262B259C 2013-12-20 David M. Rogers > sub 2048R/E494F149 2013-12-20 sig 262B259C 2013-12-20 David M. Rogers > pub 2048R/03357392 2013-12-20 [expires: 2016-12-19] uid kubotan (MBPR Laptop) > sig 3 03357392 2013-12-20 kubotan (MBPR Laptop) > sig 262B259C 2013-12-20 David M. Rogers > -------------- next part -------------- An HTML attachment was scrubbed... URL: