gmane.network.gnutls.general

Re: How to correctly set Diffie Hellman prime bits?

Simon Josefsson — 2008-07-10T09:25:48

Try GnuTLS 2.5.2. /Simon

Re: Re: How to correctly set Diffie Hellman prime bits?

Lennart Koopmann — 2008-07-10T09:12:39

Hey Ludovic, thank you very much! Seems like this was fixed in GnuTLS 2.5.2? I installed it and everything works fine with 1024 DH bits :) Have a nice day! Best regards Lennart Koopmann Am Mittwoch, den 09.07.2008, 23:19 +0200 schrieb Ludovic Courtès:

Re: How to correctly set Diffie Hellman prime bits?

Ludovic Courtès — 2008-07-09T21:19:37

Hi, Lennart Koopmann scopeport.org> writes: The solution may be to apply this patch: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b32735e1e275c4a2dbf544c04cdf344181fea555 Thanks, Ludovic.

How to correctly set Diffie Hellman prime bits?

Lennart Koopmann — 2008-07-09T12:15:36

Hello again list, i am continuing experimenting with GNUTLS. I have written a client and a server that perform anonymous (ANON-DH) TLS negotiation. I successfully connected to a gnutls-serv --http --priority "NORMAL: +ANON-DH" instance. When i tried to connect to my own server (which is mostly an example from the documentation) i got the following error: So i manually set the Diffie Hellman prime bits in the server to 1024 and in the client to 1023 (gnutls_dh_set_prime_bits (session, DH_BITS)) - With no effect. Still the same error. I also tried to set the DH prime bits in the server to 2048. The server needed longer to start up after this change so i guess that took effect. I then set the DH prime bits in the client to 0 and in the server to 1024. Now i can connect: Output of server: Output of client: Notice the "Anonymous DH using prime of -50 bits". This is the output of gnutls_dh_get_prime_bits(session)). No change whereever i place the output in the source code or what i set DH_BITS to. I guess a DH prime of 8 bits will not provide strong encryption, right? ;) Could you please help me with that? So long Lennart

Re: GNUTLS ERROR: A TLS fatal alert has been received.

Lennart Koopmann — 2008-07-06T14:48:06

Thank you again, Nikos! :) The --priority "NORMAL:+ANON-DH" allows a connection with my anonymous test client! * connection from ::ffff:127.0.0.1, port 43292 - Anonymous Diffie-Hellman parameters - Using prime: 1032 bits - Secret key: 1023 bits - Peer's public key: 1024 bits - Version: TLS1.1 - Key Exchange: ANON-DH - Cipher: CAMELLIA-256-CBC - MAC: SHA1 - Compression: NULL Best regards Lennart Am Sonntag, den 06.07.2008, 12:02 +0300 schrieb Nikos Mavrogiannopoulos:

Re: GNUTLS ERROR: A TLS fatal alert has been received.

Nikos Mavrogiannopoulos — 2008-07-06T09:02:09

But probably what you need is to run gnutls-serv with the option --priority "NORMAL:+ANON-DH". To see other possibilities use the gnutls-serv -l. regards, Nikos

Re: GNUTLS ERROR: A TLS fatal alert has been received.

Nikos Mavrogiannopoulos — 2008-07-06T08:50:49

For debugging you can use the -d 4 (or higher) option to gnutls-serv and see with details what was the reason of failure. On your own program you can use gnutls_global_set_log_function and gnutls_global_set_log_level. regards, Nikos

GNUTLS ERROR: A TLS fatal alert has been received.

Lennart Koopmann — 2008-07-05T18:11:05

Hello everyone, i installed GNUTLS version 2.5.1 from hand because the one from the Fedora repository is too old. When i try to anonymous connect to a "gnutls-server --http" my client returns: *** Handshake failed GNUTLS ERROR: A TLS fatal alert has been received. The server says: Error in handshake Error: Could not negotiate a supported cipher suite. Could you please help me with that? I don't really know how to proceed now. I can upload the source code of my test program if you want. It's mostly a copy & paste from the documentation. (7.3.1 Simple Client Example with Anonymous Authentication) [lennart< at >sundaysister Debug]$ ldd GNUTLSTest [...] libgnutls.so.26 => /usr/lib/libgnutls.so.26 (0x00111000) [...] Thank you all! So long Lennart -- FSF Member #5673

Re: gnutls_priority_set_direct undefined

Nikos Mavrogiannopoulos — 2008-07-03T20:46:42

Hello, Note that the manual in the website is for the latest version of gnutls. Thus in order to use the examples there you should download the latest available version. So either you need to upgrade or install the -doc package of gnutls in your distribution and use the older documentation. regards, Nikos On Thu, Jul 3, 2008 at 7:05 PM, Lennart Koopmann scopeport.org> wrote: _______________________________________________ Help-gnutls mailing list Help-gnutls< at >gnu.org http://lists.gnu.org/mailman/listinfo/help-gnutls

gnutls_priority_set_direct undefined

Lennart Koopmann — 2008-07-03T16:05:10

Hello everyone, i am currently experimenting with the GNU TLS library. I started with the TLS anonymous test client from the documentation. When i try to compile (a slightly modified) version, i get an error message that tells me that gnutls_priority_set_direct was not defined. (The original message is in German and i am not sure about the translation) When i comment out the gnutls_priority_set_direct line the program compiles fine but i get an "GnuTLS internal error". I am connecting to the gnutls-serv on localhost. The problem existed before my modifications to the example. Could anybody please help me with that problem? GNU TLS 2.0.4 on Fedora Core 9 Thank you very much! So long Lennart Koopmann

Re: adding trusted CAs

Simon Josefsson — 2008-07-02T16:22:07

Yes, that is typically the simplest. The gnutls_certificate_set_x509_trust_file function will read multiple CAs from a file. Extracting them from a browser has been done: http://curl.haxx.se/docs/caextract.html I don't recommend shipping these CAs as "trusted" CAs without verifying them though. It is generally safest to ask users to install the CAs they trust manually. /Simon

Re: not permitted to talk to peer,certificate invalid: no specific reason:

Nikos Mavrogiannopoulos — 2008-06-26T07:41:46

You are right, there should be a check. I'll add it to the todo list in case someone is interested into implementing it. regards, Nikos

Re: problems building 2.4.0

Simon Josefsson — 2008-06-25T18:33:03

... Great, I'd rather wait until we have more critical things to fix before doing another 2.4.x release. Alas, yes. We don't know how to handle an abstract crypto-layer without bundling it with GnuTLS. Possibly we could create another project which is the crypto provider for all gnutls projects, and gnutls and opencdk could both use them separately. But it is a lot of work. /Simon

Re: problems building 2.4.0

David Reiser — 2008-06-25T15:51:31

On Jun 24, 2008, at 5:03 AM, Simon Josefsson wrote: Yes (though I patched Makefile.in instead). Thanks. My googling needs some work, I guess. Now that I have a fix, I can package it this way, so I'm not in a hurry for a new version. Is using an internal opencdk likely to continue? -- David Reiser dbreiser< at >gmail.com

Re: List of supported CipherSuite andCompressionMethod

Simon Josefsson — 2008-06-25T15:24:43

Hi. You can run 'gnutls-cli -l' to check what your particular library/tool can support, but if you want to check the source see: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gnutls_algorithms.c;hb=HEAD The array with all supported ciphersuites is cs_algorithms. Output from my 'gnutls-cli -l' is below. The compression API is pretty minimal (get names of compression modes, and to enable/disable whether to use it, etc). Looking over the APIs involved, I can say that these functions will continue to work the same for many years the very least. No changes in that area is planned that I know of. Finally, I don't recall any changes in this area as long as I have been involved. LZO compression was disabled in the last release, but it doesn't affect the API, and you probably don't want LZO anyway because it is non-standard. /Simon jas< at >mocca:~$ gnutls-cli -v gnutls-cli (GnuTLS) 2.4.0 jas< at >mocca:~$ gnutls-cli -l Cipher suites: TLS_ANON_DH_ARCFOUR_MD5 0x00, 0x18 SSL3.0 TLS_ANON_DH_3DES_EDE_CBC_SHA1 0x00, 0x1b SSL3.0 TLS_ANON_DH_AES_128_CBC_SHA1 0x00, 0x34 SSL3.0 TLS_ANON_DH_AES_256_CBC_SHA1 0x00, 0x3a SSL3.0 TLS_ANON_DH_CAMELLIA_128_CBC_SHA1 0x00, 0x46 TLS1.0 TLS_ANON_DH_CAMELLIA_256_CBC_SHA1 0x00, 0x89 TLS1.0 TLS_PSK_SHA_ARCFOUR_SHA1 0x00, 0x8a TLS1.0 TLS_PSK_SHA_3DES_EDE_CBC_SHA1 0x00, 0x8b TLS1.0 TLS_PSK_SHA_AES_128_CBC_SHA1 0x00, 0x8c TLS1.0 TLS_PSK_SHA_AES_256_CBC_SHA1 0x00, 0x8d TLS1.0 TLS_DHE_PSK_SHA_ARCFOUR_SHA1 0x00, 0x8e TLS1.0 TLS_DHE_PSK_SHA_3DES_EDE_CBC_SHA1 0x00, 0x8f TLS1.0 TLS_DHE_PSK_SHA_AES_128_CBC_SHA1 0x00, 0x90 TLS1.0 TLS_DHE_PSK_SHA_AES_256_CBC_SHA1 0x00, 0x91 TLS1.0 TLS_SRP_SHA_3DES_EDE_CBC_SHA1 0xc0, 0x1a TLS1.0 TLS_SRP_SHA_AES_128_CBC_SHA1 0xc0, 0x1d TLS1.0 TLS_SRP_SHA_AES_256_CBC_SHA1 0xc0, 0x20 TLS1.0 TLS_SRP_SHA_DSS_3DES_EDE_CBC_SHA1 0xc0, 0x1c TLS1.0 TLS_SRP_SHA_RSA_3DES_EDE_CBC_SHA1 0xc0, 0x1b TLS1.0 TLS_SRP_SHA_DSS_AES_128_CBC_SHA1 0xc0, 0x1f TLS1.0 TLS_SRP_SHA_RSA_AES_128_CBC_SHA1 0xc0, 0x1e TLS1.0 TLS_SRP_SHA_DSS_AES_256_CBC_SHA1 0xc0, 0x22 TLS1.0 TLS_SRP_SHA_RSA_AES_256_CBC_SHA1 0xc0, 0x21 TLS1.0 TLS_DHE_DSS_ARCFOUR_SHA1 0x00, 0x66 TLS1.0 TLS_DHE_DSS_3DES_EDE_CBC_SHA1 0x00, 0x13 SSL3.0 TLS_DHE_DSS_AES_128_CBC_SHA1 0x00, 0x32 SSL3.0 TLS_DHE_DSS_AES_256_CBC_SHA1 0x00, 0x38 SSL3.0 TLS_DHE_DSS_CAMELLIA_128_CBC_SHA1 0x00, 0x44 TLS1.0 TLS_DHE_DSS_CAMELLIA_256_CBC_SHA1 0x00, 0x87 TLS1.0 TLS_DHE_RSA_3DES_EDE_CBC_SHA1 0x00, 0x16 SSL3.0 TLS_DHE_RSA_AES_128_CBC_SHA1 0x00, 0x33 SSL3.0 TLS_DHE_RSA_AES_256_CBC_SHA1 0x00, 0x39 SSL3.0 TLS_DHE_RSA_CAMELLIA_128_CBC_SHA1 0x00, 0x45 TLS1.0 TLS_DHE_RSA_CAMELLIA_256_CBC_SHA1 0x00, 0x88 TLS1.0 TLS_RSA_NULL_MD5 0x00, 0x01 SSL3.0 TLS_RSA_EXPORT_ARCFOUR_40_MD5 0x00, 0x03 SSL3.0 TLS_RSA_ARCFOUR_SHA1 0x00, 0x05 SSL3.0 TLS_RSA_ARCFOUR_MD5 0x00, 0x04 SSL3.0 TLS_RSA_3DES_EDE_CBC_SHA1 0x00, 0x0a SSL3.0 TLS_RSA_AES_128_CBC_SHA1 0x00, 0x2f SSL3.0 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 TLS_RSA_CAMELLIA_128_CBC_SHA1 0x00, 0x41 TLS1.0 TLS_RSA_CAMELLIA_256_CBC_SHA1 0x00, 0x84 TLS1.0 Certificate types: X.509, OPENPGP Protocols: SSL3.0, TLS1.0, TLS1.1, TLS1.2 Ciphers: AES-256-CBC, AES-128-CBC, 3DES-CBC, DES-CBC, ARCFOUR-128, ARCFOUR-40, RC2-40, CAMELLIA-256-CBC, CAMELLIA-128-CBC, NULL MACs: SHA1, MD5, SHA256, SHA384, SHA512, MD2, RIPEMD160, NULL Key exchange algorithms: ANON-DH, RSA, RSA-EXPORT, DHE-RSA, DHE-DSS, SRP-DSS, SRP-RSA, SRP, PSK, DHE-PSK Compression: DEFLATE, NULL jas< at >mocca:~$

List of supported CipherSuite and CompressionMethod

Richard Hartmann — 2008-06-25T14:46:23

Hi all, I was wondering if there is a list of all CipherSuite[s] and CompressionMethod[s] supported by GNUTLS. At this point, I would prefer not to go through the code to get an answer, but if you guys would point me at a file name, I would gladly take that, as well :) Additionally, I am wondering if the compression API will likely change at some point as is the case with OpenSSL. Thanks, Richard

Re: problems building 2.4.0

Simon Josefsson — 2008-06-24T09:03:45

This seems to be the same problem as in: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2912 Does the patch in that thread solve the problem for you? Perhaps we should do a 2.4.1 with this fix, but it may be too early to do this now. /Simon

problems building 2.4.0

David Reiser — 2008-06-24T02:22:04

I'm trying to build GnuTLS 2.4.0 on a Mac -- OS X 10.5.3, gcc 4.0.1, most dependencies supplied with fink packages. I get: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -DLOCALEDIR=\"/sw/share/ locale\" -I../lgl -I../lgl -I../includes -I../includes -I./x509 -I../ libextra -I../lib/openpgp/ -I/sw/include -I./opencdk -I../lib/opencdk - I/sw/include -I/sw/include -I/sw/include -g -O2 -Wno-pointer-sign -c gnutls_openpgp.c -fno-common -DPIC -o .libs/gnutls_openpgp.o gnutls_openpgp.c: In function 'gnutls_openpgp_get_key': gnutls_openpgp.c:219: error: 'cdk_keydb_search_t' undeclared (first use in this function) gnutls_openpgp.c:219: error: (Each undeclared identifier is reported only once gnutls_openpgp.c:219: error: for each function it appears in.) gnutls_openpgp.c:219: error: syntax error before 'st' gnutls_openpgp.c:242: error: 'st' undeclared (first use in this function) gnutls_openpgp.c:242: warning: passing argument 2 of 'cdk_keydb_search_start' makes integer from pointer without a cast gnutls_openpgp.c:242: error: incompatible type for argument 3 of 'cdk_keydb_search_start' gnutls_openpgp.c:242: error: too many arguments to function 'cdk_keydb_search_start' gnutls_openpgp.c:244: warning: passing argument 2 of 'cdk_keydb_search' from incompatible pointer type gnutls_openpgp.c:244: error: too many arguments to function 'cdk_keydb_search' gnutls_openpgp.c:246: warning: implicit declaration of function 'cdk_keydb_search_release' make[3]: *** [gnutls_openpgp.lo] Error 1 Suggestions? Dave -- David Reiser dbreiser< at >gmail.com

Re: Re: gnutls_certificate_verify_peers2() /GNUTLS_CERT_INVALID

Rainer Gerhards — 2008-06-23T06:30:26

Hi Nikos, On Sun, Jun 22, 2008 at 12:52 PM, Nikos Mavrogiannopoulos gnutls.org> wrote: Could you elaborate on this? As far as I understood (what may be wrong) there is no inter-dependency between the DNs. Is there some that I have not seen? I am not even sure it is a bug. My initial question was what this may have caused. I am still trying to track down the actual problem cause, but the error message is so generic that I have no clue where I should look at. Everywhere I looked so far I could not find a problem. To make matters worse, certificates generated in some environments (e.g. Fedora 9) seem to work, while ones generated in others (Centos) do not. Certificates are generated according to this guide here (maybe you can spot an error): http://www.rsyslog.com/doc-tls_cert_ca.html http://www.rsyslog.com/doc-tls_cert_machine.html I hope that Nick can provide certificates he generates - in my environments, it always works (but I can't get Nick's certificates to work). I have seen logs of what he entered during the generation, and it looks exactly like what I did. Also, I do not see any differences in the certs he sent me (and they do not work for me, either). Again, I am not saying there is a bug in GnuTLS. Most probably I am doing something wrong. But I can not find a clue on what it may be... Thanks again, Rainer

Re: Re: gnutls_certificate_verify_peers2() /GNUTLS_CERT_INVALID

Nikos Mavrogiannopoulos — 2008-06-22T10:52:35

As far as I understand here the verification correctly does not succeed because some DN's do not match. If you still think it is a gnutls bug, please send a way for me to reproduce this problem (a chain of certificates that should verify, and the way to produce them). However I'd say to check if the certificate chain is correctly send etc. regards, Nikos

Re: Re: gnutls_certificate_verify_peers2() / GNUTLS_CERT_I

2008-06-20T17:47:36

Yassou Nikos, The Certificate Authority, the client, and the server reading the server are all using GNUTLS 2.3.11 and the CentOS version is 4.6 for all three as well. This problem is also happening on Ubuntu with GnuTLS 2.0.4 and 2.3.11. Any ideas you have are greatly appreciated. Fcaristo Poli! Nick