From simon at josefsson.org Tue Apr 1 12:32:00 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 01 Apr 2008 12:32:00 +0200 Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH In-Reply-To: (Maiku's message of "Mon, 31 Mar 2008 15:48:38 -0500") References: <874panyxvx.fsf@mocca.josefsson.org> <20080331130113.GA31656@manyfish.co.uk> Message-ID: <87zlsdkgrj.fsf@mocca.josefsson.org> Maiku writes: > I wanted to clarify a few things I think I missed in my original post. In > the line I posted, when this error happens: > > if (ret < 0 && gnutls_error_is_fatal (ret) == 0) > > ret is 0. In the _gnutls_io_read_buffered function, it returns on line 639 > in gnutls_buffers.c (according to 2.3.4) in this block: > > if (ret == 0) > { /* EOF */ > gnutls_assert (); > return 0; > } > > Also, the gnutls_error_is_fatal returns false (0) for values above zero, and > returns a non-fatal error (0 again) for zero. So to me it appeared that zero > was a case that wasn't being caught properly when checking for less than 0. > My thoughts were that if it was zero it should return as normal (without an > error), the client can then check and see if enough was read, read more if > it needs more, or handle the packet if it's done. This way it doesn't > terminate the session on a return of zero and the client can handle a recv > of zero and the client can handle it however it wishes. It's a sort of case > in itself, I don't believe that would be ignoring it. I believe again that the problem is that it makes it possible for an attacker to terminate a TLS session (just inject a TCP FIN). The TLS peers could not tell the difference between that and when one of the TLS peers terminated the session properly. SSLv2 was vulnerable to this attack. It is impossible to tell the difference between if an attacker injects TCP FIN or when the server is buggy and just tears down the TLS session without sending a close alert. I believe we need to assume the former. However, a specific error code to signal this situation seems like a good idea. Some applications may want to ignore this error condition. /Simon From cmaiku at gmail.com Tue Apr 1 21:23:11 2008 From: cmaiku at gmail.com (Maiku) Date: Tue, 1 Apr 2008 14:23:11 -0500 Subject: GNUTLS_E_UNEXPECTED_PACKET_LENGTH In-Reply-To: <87zlsdkgrj.fsf@mocca.josefsson.org> References: <874panyxvx.fsf@mocca.josefsson.org> <20080331130113.GA31656@manyfish.co.uk> <87zlsdkgrj.fsf@mocca.josefsson.org> Message-ID: Ah, I think I understand now. Yes, that does seem to be a better solution. Sorry for me taking so long to get that. Maiku -------------- next part -------------- An HTML attachment was scrubbed... URL: From l at lwithers.me.uk Wed Apr 2 20:15:36 2008 From: l at lwithers.me.uk (Laurence Withers) Date: Wed, 2 Apr 2008 18:15:36 +0000 Subject: GnuTLS leaks a file descriptor in _gnutls_psk_pwd_find_entry() Message-ID: <200804021815.36425.l@lwithers.me.uk> Hi, I've found that GnuTLS leaks a file descriptor in _gnutls_psk_pwd_find_entry() (from src/lib/auth_psk_pwd.c) . On line 175, we see a call to open a file: FILE* fd; /* ... */ fd = fopen (cred->password_file, "r"); However, there is no associated call to fclose. The attached patch, against version 2.2.2, adds a call to fclose() in each of the possible exit paths. I have tested it with the application in which I noticed the leak; the leak no longer occurs. The patch also applies cleanly against 2.3.4, although I did not perform a runtime test. Bye for now, -- Laurence Withers, -- jabber:l at jabber.lwithers.me.uk http://www.lwithers.me.uk/ tel:+447753988197 -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-2.2.2-fix-fd-leak.patch Type: text/x-diff Size: 444 bytes Desc: not available URL: From simon at josefsson.org Thu Apr 3 10:00:44 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 03 Apr 2008 10:00:44 +0200 Subject: GnuTLS leaks a file descriptor in _gnutls_psk_pwd_find_entry() In-Reply-To: <200804021815.36425.l@lwithers.me.uk> (Laurence Withers's message of "Wed, 2 Apr 2008 18:15:36 +0000") References: <200804021815.36425.l@lwithers.me.uk> Message-ID: <87lk3vnz9v.fsf@mocca.josefsson.org> Laurence Withers writes: > Hi, > > I've found that GnuTLS leaks a file descriptor in > _gnutls_psk_pwd_find_entry() (from src/lib/auth_psk_pwd.c) . On line > 175, we see a call to open a file: > > FILE* fd; > /* ... */ > fd = fopen (cred->password_file, "r"); > > However, there is no associated call to fclose. The attached patch, > against version 2.2.2, adds a call to fclose() in each of the possible > exit paths. > > I have tested it with the application in which I noticed the leak; the > leak no longer occurs. The patch also applies cleanly against 2.3.4, > although I did not perform a runtime test. Hi! Thanks for the report, I applied the patch both to gnutls_2_2_x and master. Thanks, /Simon > Bye for now, > -- > Laurence Withers, -- jabber:l at jabber.lwithers.me.uk > http://www.lwithers.me.uk/ tel:+447753988197 > > --- gnutls-2.2.2/lib/auth_psk_passwd.c.old 2008-04-02 18:00:52.000000000 +0000 > +++ gnutls-2.2.2/lib/auth_psk_passwd.c 2008-04-02 18:01:35.000000000 +0000 > @@ -195,11 +195,14 @@ > if (ret < 0) > { > gnutls_assert (); > + fclose (fd); > return GNUTLS_E_SRP_PWD_ERROR; > } > + fclose (fd); > return 0; > } > } > + fclose (fd); > > /* user was not found. Fake him. > * the last index found and randomize the entry. > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Thu Apr 3 21:29:38 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 03 Apr 2008 22:29:38 +0300 Subject: test?.gnutls.org are again up Message-ID: <47F53022.4000308@gnutls.org> The test servers: https://test1.gnutls.org https://test2.gnutls.org https://test3.gnutls.org are again up! [0] regards, Nikos [0]. In case you were wondering :) From simon at josefsson.org Mon Apr 7 11:05:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Apr 2008 11:05:37 +0200 Subject: pkcs12_encr In-Reply-To: <47F8BC5E.2000607@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 06 Apr 2008 15:04:46 +0300") References: <47F8BC5E.2000607@gnutls.org> Message-ID: <873apyqbku.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Hello Simon, > I noticed that pkcs12_encr.c doesn't use the gnutls functions for > hashing and mpi handling (i'm restricting the gcrypt set we use to > avoid having an external api that requires having libgcrypt). I've > updated it to use them but I wanted to be sure that it actually > behaves as you intended... The changes are attached... but is there > also a test that I can do to verify that it behaves as intended? Hi Nikos. I've looked at that code before too, to convert it to the gnutls functions, but never committed any patches. I couldn't find any test vectors that triggered that code. I think it would be quite good to have such test vectors before touching the code. I remember creating some PKCS#12 blobs and ran them through certtool, but for some reason I wasn't able to self-test this particular code. Or my patch to port it to the gnutls API never worked. Or I just forgot about the problem.. Could you try to create a PKCS#12 blob that triggers this code path? /Simon > > regards, > Nikos > diff --git a/lib/x509/pkcs12_encr.c b/lib/x509/pkcs12_encr.c > index edbec8b..b5bc122 100644 > --- a/lib/x509/pkcs12_encr.c > +++ b/lib/x509/pkcs12_encr.c > @@ -48,6 +48,15 @@ _pkcs12_check_pass (const char *pass, size_t plen) > return 0; > } > > +static void clear_highbit( mpi_t m, int bit) > +{ > +int highest = _gnutls_mpi_get_nbits(m); > +register int i; > + > + for (i=bit;i + _gnutls_mpi_clear_bit(m, i); > +} > + > /* ID should be: > * 3 for MAC > * 2 for IV > @@ -61,7 +70,7 @@ _pkcs12_string_to_key (unsigned int id, const opaque * salt, > { > int rc; > unsigned int i, j; > - gc_hash_handle md; > + digest_hd_st md; > mpi_t num_b1 = NULL; > unsigned int pwlen; > opaque hash[20], buf_b[64], buf_i[128], *p; > @@ -106,27 +115,35 @@ _pkcs12_string_to_key (unsigned int id, const opaque * salt, > > for (;;) > { > - rc = gc_hash_open (GC_SHA1, 0, &md); > - if (rc) > + rc = gnutls_hash_init (&md, GNUTLS_MAC_SHA1); > + if (rc < 0) > { > gnutls_assert (); > - return GNUTLS_E_DECRYPTION_FAILED; > + return rc; > } > for (i = 0; i < 64; i++) > { > unsigned char lid = id & 0xFF; > - gc_hash_write (md, 1, &lid); > + _gnutls_hash (&md, &lid, 1); > } > - gc_hash_write (md, pw ? 128 : 64, buf_i); > - memcpy (hash, gc_hash_read (md), 20); > - gc_hash_close (md); > + _gnutls_hash( &md, buf_i, pw ? 128 : 64); > + _gnutls_hash_deinit( &md, hash); > for (i = 1; i < iter; i++) > - gc_hash_buffer (GC_SHA1, hash, 20, hash); > + { > + rc = gnutls_hash_init (&md, GNUTLS_MAC_SHA1); > + if (rc < 0) > + { > + gnutls_assert(); > + return rc; > + } > + _gnutls_hash( &md, hash, 20); > + _gnutls_hash_deinit( &md, hash); > + } > for (i = 0; i < 20 && cur_keylen < req_keylen; i++) > keybuf[cur_keylen++] = hash[i]; > if (cur_keylen == req_keylen) > { > - gcry_mpi_release (num_b1); > + _gnutls_mpi_release (&num_b1); > return 0; /* ready */ > } > > @@ -140,7 +157,7 @@ _pkcs12_string_to_key (unsigned int id, const opaque * salt, > gnutls_assert (); > return rc; > } > - gcry_mpi_add_ui (num_b1, num_b1, 1); > + _gnutls_mpi_add_ui (num_b1, num_b1, 1); > for (i = 0; i < 128; i += 64) > { > mpi_t num_ij; > @@ -152,8 +169,8 @@ _pkcs12_string_to_key (unsigned int id, const opaque * salt, > gnutls_assert (); > return rc; > } > - gcry_mpi_add (num_ij, num_ij, num_b1); > - gcry_mpi_clear_highbit (num_ij, 64 * 8); > + _gnutls_mpi_add (num_ij, num_ij, num_b1); > + clear_highbit (num_ij, 64 * 8); > n = 64; > rc = _gnutls_mpi_print (buf_i + i, &n, num_ij); > if (rc < 0) > @@ -161,7 +178,7 @@ _pkcs12_string_to_key (unsigned int id, const opaque * salt, > gnutls_assert (); > return rc; > } > - gcry_mpi_release (num_ij); > + _gnutls_mpi_release (&num_ij); > } > } > } From ludo at gnu.org Tue Apr 8 23:19:19 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 08 Apr 2008 23:19:19 +0200 Subject: OpenCDK, temporary files and $TMPDIR Message-ID: <87myo4m4dk.fsf@gnu.org> Hi, When building and testing GnuTLS on NixOS (http://nixos.org/) in a chroot, `tests/openpgp/keyring.c' fails. More precisely `gnutls_openpgp_keyring_import ()' returns `GNUTLS_E_FILE_ERROR'. The reason is that the chroot doesn't have a writable `/tmp', and `cdk_stream_tmp_from_mem ()' (called from `cdk_keydb_new_from_mem ()') tries to create a file with `tmpfile ()', which does not honor $TMPDIR ($TMPDIR is set to a writable temporary directory in the NixOS chroot). Two remarks: 1. Why the hell does it have to create a file when all it does is decode a keyring from memory? :-) 2. Too bad $TMPDIR is not honored. This can surely be fixed using `getenv' and Gnulib's `tempname' module. Thanks, Ludovic. From twoaday at gmx.net Wed Apr 9 16:59:46 2008 From: twoaday at gmx.net (Timo Schulz) Date: Wed, 09 Apr 2008 16:59:46 +0200 Subject: OpenCDK, temporary files and $TMPDIR In-Reply-To: <87myo4m4dk.fsf@gnu.org> References: <87myo4m4dk.fsf@gnu.org> Message-ID: <47FCD9E2.3040401@gmx.net> Ludovic Court?s schrieb: > Two remarks: > > 1. Why the hell does it have to create a file when all it does is > decode a keyring from memory? :-) The way I implemented filters for "I/O" buffers. Tempfiles are not required and the implementation could be changed to avoid them. The main problem is time. Timo From simon at josefsson.org Sun Apr 13 11:28:02 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Apr 2008 11:28:02 +0200 Subject: GnuTLS 2.3.4.netconf.0 Message-ID: <878wziayu5.fsf@mocca.josefsson.org> I've created a branch 'gnutls_with_netconf' that will implement support for Netconf over TLS-PSK as per this IETF draft: . This is the first release from this branch, and it adds the PSK key derivation function and some PSK example code. What remains is to fix the GnuTLS PSK code to handle the 'psk_identity_hint' field, and to add a section to the manual. The goal is to merge this with the development branch eventually. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.netconf.0.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.4.netconf.0.tar.bz2 Happy hacking, Simon * Version 2.3.4.netconf.0 (released 2008-04-13) ** Support Netconf PSK key derivation. The function gnutls_psk_netconf_derive_key supports the PSK key derivation as specified in draft-ietf-netconf-tls-01.txt. New self test netconf-psk.c. ** New PSK example client and server. See doc/examples/ex-client-psk.c and doc/examples/ex-serv-psk.c. ** API and ABI modifications: gnutls_psk_netconf_derive_key: ADDED From simon at josefsson.org Sun Apr 13 11:42:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Apr 2008 11:42:27 +0200 Subject: openpgp api changes Message-ID: <87zlry9jlo.fsf@mocca.josefsson.org> Hi Nikos, I just noticed this commit: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=1eb501d0a85a742778e507ebfbb8f05a984559eb The gnutls_openpgp_crt_get_auth_subkey function was part of GnuTLS 2.2.x, so changing it will trigger a shared library bump, and I want to avoid that for 2.4.x. Can you see any other way to solve this than introducing a new parameter to the function? If that's not the case, please add a new function instead of changing one, perhaps as gnutls_openpgp_crt_get_auth_subkey2, which would takes the flag parameter, and make the old gnutls_openpgp_crt_get_auth_subkey function call that new function if possible. /Simon From simon at josefsson.org Sun Apr 13 11:58:27 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Apr 2008 11:58:27 +0200 Subject: releasing LGPL version of opencdk? In-Reply-To: <47E15DBE.20005@gmx.net> (Timo Schulz's message of "Wed, 19 Mar 2008 19:38:54 +0100") References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> Message-ID: <87od8e9iv0.fsf@mocca.josefsson.org> Timo Schulz writes: > Nikos Mavrogiannopoulos wrote: >> Simon Josefsson wrote: >> >>> Regarding naming, on second thought, I think it would be better to avoid >>> having 'gnutls' in the name of the LGPL package since it would be >>> confusing if any non-gnutls projects to link with it. >>> 'libopencdk-lite'? >> >> I also like the lite version better :) > > I've to agree, that the 'gnutls' part might confuse user. > So it's settled, we use the 'libopencdk-lite' name :-). It seems the savannah people do not like project names that contain 'open'... https://savannah.gnu.org/task/?7859 How do you feel about using 'freecdk'? This let us avoid the -lite suffix which is nice. Or 'minicdk'? /Simon From twoaday at gmx.net Sun Apr 13 13:15:29 2008 From: twoaday at gmx.net (Timo Schulz) Date: Sun, 13 Apr 2008 13:15:29 +0200 Subject: releasing LGPL version of opencdk? In-Reply-To: <87od8e9iv0.fsf@mocca.josefsson.org> References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> <87od8e9iv0.fsf@mocca.josefsson.org> Message-ID: <4801EB51.908@gmx.net> Simon Josefsson wrote: Hi, > It seems the savannah people do not like project names that contain > 'open'... > > https://savannah.gnu.org/task/?7859 > > How do you feel about using 'freecdk'? This let us avoid the -lite > suffix which is nice. Or 'minicdk'? my choice would be 'minicdk'. Timo From simon at josefsson.org Sun Apr 13 13:48:41 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Apr 2008 13:48:41 +0200 Subject: releasing LGPL version of opencdk? In-Reply-To: <4801EB51.908@gmx.net> (Timo Schulz's message of "Sun, 13 Apr 2008 13:15:29 +0200") References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> <87od8e9iv0.fsf@mocca.josefsson.org> <4801EB51.908@gmx.net> Message-ID: <87bq4e9dra.fsf@mocca.josefsson.org> Timo Schulz writes: > Simon Josefsson wrote: > > Hi, > >> It seems the savannah people do not like project names that contain >> 'open'... >> >> https://savannah.gnu.org/task/?7859 >> >> How do you feel about using 'freecdk'? This let us avoid the -lite >> suffix which is nice. Or 'minicdk'? > > my choice would be 'minicdk'. Ok, I've started a new project application: https://savannah.gnu.org/task/?7942 /Simon From simon at josefsson.org Sun Apr 13 14:33:37 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 13 Apr 2008 14:33:37 +0200 Subject: crypto engine In-Reply-To: <47F53307.3030002@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 03 Apr 2008 22:41:59 +0300") References: <47F53307.3030002@gnutls.org> Message-ID: <877if29boe.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > About the new crypto engine I think it should be included as is in the > new release. It is not tested but API-wise I don't expect changes. I > could add the mpi interface after the release in the development > branch. Ok, I looked over the API, and I think we need to do at least #1/#2 before we can release it: #1: I think that avoiding struct's in the public API would be a good idea (struct alignment always seem to cause problems on weirder platforms), so how about instead of doing something like this: typedef struct gnutls_crypto_rnd { int (*init)( void** ctx); int (*rnd) ( void* ctx, int /* gnutls_rnd_level_t */ level, void* data, int datasize); void (*deinit)( void* ctx); } gnutls_crypto_rnd_st; int gnutls_crypto_rnd_register( int priority, gnutls_crypto_rnd_st* s); do this instead: typedef int (*gnutls_rng_init_func)( void** ctx); typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize); typedef void (*gnutls_rng_deinit_func)( void* ctx); int gnutls_crypto_rnd_register( int priority, gnutls_rng_init_func init, gnutls_rng_rnd_func rnd, gnutls_rng_deinit_func deinit); Note use of gnutls_rnd_level_t as well. #2: Use 'size_t' for buffer length variables instead of 'int'. #3: Couldn't we align the GNUTLS_RND_* symbols to match the libgcrypt values? In other words, change the order and values of the symbols. Not important, but might simplify libgcrypt mapping... /Simon From nmav at gnutls.org Sun Apr 13 18:57:12 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Apr 2008 19:57:12 +0300 Subject: openpgp api changes In-Reply-To: <87zlry9jlo.fsf@mocca.josefsson.org> References: <87zlry9jlo.fsf@mocca.josefsson.org> Message-ID: <48023B68.6090405@gnutls.org> Simon Josefsson wrote: > Hi Nikos, I just noticed this commit: > > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=1eb501d0a85a742778e507ebfbb8f05a984559eb > > The gnutls_openpgp_crt_get_auth_subkey function was part of GnuTLS > 2.2.x, so changing it will trigger a shared library bump, and I want to > avoid that for 2.4.x. Are you sure it is in 2.2.x? This api is the part of the openpgp api that was introduced in the development branch. As far as I remember there is not subkey* function in 2.2.x. regards, Nikos From nmav at gnutls.org Sun Apr 13 19:01:10 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 13 Apr 2008 20:01:10 +0300 Subject: releasing LGPL version of opencdk? In-Reply-To: <87od8e9iv0.fsf@mocca.josefsson.org> References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> <87od8e9iv0.fsf@mocca.josefsson.org> Message-ID: <48023C56.2000303@gnutls.org> Simon Josefsson wrote: > Timo Schulz writes: > >> Nikos Mavrogiannopoulos wrote: >>> Simon Josefsson wrote: >>> >>>> Regarding naming, on second thought, I think it would be better to avoid >>>> having 'gnutls' in the name of the LGPL package since it would be >>>> confusing if any non-gnutls projects to link with it. >>>> 'libopencdk-lite'? >>> I also like the lite version better :) >> I've to agree, that the 'gnutls' part might confuse user. >> So it's settled, we use the 'libopencdk-lite' name :-). > > It seems the savannah people do not like project names that contain > 'open'... > > https://savannah.gnu.org/task/?7859 > > How do you feel about using 'freecdk'? This let us avoid the -lite > suffix which is nice. Or 'minicdk'? We also have another problem I found during my migration to generic crypto functions. Since opencdk does crypto by itself it has (at least the included version) to call the gnutls API generic functions also, otherwise it will not be possible to completely offer a version compiled with another crypto library. For this reason I'd suggest to consider making it (the tiny part) a part of gnutls. The generic API to use would be the exported gnutls _openpgp_ API. What do you think of this? regards, Nikos From nmav at gnutls.org Mon Apr 14 06:11:15 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Apr 2008 07:11:15 +0300 Subject: crypto engine In-Reply-To: <877if29boe.fsf@mocca.josefsson.org> References: <47F53307.3030002@gnutls.org> <877if29boe.fsf@mocca.josefsson.org> Message-ID: <4802D963.8090009@gnutls.org> Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > >> About the new crypto engine I think it should be included as is in the >> new release. It is not tested but API-wise I don't expect changes. I >> could add the mpi interface after the release in the development >> branch. > > Ok, I looked over the API, and I think we need to do at least #1/#2 > before we can release it: I'm still working on it so let's disable it for the release. I'll put today an #if 0 on this code. > #1: > > I think that avoiding struct's in the public API would be a good idea > (struct alignment always seem to cause problems on weirder platforms), > so how about instead of doing something like this: > do this instead: > > typedef int (*gnutls_rng_init_func)( void** ctx); > typedef int (*gnutls_rng_rnd_func) ( void* ctx, gnutls_rnd_level_t level, void* data, int datasize); > typedef void (*gnutls_rng_deinit_func)( void* ctx); Although not using structures is better for the API, the whole crypto.c will be inconsistent with some functions taking pointers to structures as arguments and others functions. I don't like the idea so much. > #2: > > Use 'size_t' for buffer length variables instead of 'int'. I'll do this. > #3: > Couldn't we align the GNUTLS_RND_* symbols to match the libgcrypt > values? In other words, change the order and values of the symbols. > Not important, but might simplify libgcrypt mapping... Also. regards, Nikos From simon at josefsson.org Mon Apr 14 12:40:17 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Apr 2008 12:40:17 +0200 Subject: openpgp api changes In-Reply-To: <48023B68.6090405@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 13 Apr 2008 19:57:12 +0300") References: <87zlry9jlo.fsf@mocca.josefsson.org> <48023B68.6090405@gnutls.org> Message-ID: <87ve2kk9da.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> Hi Nikos, I just noticed this commit: >> >> http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=1eb501d0a85a742778e507ebfbb8f05a984559eb >> >> The gnutls_openpgp_crt_get_auth_subkey function was part of GnuTLS >> 2.2.x, so changing it will trigger a shared library bump, and I want to >> avoid that for 2.4.x. > > Are you sure it is in 2.2.x? This api is the part of the openpgp api > that was introduced in the development branch. As far as I remember > there is not subkey* function in 2.2.x. Oops! You are right, for some reason I had checked out master in my gnutls-2.2 directory... I'll document the API change in NEWS and see if we can do another 2.3.x release now. Sorry, Simon From simon at josefsson.org Mon Apr 14 15:26:34 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Apr 2008 15:26:34 +0200 Subject: GnuTLS 2.3.5 Message-ID: <87abjwin3p.fsf@mocca.josefsson.org> The GnuTLS 2.3.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. My next step is to release a minicdk, then make a gnutls 2.3.x release that use it, then branch off gnutls_2_4_x and go for a new stable GnuTLS release in a few weeks. I tried to make sure there are no ABI/ABI modifications/deletions in this compared to v2.2.x, but as the changes have been quite large, I may have missed something. Note that we don't guarantee ABI compatibility during development releases, so if there are ABI breaks in this release, we'll consider those bugs and revert them, rather than bumping the ABI. The goals for the 2.3.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4 More ideas are welcome, just create a new ticket. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.5.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.5.tar.bz2 Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. News in this release: * Version 2.3.5 (released 2008-04-14) ** Build fix for MinGW and --disable-shared. Reported by Massimo Gaspari in . ** Document how to generate CRLs. Suggested by "Rainer Gerhards" . ** Documented the --priority option to gnutls-cli and gnutls-serv. ** Several minor fixes in the OpenPGP interface. Thanks to Daniel Kahn Gillmor. ** Fix fopen file descriptor leak in PSK server code. Thanks to Laurence Withers , see . ** Translations files not stored directly in git to avoid merge conflicts. ** New APIs to let applications replace the RNG used. Update all RNG callers in the code to use the new interface. ** Guile code now built with -fgnu89-inline to fix inline semantic problem. ** Update gnulib files. ** API and ABI modifications: gnutls_crypto_rnd_register: ADDED gnutls_rnd_level_t: ADDED GNUTLS_RND_KEY: ADDED, gnutls_rnd_level_t member GNUTLS_RND_RANDOM: ADDED, gnutls_rnd_level_t member GNUTLS_RND_NONCE: ADDED, gnutls_rnd_level_t member gnutls_crypto_rnd_st: ADDED GNUTLS_DIG_SHA224: ADDED GNUTLS_SIGN_RSA_SHA224: ADDED gnutls_openpgp_crt_get_auth_subkey: MODIFIED /Simon From simon at josefsson.org Tue Apr 15 07:06:12 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 15 Apr 2008 07:06:12 +0200 Subject: releasing LGPL version of opencdk? In-Reply-To: <48023C56.2000303@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 13 Apr 2008 20:01:10 +0300") References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> <87od8e9iv0.fsf@mocca.josefsson.org> <48023C56.2000303@gnutls.org> Message-ID: <87d4orvha3.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > We also have another problem I found during my migration to generic > crypto functions. Since opencdk does crypto by itself it has (at least > the included version) to call the gnutls API generic functions also, > otherwise it will not be possible to completely offer a version > compiled with another crypto library. Ouch... you are right. > For this reason I'd suggest to consider making it (the tiny part) a > part of gnutls. The generic API to use would be the exported gnutls > _openpgp_ API. What do you think of this? That is unfortunate because it would lead to having no LGPL openpgp library available for other applications... except for the gnutls API, though, of course. How useful is that for a non-tls application? However, this suggestion would save me cycles maintaining minicdk (time I really don't have), so I think we should do this. By integrating the opencdk code more closely we can also remove some duplicate stuff (like base64), remove some then unnecessary stuff (e.g. cdk_check_version), and use more gnulib modules. /Simon From simon at josefsson.org Wed Apr 16 15:11:57 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 16 Apr 2008 15:11:57 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem In-Reply-To: <480517D5.1000704@enterprise.bidmc.harvard.edu> (Kris Karas's message of "Tue, 15 Apr 2008 17:02:13 -0400") References: <480517D5.1000704@enterprise.bidmc.harvard.edu> Message-ID: <87y77e7xlu.fsf@mocca.josefsson.org> Kris Karas writes: > Hi Simon, > > Just wanted to report a build problem with the newest GnuTLS 2.3.5. > When in concert with gcc-3.4 (as found on, for example, Slackware 11) > the build bombs out as evidenced here: > > Making all in src > make[3]: Entering directory `/var/tmp/slackbuild/gnutls/gnutls-2.3.5/guile/src' > /usr/bin/guile-snarf -o core.x core.c -DHAVE_CONFIG_H -I../../includes -I../../includes -I../.. -I. -g -O2 -pipe -Wno-strict-prototypes -fgnu89-inline -pthread > cc1: error: unrecognized command line option "-fgnu89-inline" > make[3]: *** [core.x] Error 1 > make[3]: Leaving directory `/var/tmp/slackbuild/gnutls/gnutls-2.3.5/guile/src' > > make: *** [all] Error 2 > > > The build works just fine with gcc-4.x.x Hi! Thanks for the report. I think our configure.in needs to test whether -fgnu89-inline is available before using it. I'll try to fix this. /Simon From simon at josefsson.org Wed Apr 16 15:12:36 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 16 Apr 2008 15:12:36 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem In-Reply-To: <48051B5B.1040005@enterprise.bidmc.harvard.edu> (Kris Karas's message of "Tue, 15 Apr 2008 17:17:15 -0400") References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <48051B5B.1040005@enterprise.bidmc.harvard.edu> Message-ID: <87skxm7xkr.fsf@mocca.josefsson.org> Kris Karas writes: > Oops - spoke too soon. It appears that gcc-4.1.2 also bombs, but > gcc-4.2.3 is OK. Right, only the very latest gcc have this flag. /Simon > Kris Karas wrote: >> Hi Simon, >> >> Just wanted to report a build problem with the newest GnuTLS 2.3.5. >> When in concert with gcc-3.4 (as found on, for example, Slackware >> 11) the build bombs out as evidenced here: >> >> Making all in src >> make[3]: Entering directory >> /var/tmp/slackbuild/gnutls/gnutls-2.3.5/guile/src' >> /usr/bin/guile-snarf -o core.x core.c -DHAVE_CONFIG_H >> -I../../includes -I../../includes -I../.. -I. -g -O2 -pipe >> -Wno-strict-prototypes -fgnu89-inline -pthread >> cc1: error: unrecognized command line option "-fgnu89-inline" >> make[3]: *** [core.x] Error 1 >> make[3]: Leaving directory >> /var/tmp/slackbuild/gnutls/gnutls-2.3.5/guile/src' >> >> make: *** [all] Error 2 >> >> >> The build works just fine with gcc-4.x.x >> >> Cheers, >> Kris >> From ludo at gnu.org Wed Apr 16 17:10:18 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Wed, 16 Apr 2008 17:10:18 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <87y77e7xlu.fsf@mocca.josefsson.org> Message-ID: <87iqyhzvhh.fsf@gnu.org> Hi, Simon Josefsson writes: > Hi! Thanks for the report. I think our configure.in needs to test > whether -fgnu89-inline is available before using it. I'll try to fix > this. Normally, it's already tested: AC_MSG_CHECKING([whether gcc supports -fgnu89-inline]) _gcc_cflags_save="$CFLAGS" CFLAGS="${CFLAGS} -fgnu89-inline" AC_COMPILE_IFELSE(AC_LANG_PROGRAM([]), _gcc_gnu89_inline=yes, _gcc_gnu89_inline=no) AC_MSG_RESULT($_gcc_gnu89_inline) AM_CONDITIONAL([HAVE_GCC_GNU89_INLINE_OPTION], [test "x$_gcc_gnu89_inline" = "xyes"]) CFLAGS=$_gcc_cflags_save; Kris: can you grep "whether gcc support -fgnu89-inline" in your `config.log'? It's supported starting from GCC 4.2. Thanks, Ludovic. From simon at josefsson.org Thu Apr 17 13:20:54 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Apr 2008 13:20:54 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem In-Reply-To: <87iqyhzvhh.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 16 Apr 2008 17:10:18 +0200") References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <87y77e7xlu.fsf@mocca.josefsson.org> <87iqyhzvhh.fsf@gnu.org> Message-ID: <87iqygohgp.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> Hi! Thanks for the report. I think our configure.in needs to test >> whether -fgnu89-inline is available before using it. I'll try to fix >> this. > > Normally, it's already tested: > > AC_MSG_CHECKING([whether gcc supports -fgnu89-inline]) > _gcc_cflags_save="$CFLAGS" > CFLAGS="${CFLAGS} -fgnu89-inline" > AC_COMPILE_IFELSE(AC_LANG_PROGRAM([]), > _gcc_gnu89_inline=yes, _gcc_gnu89_inline=no) > AC_MSG_RESULT($_gcc_gnu89_inline) > AM_CONDITIONAL([HAVE_GCC_GNU89_INLINE_OPTION], > [test "x$_gcc_gnu89_inline" = "xyes"]) > CFLAGS=$_gcc_cflags_save; > > Kris: can you grep "whether gcc support -fgnu89-inline" in your > `config.log'? > > It's supported starting from GCC 4.2. Hm, my configure.in doesn't have that code. Did you forget to push this? Or did you push it to another branch? Also, the Makefile.am uses the conditional HAVE_GCC. /Simon From simon at josefsson.org Thu Apr 17 13:25:18 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Apr 2008 13:25:18 +0200 Subject: releasing LGPL version of opencdk? In-Reply-To: <87d4orvha3.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 15 Apr 2008 07:06:12 +0200") References: <87zlt4cqzu.fsf@mocca.josefsson.org> <47D7AE54.4090706@gmx.net> <87k5jyx3u8.fsf@mocca.josefsson.org> <47E15B3E.8080005@gnutls.org> <47E15DBE.20005@gmx.net> <87od8e9iv0.fsf@mocca.josefsson.org> <48023C56.2000303@gnutls.org> <87d4orvha3.fsf@mocca.josefsson.org> Message-ID: <87ej94oh9d.fsf@mocca.josefsson.org> Simon Josefsson writes: >> For this reason I'd suggest to consider making it (the tiny part) a >> part of gnutls. The generic API to use would be the exported gnutls >> _openpgp_ API. What do you think of this? > > That is unfortunate because it would lead to having no LGPL openpgp > library available for other applications... except for the gnutls API, > though, of course. How useful is that for a non-tls application? > > However, this suggestion would save me cycles maintaining minicdk (time > I really don't have), so I think we should do this. By integrating the > opencdk code more closely we can also remove some duplicate stuff (like > base64), remove some then unnecessary stuff (e.g. cdk_check_version), > and use more gnulib modules. If we are going to release v2.4 soon, we should adopt this approach. It isn't the best thing to do -- that would be to release opencdk under lgpl separately, fix the crypto abstraction so that gnutls can hook into it (messy work!) and use that -- but it is the best we can unless someone puts time into this. If someone wants to maintain the lgpl-opencdk externally from gnutls in the future, that would be welcome, and we should link to it. So this decision doesn't mean we'll always have opencdk integrated. I'll remove some unnecessary code from our opencdk... /Simon From ludo at gnu.org Thu Apr 17 14:20:59 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 17 Apr 2008 14:20:59 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <87y77e7xlu.fsf@mocca.josefsson.org> <87iqyhzvhh.fsf@gnu.org> <87iqygohgp.fsf@mocca.josefsson.org> Message-ID: <87y77cad04.fsf@gnu.org> Hi, Simon Josefsson writes: > Hm, my configure.in doesn't have that code. Did you forget to push > this? Or did you push it to another branch? Also, the Makefile.am uses > the conditional HAVE_GCC. Stupid me, I had forgotten to push the patch... Here it is (in `master'): http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b70070b6b11327e7967c83ad77e9d35fa2db05a9 http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=d5b3b9c5b4cd118cb3229f3b64d8bda146bf7b1b Sorry about that! Ludovic. From simon at josefsson.org Thu Apr 17 14:37:22 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Apr 2008 14:37:22 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem In-Reply-To: <87y77cad04.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Thu, 17 Apr 2008 14:20:59 +0200") References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <87y77e7xlu.fsf@mocca.josefsson.org> <87iqyhzvhh.fsf@gnu.org> <87iqygohgp.fsf@mocca.josefsson.org> <87y77cad04.fsf@gnu.org> Message-ID: <878wzcd5dp.fsf@mocca.josefsson.org> ludo at gnu.org (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> Hm, my configure.in doesn't have that code. Did you forget to push >> this? Or did you push it to another branch? Also, the Makefile.am uses >> the conditional HAVE_GCC. > > Stupid me, I had forgotten to push the patch... Here it is (in > `master'): > > http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=b70070b6b11327e7967c83ad77e9d35fa2db05a9 > http://git.sv.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=d5b3b9c5b4cd118cb3229f3b64d8bda146bf7b1b > > Sorry about that! Thanks. In the future, try to avoid pushing merges, especially those with conflicts, as they make history rather hard to read. See: http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00118.html http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/11269 /Simon From ludo at gnu.org Thu Apr 17 14:56:35 2008 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Thu, 17 Apr 2008 14:56:35 +0200 Subject: GnuTLS 2.3.5 / GCC-3.4.x build problem References: <480517D5.1000704@enterprise.bidmc.harvard.edu> <87y77e7xlu.fsf@mocca.josefsson.org> <87iqyhzvhh.fsf@gnu.org> <87iqygohgp.fsf@mocca.josefsson.org> <87y77cad04.fsf@gnu.org> <878wzcd5dp.fsf@mocca.josefsson.org> Message-ID: <87lk3c63ng.fsf@gnu.org> Simon Josefsson writes: > In the future, try to avoid pushing merges, especially those with > conflicts, as they make history rather hard to read. See: > > http://lists.gnu.org/archive/html/bug-gnulib/2007-09/msg00118.html > http://permalink.gmane.org/gmane.comp.lib.gnulib.bugs/11269 Thanks for the hint! Ludovic. From simon at josefsson.org Thu Apr 17 15:06:14 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Apr 2008 15:06:14 +0200 Subject: GnuTLS 2.3.6 Message-ID: <87zlrsbph5.fsf@mocca.josefsson.org> The GnuTLS 2.3.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. We decided to avoid an external dependency on a stripped down opencdk library (minicdk aka opencdk-lite) because integrating that with the upcoming gnutls crypto backend seems like a rather complicated problem, and we don't really have maintenance cycles to take on another library. This decision allows us to move towards a v2.4.0 release soon(er). I tried to make sure there are no ABI/ABI modifications/deletions in this compared to v2.2.x, but as the changes have been quite large, I may have missed something. Note that we don't guarantee ABI compatibility during development releases. The goals for the 2.3.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4 More ideas are welcome, just create a new ticket. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.6.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.6.tar.bz2 Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. News in this release: * Version 2.3.6 (released 2008-04-17) ** Make gnutls_x509_crq_sign2 set certificate request version if not set. ** Improve documentation for gnutls_x509_crq_sign2. Based on report from "John Brooks" in . ** tests/pathlen: run diff without parameters to improve portability. Based on HPUX build hints in . ** Don't use %e specifier with strftime, it doesn't work under Windows. Reported by Massimo Gaspari in . ** Remove all uses of gnutls_alloca/gnutls_afree. Use normal gnutls_malloc instead. One reason is increased portability to Windows, the other is that several of the uses may be unsafe because the size of data allocated could be large. Reported by Massimo Gaspari in . ** Build Guile code with -fgnu89-inline only when supported. Reported by Kris Karas in . ** Several GTK-DOC related fixes. ** Clean up OpenCDK related code. GnuTLS now requires its internal OpenCDK code rather than the external GPL library OpenCDK. Unfortunately, we don't have resources to maintain an external library (help welcome). ** API and ABI modifications: No changes since last version. /Simon From simon at josefsson.org Mon Apr 21 12:56:35 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 21 Apr 2008 12:56:35 +0200 Subject: Libtasn1 1.4 Message-ID: <87k5irqxwc.fsf@mocca.josefsson.org> Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding and DER/BER decoding. Libtasn1 is used by GnuTLS to manipulate X.509 objects and by Shishi to handle Kerberos V5 packets. Version 1.4 (released 2008-04-21) - Update gnulib files. - Replace uses of alloca with malloc. Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join our help-gnutls mailing list, see: . Homepage: http://josefsson.org/libtasn1/ Manual in many formats: http://josefsson.org/gnutls/manual/libtasn1/ Here are the compressed sources (1.5MB): ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.4.tar.gz http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.4.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/libtasn1/libtasn1-1.4.tar.gz.sig http://josefsson.org/gnutls/releases/libtasn1/libtasn1-1.4.tar.gz.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2008-06-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: 2008-06-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: 684c9dc343b0155a074c2127ac8050f983528bc8 libtasn1-1.4.tar.gz 717d633b49d68b8ce884bb51129c93ae54bd6b020adb96c30e4bb750 libtasn1-1.4.tar.gz Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Apr 21 13:54:33 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 21 Apr 2008 13:54:33 +0200 Subject: GnuTLS 2.3.7 Message-ID: <87zlrnpgna.fsf@mocca.josefsson.org> The GnuTLS 2.3.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. We decided to avoid an external dependency on a stripped down opencdk library (minicdk aka opencdk-lite) because integrating that with the upcoming gnutls crypto backend seems like a rather complicated problem, and we don't really have maintenance cycles to take on another library. This decision allows us to move towards a v2.4.0 release soon(er). I tried to make sure there are no ABI/ABI modifications/deletions in this compared to v2.2.x, but as the changes have been quite large, I may have missed something. Note that we don't guarantee ABI compatibility during development releases. The goals for the 2.3.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4 More ideas are welcome, just create a new ticket. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.7.tar.bz2 Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. News in this release: * Version 2.3.7 (released 2008-04-21) ** opencdk now properly sets the key usage bits into openpgp keys. ** gnutls-cli: Fix crash on TLS handshake failures. Reported by "Marc F. Clemente" in Debian BTS #466477. This is similar to . ** certtool: with --generate-request and newly generated keys, print the key. ** Build fixes for MinGW. Missing rpl_fseeko symbol in lib/opencdk/. Better checks for linking with -lws2_32 when needed. Use ASCII only isprint() when printing X.509 certificate information, to avoid non-ASCII but printable characters. Thanks to Massimo Gaspari for reports. ** Update internal copy of libtasn1 to version 1.4. ** API and ABI modifications: No changes since last version. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From dkg-debian.org at fifthhorseman.net Mon Apr 21 17:30:57 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 21 Apr 2008 11:30:57 -0400 Subject: issues with OpenPGP certificate verification Message-ID: <87lk37rzri.fsf@squeak.fifthhorseman.net> Hey Folks-- I just opened a couple tickets concerning what appear to be serious problems with GnuTLS's OpenPGP certificate verification: * gnutls-cli continues connection when certificate User ID does not match hostname (even without --insecure): http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/31 This is equivalent to accepting a valid TLS certificate from https://evil.com/ even though the connection was made to https://good.com/ * gnutls will accept an unsigned UserID as a hostname match as long as some signed UserID exists: http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/32 This appears to be a problem with the way that the library offers information about the UserIDs in the OpenPGP certificates. Since each UserID in an OpenPGP cert can be signed by 0 or more keys (other than the primary key), there needs to be a way to check the validity of specific UserIDs, not just the certificate as a whole. As usual, if you want more details, just post to the tickets, and i'll provide whatever help i can. I'm excited to see the library offering OpenPGP features for TLS, but these problems are significant security concerns. i want to make sure that the first major implementation of this extension is secure! Thanks for all the work on this, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nmav at gnutls.org Mon Apr 21 20:34:35 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 21 Apr 2008 21:34:35 +0300 Subject: issues with OpenPGP certificate verification In-Reply-To: <87lk37rzri.fsf@squeak.fifthhorseman.net> References: <87lk37rzri.fsf@squeak.fifthhorseman.net> Message-ID: <480CDE3B.8000500@gnutls.org> Daniel Kahn Gillmor wrote: > Hey Folks-- > > I just opened a couple tickets concerning what appear to be serious > problems with GnuTLS's OpenPGP certificate verification: > > * gnutls-cli continues connection when certificate User ID does not > match hostname (even without --insecure): > > http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/31 > > This is equivalent to accepting a valid TLS certificate from > https://evil.com/ even though the connection was made to > https://good.com/ Currently gnutls-cli prints: # The hostname in the key does NOT match 'goodsite'. However it seems that gnutls-cli is not any more a debugging tool. So it is a valid request to fail if the hostname doesn't match. (This also doesn't happen in the X.509 certificate case)... Simon could there be any issue with this change and gnus that use it? > * gnutls will accept an unsigned UserID as a hostname match as long > as some signed UserID exists: > > http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/32 > > This appears to be a problem with the way that the library offers > information about the UserIDs in the OpenPGP certificates. Since > each UserID in an OpenPGP cert can be signed by 0 or more keys > (other than the primary key), there needs to be a way to check the > validity of specific UserIDs, not just the certificate as a whole. This is a current limitation of the API. If you have some suggestion on a verification function, I'd be glad to hear it. I'd be even more glad if you offered a patch for it, since it seems my time is quite limited lately. regards, Nikos From dkg-debian.org at fifthhorseman.net Mon Apr 21 21:13:44 2008 From: dkg-debian.org at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 21 Apr 2008 15:13:44 -0400 Subject: issues with OpenPGP certificate verification In-Reply-To: <480CDE3B.8000500@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon\, 21 Apr 2008 21\:34\:35 +0300") References: <87lk37rzri.fsf@squeak.fifthhorseman.net> <480CDE3B.8000500@gnutls.org> Message-ID: <87lk37dnrr.fsf@squeak.fifthhorseman.net> Thanks for the quick feedback, Nikos. On Mon 2008-04-21 14:34:35 -0400, Nikos Mavrogiannopoulos wrote: > Daniel Kahn Gillmor wrote: > >> http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/31 > > Currently gnutls-cli prints: > # The hostname in the key does NOT match 'goodsite'. yup. But without --insecure, the appropriate step would be to terminate the connection, or else you leave the client open to an unexpected MITM attack. > However it seems that gnutls-cli is not any more a debugging > tool. So it is a valid request to fail if the hostname doesn't > match. (This also doesn't happen in the X.509 certificate case)... Yikes! i hadn't tested the X.509 case, sorry. > Simon could there be any issue with this change and gnus that use > it? I'm a gnus user, and hadn't realized that such a spoof wouldn't be caught by gnutls-cli. I'd certainly prefer gnus to fail on a hostname/certificate mismatch. >> http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/32 > > This is a current limitation of the API. If you have some suggestion > on a verification function, I'd be glad to hear it. I'd be even more > glad if you offered a patch for it, since it seems my time is quite > limited lately. If only we could unlimit all our times! I'll do what i can. I'm going to propose a snippet of a .h file on the ticket, and if that seems acceptable to you, then i'll go ahead and try to implement it. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From ashishg2dec at gmail.com Wed Apr 23 11:19:20 2008 From: ashishg2dec at gmail.com (Ashish Gupta) Date: Wed, 23 Apr 2008 14:49:20 +0530 Subject: Size of Libgcrypt (and other libraries) and subsequent performance Message-ID: Hi, The size of the libraries (especially libgcrypt) claimed at http://www.gnu.org/software/gnutls/comparison.html is much lower than what is produced by default (note, the size claimed is 367kb whereas the defaule build for libgcrypt results in close of 1.2MB shared object). Can someone help in understanding how these binaries were created for the Debian and how can this much optimization be achieved? The default build of libgcrypt (1.2MB) is relatively comparable to the size of libcrypto (1.3MB) (used with openssl). Hence the effective load time of the (similar) programs using both these libraries yeilds better performance on openssl. The sample client timings as observed over itierations (taking into account TLB) gives: ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./gnutls/client Finished real 0m0.294s user 0m0.046s sys 0m0.092s ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./openssl/client FINISHED real 0m0.117s user 0m0.004s sys 0m0.004s The libraries linked in were as follows: ashish at ashish-desktop:~/Atemp/SSLExamples$ ldd ./gnutls/client linux-gate.so.1 => (0xffffe000) libgnutls.so.26 => /usr/local/lib/libgnutls.so.26 (0xb7e55000) libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7e35000) libgcrypt.so.11 => /usr/local/lib/libgcrypt.so.11 (0xb7dc5000) libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0xb7dc1000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c80000) libz.so.1 => /usr/lib/libz.so.1 (0xb7c6c000) /lib/ld-linux.so.2 (0xb7ef1000) ashish at ashish-desktop:~/Atemp/SSLExamples$ ldd ./openssl/client linux-gate.so.1 => (0xffffe000) libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7f61000) libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7e1f000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e1a000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cd9000) libz.so.1 => /usr/lib/libz.so.1 (0xb7cc5000) /lib/ld-linux.so.2 (0xb7fae000) The necessary programs are also attached. Both the programs simply connect to the same server over the internet and issue same queries. No certification check is done in either. In case I can provide more information on this please let me know. Regards, Ashish Gupta -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_client.c Type: text/x-csrc Size: 2395 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_client.c Type: text/x-csrc Size: 1370 bytes Desc: not available URL: From aspecialj at gmail.com Thu Apr 24 05:14:16 2008 From: aspecialj at gmail.com (John Brooks) Date: Wed, 23 Apr 2008 21:14:16 -0600 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: References: Message-ID: Obvious reply is to make sure that they're not built with -g (debug symbols) and to run `strip' on them (removes excess information such as debug symbols from the binaries without changing their execution). Optimization flags may also play a part (-Os to optimize for space, and -O1/2/3 may make the binary larger, but should make execution faster). It would also be interesting to profile both of those applications and see how long the operations take in comparison to eachother, rather than just a cold execution time. -- - John On Wed, Apr 23, 2008 at 3:19 AM, Ashish Gupta wrote: > Hi, > > The size of the libraries (especially libgcrypt) claimed at > http://www.gnu.org/software/gnutls/comparison.html is much lower than what > is produced by default (note, the size claimed is 367kb whereas the defaule > build for libgcrypt results in close of 1.2MB shared object). Can someone > help in understanding how these binaries were created for the Debian and how > can this much optimization be achieved? > > The default build of libgcrypt (1.2MB) is relatively comparable to the > size of libcrypto (1.3MB) (used with openssl). Hence the effective load time > of the (similar) programs using both these libraries yeilds better > performance on openssl. The sample client timings as observed over > itierations (taking into account TLB) gives: > > ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./gnutls/client > Finished > > real 0m0.294s > user 0m0.046s > sys 0m0.092s > ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./openssl/client > FINISHED > > real 0m0.117s > user 0m0.004s > sys 0m0.004s > > The libraries linked in were as follows: > > ashish at ashish-desktop:~/Atemp/SSLExamples$ ldd ./gnutls/client > linux-gate.so.1 => (0xffffe000) > libgnutls.so.26 => /usr/local/lib/libgnutls.so.26 (0xb7e55000) > libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7e35000) > libgcrypt.so.11 => /usr/local/lib/libgcrypt.so.11 (0xb7dc5000) > libgpg-error.so.0 => /usr/local/lib/libgpg-error.so.0 (0xb7dc1000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7c80000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7c6c000) > /lib/ld-linux.so.2 (0xb7ef1000) > ashish at ashish-desktop:~/Atemp/SSLExamples$ ldd ./openssl/client > linux-gate.so.1 => (0xffffe000) > libssl.so.0.9.8 => /usr/lib/i686/cmov/libssl.so.0.9.8 (0xb7f61000) > libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 > (0xb7e1f000) > libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e1a000) > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7cd9000) > libz.so.1 => /usr/lib/libz.so.1 (0xb7cc5000) > /lib/ld-linux.so.2 (0xb7fae000) > > The necessary programs are also attached. Both the programs simply connect > to the same server over the internet and issue same queries. No > certification check is done in either. > > In case I can provide more information on this please let me know. > > Regards, > Ashish Gupta > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Thu Apr 24 12:07:06 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Apr 2008 12:07:06 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: (Ashish Gupta's message of "Wed, 23 Apr 2008 14:49:20 +0530") References: Message-ID: <87abjj5zxx.fsf@mocca.josefsson.org> "Ashish Gupta" writes: > Hi, > > The size of the libraries (especially libgcrypt) claimed at > http://www.gnu.org/software/gnutls/comparison.html is much lower than what > is produced by default (note, the size claimed is 367kb whereas the defaule > build for libgcrypt results in close of 1.2MB shared object). Can someone > help in understanding how these binaries were created for the Debian and how > can this much optimization be achieved? Did you strip the library? Debian libraries are stripped. On my debian testing system, libgcrypt is now 421kb. I'm not sure why it is has grown so much. If you are short on size, you could disable some of the rarely used ciphers: whirlpool, twofish, serpent, seed, tiger. TLS never needs those algorithms. > The default build of libgcrypt (1.2MB) is relatively comparable to the size > of libcrypto (1.3MB) (used with openssl). Hence the effective load time of > the (similar) programs using both these libraries yeilds better performance > on openssl. I think your libgcrypt value should be ~420kb, otherwise you are comparing stripped libraries with unstripped libraries. > The sample client timings as observed over itierations (taking into > account TLB) gives: > > ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./gnutls/client > Finished > > real 0m0.294s > user 0m0.046s > sys 0m0.092s > ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./openssl/client > FINISHED > > real 0m0.117s > user 0m0.004s > sys 0m0.004s Thanks for providing these test cases! I'll see if I can reproduce your values, and if I can optimize anything. > The necessary programs are also attached. Both the programs simply connect > to the same server over the internet and issue same queries. No > certification check is done in either. > > In case I can provide more information on this please let me know. Connecting to a server over the internet seems somewhat unreliable, but if you run the tests many times and compare averages it may be OK. /Simon From simon at josefsson.org Thu Apr 24 12:30:33 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Apr 2008 12:30:33 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <87abjj5zxx.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 24 Apr 2008 12:07:06 +0200") References: <87abjj5zxx.fsf@mocca.josefsson.org> Message-ID: <8763u75yuu.fsf@mocca.josefsson.org> Simon Josefsson writes: >> ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./gnutls/client >> Finished >> >> real 0m0.294s >> user 0m0.046s >> sys 0m0.092s >> ashish at ashish-desktop:~/Atemp/SSLExamples$ time ./openssl/client >> FINISHED >> >> real 0m0.117s >> user 0m0.004s >> sys 0m0.004s > > Thanks for providing these test cases! I'll see if I can reproduce your > values, and if I can optimize anything. Running wireshark reveals that gnutls sends each of the handshake packets in separate TCP packets, but openssl combines them and sends them in one TCP packet. I'm not sure how much overhead this generates, but since network traffic is involved, it may be significant. Anyway, running callgrind on these binaries would be interesting... next step. /Simon From simon at josefsson.org Thu Apr 24 13:37:15 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Apr 2008 13:37:15 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <8763u75yuu.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 24 Apr 2008 12:30:33 +0200") References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> Message-ID: <87zlrj4h78.fsf@mocca.josefsson.org> Simon Josefsson writes: > Anyway, running callgrind on these binaries would be interesting... next > step. Which gave some interesting results. I don't know how to cut'n'paste from kcachegrind, but I'm attaching a gzip'ed callgrind.out in case anyone want to into more details. The top functions are: 97.25% main 26.60% transform (libgcrypt) 24.20% mix_pool (libgcrypt) 19.71% add_randomness (libgcrypt) 17.67% _gcry_rmd160_mixblock (libgcrypt) 15.47% do_fast_random_poll (libgcrypt) 14.24% asn1_find_node (libtasn1) 8.64% malloc 6.75% free 6.17% asn1_delete_structure (libtasn1) 6.11% strcmp 5.89% _gcry_randomize 5.54% _asn1_remove_node 5.38% _gcry_rmd160_hash_buffer 5.24% md_final 4.72% rmd160_write 4.55% _gcry_rndlinux_gather_random ... 3.80% gnutls_global_deinit 3.77% strdup 3.67% _gnutls_supported_ciphersuites_sorted 3.67 _gnutls_qsort ... Unsurprisingly, the randomness functions in libgcrypt take up most of the time. Libgcrypt's random function mixes the pool a few times, which explains the uses of hashing and in particular RIPE-MD-160. What's surprising is that libtasn1 takes 14% of the time to parse the certificate. However, I think we need more evidence to start optimizing that -- it is a one-time startup cost and wall time elapsed time is likely small. It is funny that the gnutls function that takes the most time is the global deinitialization function! The other gnutls functions are related to sorting the cipher suite during the handshake. It can probably be optimized a bit, but I'm not sure it is worth it. Improving the randomness stuff is likely to give much better return of investment. There seems to be plenty of evidence now that we should do something about that. The openssl kcachegrind output wasn't very readable since I'm using stripped libraries. /Simon From simon at josefsson.org Thu Apr 24 14:30:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Apr 2008 14:30:21 +0200 Subject: seg fault in crypto.h code Message-ID: <871w4vxwo2.fsf@mocca.josefsson.org> Hi Nikos, I tried to replace the internal rng using the new interfaces, but couldn't get it to work. This self-contained example trigger a segmentation fault. Could you look into this? I noticed that the code uses global variables for the hooks: static cipher_list glob_cl = { GNUTLS_CIPHER_NULL, 0, NULL, NULL }; static mac_list glob_ml = { GNUTLS_MAC_NULL, 0, NULL, NULL }; static digest_list glob_dl = { GNUTLS_MAC_NULL, 0, NULL, NULL }; static rnd_list glob_rnd = { 0, 0, NULL, NULL }; Is all code related to this thread safe? I would think that if you use global variables, you must call thread mutex hooks to avoid problems. /Simon #include #include #include #include #include #include #include #include #include #include #include /* A very basic TLS client, with X.509 authentication. */ #define MAX_BUF 1024 #define CAFILE \ "/etc/ssl/certs/Verisign_Class_3_Public_Primary_Certification_Authority.pem" #define MSG1 "GET / HTTP/1.1 \r\n Accept:*/* \r\n Host: mail.google.com \r\n Connection: Keep-Alive\r\n\r\n" #define SA struct sockaddr /* Connects to the peer and returns a socket * descriptor. */ extern int tcp_connect (void) { const char *PORT = "443"; const char *SERVER = "66.249.91.19"; int err, sd; struct sockaddr_in sa; /* connects to server */ sd = socket (AF_INET, SOCK_STREAM, 0); memset (&sa, '\0', sizeof (sa)); sa.sin_family = AF_INET; sa.sin_port = htons (atoi (PORT)); inet_pton (AF_INET, SERVER, &sa.sin_addr); err = connect (sd, (SA *) & sa, sizeof (sa)); if (err < 0) { fprintf (stderr, "Connect error\n"); exit (1); } return sd; } /* closes the given socket descriptor. */ extern void tcp_close (int sd) { shutdown (sd, SHUT_RDWR); /* no more receptions */ close (sd); } void mylogfn( int level, const char*ptr) { printf ("Got Logs: "); if (ptr) printf ("%s", ptr); } int rng_init( void** ctx) { return 0; } int rng_rnd ( void* ctx, int level, void* data, int datasize) { return 0; } void rng_deinit( void* ctx) { } int main (void) { int ret, sd, ii; gnutls_session_t session; char buffer[MAX_BUF + 1]; const char *err; gnutls_certificate_credentials_t xcred; gnutls_crypto_rnd_st rng = { rng_init, rng_rnd, rng_deinit }; gnutls_global_init (); ret = gnutls_crypto_rnd_register (0, &rng); printf ("ret %d\n", ret); /* X509 stuff */ gnutls_certificate_allocate_credentials (&xcred); /* Initialize TLS session */ gnutls_init (&session, GNUTLS_CLIENT); /* Use default priorities */ ret = gnutls_priority_set_direct (session, "NORMAL", &err); if (ret < 0) { if (ret == GNUTLS_E_INVALID_REQUEST) { fprintf(stderr, "Syntax error at: %s\n", err); } exit(1); } /* put the x509 credentials to the current session */ gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, xcred); /* connect to the peer */ sd = tcp_connect (); gnutls_transport_set_ptr (session, (gnutls_transport_ptr_t) sd); /* Perform the TLS handshake */ ret = gnutls_handshake (session); if (ret < 0) { fprintf (stderr, "*** Handshake failed\n"); gnutls_perror (ret); goto end; } gnutls_record_send (session, MSG1, strlen (MSG1)); ret = gnutls_record_recv (session, buffer, MAX_BUF); if (ret == 0) { printf ("- Peer has closed the TLS connection\n"); goto end; } else if (ret < 0) { fprintf (stderr, "*** Error: %s\n", gnutls_strerror (ret)); goto end; } /* for (ii = 0; ii < ret; ii++) { fputc (buffer[ii], stdout); } */ fputs ("Finished\n", stdout); gnutls_bye (session, GNUTLS_SHUT_RDWR); end: tcp_close (sd); gnutls_deinit (session); gnutls_global_deinit (); return 0; } From ashishg2dec at gmail.com Thu Apr 24 14:32:22 2008 From: ashishg2dec at gmail.com (Ashish Gupta) Date: Thu, 24 Apr 2008 18:02:22 +0530 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <87zlrj4h78.fsf@mocca.josefsson.org> References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> Message-ID: HI Simon, Thanks for the update. I am currently not in office, however will conduct more experiments once I am back. Meanwhile, the figures related to the run time overheads are most intriguing. Any comparisions on the way openssl handles its randoms? Regards, Ashish Gupta On 4/24/08, Simon Josefsson wrote: > > Simon Josefsson writes: > > > Anyway, running callgrind on these binaries would be interesting... next > > step. > > Which gave some interesting results. I don't know how to cut'n'paste > from kcachegrind, but I'm attaching a gzip'ed callgrind.out in case > anyone want to into more details. The top functions are: > > 97.25% main > 26.60% transform (libgcrypt) > 24.20% mix_pool (libgcrypt) > 19.71% add_randomness (libgcrypt) > 17.67% _gcry_rmd160_mixblock (libgcrypt) > 15.47% do_fast_random_poll (libgcrypt) > 14.24% asn1_find_node (libtasn1) > 8.64% malloc > 6.75% free > 6.17% asn1_delete_structure (libtasn1) > 6.11% strcmp > 5.89% _gcry_randomize > 5.54% _asn1_remove_node > 5.38% _gcry_rmd160_hash_buffer > 5.24% md_final > 4.72% rmd160_write > 4.55% _gcry_rndlinux_gather_random > ... > 3.80% gnutls_global_deinit > 3.77% strdup > 3.67% _gnutls_supported_ciphersuites_sorted > 3.67 _gnutls_qsort > ... > > Unsurprisingly, the randomness functions in libgcrypt take up most of > the time. Libgcrypt's random function mixes the pool a few times, which > explains the uses of hashing and in particular RIPE-MD-160. > > What's surprising is that libtasn1 takes 14% of the time to parse the > certificate. However, I think we need more evidence to start optimizing > that -- it is a one-time startup cost and wall time elapsed time is > likely small. > > It is funny that the gnutls function that takes the most time is the > global deinitialization function! > > The other gnutls functions are related to sorting the cipher suite > during the handshake. It can probably be optimized a bit, but I'm not > sure it is worth it. > > Improving the randomness stuff is likely to give much better return of > investment. There seems to be plenty of evidence now that we should do > something about that. > > The openssl kcachegrind output wasn't very readable since I'm using > stripped libraries. > > /Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Apr 25 09:45:29 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Apr 2008 09:45:29 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <87zlrj4h78.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 24 Apr 2008 13:37:15 +0200") References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> Message-ID: <87ej8ubco6.fsf@wheatstone.g10code.de> On Thu, 24 Apr 2008 13:37, simon at josefsson.org said: > Which gave some interesting results. I don't know how to cut'n'paste > from kcachegrind, but I'm attaching a gzip'ed callgrind.out in case > anyone want to into more details. The top functions are: > > 97.25% main > 26.60% transform (libgcrypt) > 24.20% mix_pool (libgcrypt) What version of libgcryt is that 1.4.0 or 1.4.1rc1 ? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Fri Apr 25 12:55:19 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 25 Apr 2008 12:55:19 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <87ej8ubco6.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 25 Apr 2008 09:45:29 +0200") References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> <87ej8ubco6.fsf@wheatstone.g10code.de> Message-ID: <87bq3ymcfc.fsf@mocca.josefsson.org> Werner Koch writes: > On Thu, 24 Apr 2008 13:37, simon at josefsson.org said: > >> Which gave some interesting results. I don't know how to cut'n'paste >> from kcachegrind, but I'm attaching a gzip'ed callgrind.out in case >> anyone want to into more details. The top functions are: >> >> 97.25% main >> 26.60% transform (libgcrypt) >> 24.20% mix_pool (libgcrypt) > > What version of libgcryt is that 1.4.0 or 1.4.1rc1 ? I added printing of gcrypt version to the client (see below), and it prints 1.4.1rc1. The simple client doesn't use a seeds file though. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_client.c Type: text/x-csrc Size: 3351 bytes Desc: not available URL: From simon at josefsson.org Fri Apr 25 13:10:34 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 25 Apr 2008 13:10:34 +0200 Subject: seg fault in crypto.h code In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 25 Apr 2008 11:09:09 +0300") References: <871w4vxwo2.fsf@mocca.josefsson.org> Message-ID: <877iemmbpx.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > should be fixed. Thanks. It doesn't segfault, but the new randomness provider isn't used, it still uses the internal gcrypt code. Could you try running this client? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_client.c Type: text/x-csrc Size: 3344 bytes Desc: not available URL: From simon at josefsson.org Fri Apr 25 13:18:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 25 Apr 2008 13:18:21 +0200 Subject: seg fault in crypto.h code In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 25 Apr 2008 09:28:40 +0300") References: <871w4vxwo2.fsf@mocca.josefsson.org> Message-ID: <873apambcy.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > I'll check it. This weekend I'll have some free time (btw. the mpi and > pk interface are also pretty much ready -no testing though). I'm beginning to think that we shouldn't push this into gnutls 2.4. I want to get v2.4 out in the next few weeks (it is already almost a month late). Adding the mpi/pk stuff, and having little or no testing of the overall crypto.h stuff, and no self-tests, and no plan to handle the multithread concerns, all seems likely to cause further delays. So, please, push your mpi/pk work to a separate branch. For the v2.4 release, reverting the crypto.h related code seems also likely to cause problems, so I think 'make install' simply shouldn't install crypto.h, and we should say that those APIs are off-limits (i.e., if we change the function prototypes for those functions, we won't bump the ABI version.) What do you think? Others? /Simon From simon at josefsson.org Fri Apr 25 16:59:34 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 25 Apr 2008 16:59:34 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: (Ashish Gupta's message of "Thu, 24 Apr 2008 18:02:22 +0530") References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> Message-ID: <87lk32yo89.fsf@mocca.josefsson.org> "Ashish Gupta" writes: > HI Simon, > > Thanks for the update. I am currently not in office, however will conduct > more experiments once I am back. > > Meanwhile, the figures related to the run time overheads are most > intriguing. Any comparisions on the way openssl handles its randoms? I don't have openssl libraries with debug symbols, but if you want to do the comparison for openssl that could help. If libgcrypt randomness code isn't improved, I think we should start thinking about adding our own PRNG and using it by default. Here is how I think it should work: 1. On initialization, read 32 bytes from /dev/urandom and seed a AES-based PRNG. 2. For the two lesser randomness levels, nonce + random, read data from the PNRG. 3. For the higher randomness level (e.g., for long-lived RSA keys), read bytes directly from /dev/random. Possibly XOR it against the /dev/urandom based PRNG output? As far as I recall, no part of a TLS handshake will require the strongest randomness level, so all typical GnuTLS applications will at most read 32 bytes from /dev/urandom. GnuTLS applications that generate long-lived keys (normally only 'certtool'?) will read data from /dev/random. The good thing is that we can experiment with how much performance improvement this would yield relatively easily, once the crypto.h rnd code works. Thoughts? /Simon From n.mavrogiannopoulos at gmail.com Sat Apr 26 12:18:53 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 26 Apr 2008 12:18:53 +0200 Subject: seg fault in crypto.h code In-Reply-To: <873apambcy.fsf@mocca.josefsson.org> References: <871w4vxwo2.fsf@mocca.josefsson.org> <873apambcy.fsf@mocca.josefsson.org> Message-ID: On Fri, Apr 25, 2008 at 1:18 PM, Simon Josefsson wrote: > "Nikos Mavrogiannopoulos" writes: > > > I'll check it. This weekend I'll have some free time (btw. the mpi and > > pk interface are also pretty much ready -no testing though). > I'm beginning to think that we shouldn't push this into gnutls 2.4. I > want to get v2.4 out in the next few weeks (it is already almost a month > late). Adding the mpi/pk stuff, and having little or no testing of the > overall crypto.h stuff, and no self-tests, and no plan to handle the > multithread concerns, all seems likely to cause further delays. And I also agree. Put the code in an #if 0 (also the header) before release. About the multithreaded issue, I don't believe it is an issue. The registration should happen once after global_init. It is not an api to call at any time during execution. > So, please, push your mpi/pk work to a separate branch. It is on a separate branch. regards, Nikos From simon at josefsson.org Mon Apr 28 12:34:38 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 12:34:38 +0200 Subject: seg fault in crypto.h code In-Reply-To: (Nikos Mavrogiannopoulos's message of "Sat, 26 Apr 2008 12:18:53 +0200") References: <871w4vxwo2.fsf@mocca.josefsson.org> <873apambcy.fsf@mocca.josefsson.org> Message-ID: <87prsai7y9.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Fri, Apr 25, 2008 at 1:18 PM, Simon Josefsson wrote: >> "Nikos Mavrogiannopoulos" writes: >> >> > I'll check it. This weekend I'll have some free time (btw. the mpi and >> > pk interface are also pretty much ready -no testing though). > >> I'm beginning to think that we shouldn't push this into gnutls 2.4. I >> want to get v2.4 out in the next few weeks (it is already almost a month >> late). Adding the mpi/pk stuff, and having little or no testing of the >> overall crypto.h stuff, and no self-tests, and no plan to handle the >> multithread concerns, all seems likely to cause further delays. > > And I also agree. Put the code in an #if 0 (also the header) before > release. I'll do this soon. > About the multithreaded issue, I don't believe it is an issue. The > registration should happen once after global_init. It is not an api to > call at any time during execution. The problem I see is that libgnutls could be used by libraries, and they may not be aware of each other. Consider: threaded application ---> library 1 -> register a crypto.h handler -> gnutls_global_init ---> library 2 -> register a crypto.h handler -> gnutls_global_init I'm not sure what the expected behaviour should be in this situation. Any crashes should be avoidable, of course, but it may be (too?) surprising for library 1 to not use the crypto.h functions it registered. This was my reason for doing a compile-time (rather than run-time) decision via the gnulib gc-* stuff, but alas that was never finished for pk/mpi. >> So, please, push your mpi/pk work to a separate branch. > > It is on a separate branch. Great. /Simon From ashishg2dec at gmail.com Mon Apr 28 13:49:23 2008 From: ashishg2dec at gmail.com (Ashish Gupta) Date: Mon, 28 Apr 2008 17:19:23 +0530 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: <87lk32yo89.fsf@mocca.josefsson.org> References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> <87lk32yo89.fsf@mocca.josefsson.org> Message-ID: Hi, Back again! Firstly, the gcrypt version I am using is 1.4.0. I did strip the required libraries to more manageable sizes ('tis now 621K for TLS and 443K for gcrypt). Thanks for the input. Surprisingly libcrypto.so (with openssl) is 1.3M stripped! (will check that later). Also, I ran the same program with openssl to see the results with kcachegrind. Attaching the corresponding callgrind.out for analysis. Not suprisingly, the following points turned up - 1. As mentioned before the random is the culprit on gcrypt. Just the "transform" function is called a whopping 56.96% of the times. Compared to what openssl does is calls SHA1_Update to mix its randoms, which is much faster. 2. asn1_find_node is taking only 1.55% of the time, in the tests I have run. Unsure why asn1_find_node is taking about 14% in the details sent before. 3. Openssl takes about 53% of time just to load its error strings. 4. Another difference is that Openssl invokes its PRNG "after" starting the handshake, whereas in TLS this is a part of gnutls_global_init. Unsure what is the reason for this in case of Openssl (for that matter, why is it part of global init in case of TLS) It would make sense to source it from /dev/urandom on linux, however unsure how the same will be done on windows!. Regards, Ashish On Fri, Apr 25, 2008 at 8:29 PM, Simon Josefsson wrote: > "Ashish Gupta" writes: > > > HI Simon, > > > > Thanks for the update. I am currently not in office, however will > conduct > > more experiments once I am back. > > > > Meanwhile, the figures related to the run time overheads are most > > intriguing. Any comparisions on the way openssl handles its randoms? > > I don't have openssl libraries with debug symbols, but if you want to do > the comparison for openssl that could help. > > If libgcrypt randomness code isn't improved, I think we should start > thinking about adding our own PRNG and using it by default. Here is how > I think it should work: > > 1. On initialization, read 32 bytes from /dev/urandom and seed a > AES-based PRNG. > > 2. For the two lesser randomness levels, nonce + random, read data from > the PNRG. > > 3. For the higher randomness level (e.g., for long-lived RSA keys), read > bytes directly from /dev/random. Possibly XOR it against the > /dev/urandom based PRNG output? > > As far as I recall, no part of a TLS handshake will require the > strongest randomness level, so all typical GnuTLS applications will at > most read 32 bytes from /dev/urandom. GnuTLS applications that generate > long-lived keys (normally only 'certtool'?) will read data from > /dev/random. > > The good thing is that we can experiment with how much performance > improvement this would yield relatively easily, once the crypto.h rnd > code works. > > Thoughts? > > /Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callgrind.out.24173.gz Type: application/x-gzip Size: 141532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callgrind.out.25616.gz Type: application/x-gzip Size: 46589 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Mon Apr 28 17:21:43 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 28 Apr 2008 18:21:43 +0300 Subject: seg fault in crypto.h code In-Reply-To: <87prsai7y9.fsf@mocca.josefsson.org> References: <871w4vxwo2.fsf@mocca.josefsson.org> <873apambcy.fsf@mocca.josefsson.org> <87prsai7y9.fsf@mocca.josefsson.org> Message-ID: <4815EB87.2070803@gmail.com> Simon Josefsson wrote: > The problem I see is that libgnutls could be used by libraries, and they > may not be aware of each other. Consider: > > threaded application > ---> library 1 > -> register a crypto.h handler > -> gnutls_global_init > ---> library 2 > -> register a crypto.h handler > -> gnutls_global_init > > I'm not sure what the expected behaviour should be in this situation. > Any crashes should be avoidable, of course, but it may be (too?) > surprising for library 1 to not use the crypto.h functions it > registered. Each one registering a handler, associates with a priority number. On execution time the one with lowest priority is run. In case of a conflict (priority number reuse or registering with higher priority than an existing handler) the registration will fail. > This was my reason for doing a compile-time (rather than run-time) > decision via the gnulib gc-* stuff, but alas that was never finished for > pk/mpi. The approach I followed in pk/mpi will allow for both compile time and runtime decision. Once finished I'll rewrite the logic in hash/cipher/rnd to be similar in mind. From simon at josefsson.org Mon Apr 28 18:31:34 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 18:31:34 +0200 Subject: Size of Libgcrypt (and other libraries) and subsequent performance In-Reply-To: (Ashish Gupta's message of "Mon, 28 Apr 2008 17:19:23 +0530") References: <87abjj5zxx.fsf@mocca.josefsson.org> <8763u75yuu.fsf@mocca.josefsson.org> <87zlrj4h78.fsf@mocca.josefsson.org> <87lk32yo89.fsf@mocca.josefsson.org> Message-ID: <87ej8q2b6h.fsf@mocca.josefsson.org> "Ashish Gupta" writes: > Hi, > > Back again! > > Firstly, the gcrypt version I am using is 1.4.0. I did strip the required > libraries to more manageable sizes ('tis now 621K for TLS and 443K for > gcrypt). Thanks for the input. Surprisingly libcrypto.so (with openssl) is > 1.3M stripped! (will check that later). Don't forget to count libssl.so as well, for OpenSSL. To be fair, OpenSSL implements much more than what GnuTLS does. On the other hand, you can view this as better modularization -- the things that GnuTLS doesn't implement is available from other libraries (libtasn1, libgcrypt, libksba, gnupg2, etc). > Also, I ran the same program with openssl to see the results with > kcachegrind. Attaching the corresponding callgrind.out for analysis. Thanks. > Not suprisingly, the following points turned up - > > > 1. As mentioned before the random is the culprit on gcrypt. Just the > "transform" function is called a whopping 56.96% of the times. Compared to > what openssl does is calls SHA1_Update to mix its randoms, which is much > faster. The reason is, as far as I understand, that libgcrypt initialize its randomness pool in a more pessimistic way than openssl, and thus requires much more hashes. > 2. asn1_find_node is taking only 1.55% of the time, in the tests I > have run. Unsure why asn1_find_node is taking about 14% in the details sent > before. Which libtasn1 version are you using? Maybe the alloca->malloc change I did recently had negative consequences... however, I'm not sure. Also, I'm not sure it is worth spending time on this -- loading certificates is only done once. > 3. Openssl takes about 53% of time just to load its error strings. Translated error strings? GnuTLS also has translated error strings, but maybe it loads them differently. > 4. Another difference is that Openssl invokes its PRNG "after" > starting the handshake, whereas in TLS this is a part of > gnutls_global_init. Unsure what is the reason for this in case of > Openssl (for that matter, why is it part of global init in case of > TLS) GnuTLS requests 1 random character during initialization, mostly to trigger any installation problem with libgcrypt early on rather than later during the handshake. The order when this is done isn't that important, IMHO, instead the time it takes is what is important. > It would make sense to source it from /dev/urandom on linux, however unsure > how the same will be done on windows!. The approach I mentioned would only be used under GNU/Linux. The /dev/*random devices on non-linux systems are sometimes known to be completely broken. On Windows, we could use its native PRNG interface, although that is known to have several problems. The simplest is to do what we do today, require libgcrypt. /Simon From simon at josefsson.org Mon Apr 28 18:33:41 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 18:33:41 +0200 Subject: seg fault in crypto.h code In-Reply-To: <4815EB87.2070803@gmail.com> (Nikos Mavrogiannopoulos's message of "Mon, 28 Apr 2008 18:21:43 +0300") References: <871w4vxwo2.fsf@mocca.josefsson.org> <873apambcy.fsf@mocca.josefsson.org> <87prsai7y9.fsf@mocca.josefsson.org> <4815EB87.2070803@gmail.com> Message-ID: <87abje2b2y.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: > >> The problem I see is that libgnutls could be used by libraries, and they >> may not be aware of each other. Consider: >> >> threaded application >> ---> library 1 >> -> register a crypto.h handler >> -> gnutls_global_init >> ---> library 2 >> -> register a crypto.h handler >> -> gnutls_global_init >> >> I'm not sure what the expected behaviour should be in this situation. >> Any crashes should be avoidable, of course, but it may be (too?) >> surprising for library 1 to not use the crypto.h functions it >> registered. > > Each one registering a handler, associates with a priority number. On > execution time the one with lowest priority is run. In case of a > conflict (priority number reuse or registering with higher priority than > an existing handler) the registration will fail. Ok. In any case, since these interfaces are optional, as long as we document the caveats properly, people could decide for themselves if they are safe to use for what they are using it for. I'm not sure many applications need to replace the crypto functions during run-time, but I could be wrong. >> This was my reason for doing a compile-time (rather than run-time) >> decision via the gnulib gc-* stuff, but alas that was never finished for >> pk/mpi. > > The approach I followed in pk/mpi will allow for both compile time and > runtime decision. Once finished I'll rewrite the logic in > hash/cipher/rnd to be similar in mind. Great! /Simon From simon at josefsson.org Mon Apr 28 20:01:45 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 20:01:45 +0200 Subject: issues with OpenPGP certificate verification In-Reply-To: <480CDE3B.8000500@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 21 Apr 2008 21:34:35 +0300") References: <87lk37rzri.fsf@squeak.fifthhorseman.net> <480CDE3B.8000500@gnutls.org> Message-ID: <871w4phn92.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Daniel Kahn Gillmor wrote: >> Hey Folks-- >> >> I just opened a couple tickets concerning what appear to be serious >> problems with GnuTLS's OpenPGP certificate verification: >> >> * gnutls-cli continues connection when certificate User ID does not >> match hostname (even without --insecure): >> >> http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/31 >> >> This is equivalent to accepting a valid TLS certificate from >> https://evil.com/ even though the connection was made to >> https://good.com/ > > Currently gnutls-cli prints: > # The hostname in the key does NOT match 'goodsite'. > > However it seems that gnutls-cli is not any more a debugging tool. So > it is a valid request to fail if the hostname doesn't match. (This > also doesn't happen in the X.509 certificate case)... Simon could > there be any issue with this change and gnus that use it? No, changing this would be good. If it causes failures for some people, it probably does that for a reason, and they should investigate it. /Simon From simon at josefsson.org Mon Apr 28 20:03:33 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 20:03:33 +0200 Subject: issues with OpenPGP certificate verification In-Reply-To: <87lk37rzri.fsf@squeak.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 21 Apr 2008 11:30:57 -0400") References: <87lk37rzri.fsf@squeak.fifthhorseman.net> Message-ID: <87wsmhg8lm.fsf@mocca.josefsson.org> Hi Daniel. Thanks for reporting this. I've modified them so that they must be fixed before v2.4. I haven't had time to look at them yet, but I hope Nikos and you will be able to come up with something that solves the problem. I'll revisit this when I get closer to the release. /Simon Daniel Kahn Gillmor writes: > Hey Folks-- > > I just opened a couple tickets concerning what appear to be serious > problems with GnuTLS's OpenPGP certificate verification: > > * gnutls-cli continues connection when certificate User ID does not > match hostname (even without --insecure): > > http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/31 > > This is equivalent to accepting a valid TLS certificate from > https://evil.com/ even though the connection was made to > https://good.com/ > > * gnutls will accept an unsigned UserID as a hostname match as long > as some signed UserID exists: > > http://trac.gnutls.org/cgi-bin/trac.cgi/ticket/32 > > This appears to be a problem with the way that the library offers > information about the UserIDs in the OpenPGP certificates. Since > each UserID in an OpenPGP cert can be signed by 0 or more keys > (other than the primary key), there needs to be a way to check the > validity of specific UserIDs, not just the certificate as a whole. > > As usual, if you want more details, just post to the tickets, and i'll > provide whatever help i can. > > I'm excited to see the library offering OpenPGP features for TLS, but > these problems are significant security concerns. i want to make sure > that the first major implementation of this extension is secure! > > Thanks for all the work on this, > > --dkg > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From simon at josefsson.org Mon Apr 28 20:17:18 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 28 Apr 2008 20:17:18 +0200 Subject: certtool --inraw/--outraw Message-ID: <87k5ihg7yp.fsf@mocca.josefsson.org> Nikos, regarding this patch: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=734f6dd83932f57fda56bb322e64f565ac30dc77 It replaces --inder/--outder with --inraw/--outraw in the certtool man page, but the code just add new --inraw/--outraw. What's the background here? We can't remove the --inder/--outder parameter now, they are too widely used and documented. Is this about openpgp stuff, which aren't DER encoded? /Simon From nmav at gnutls.org Mon Apr 28 21:36:49 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 28 Apr 2008 22:36:49 +0300 Subject: certtool --inraw/--outraw In-Reply-To: <87k5ihg7yp.fsf@mocca.josefsson.org> References: <87k5ihg7yp.fsf@mocca.josefsson.org> Message-ID: <48162751.4080503@gnutls.org> Simon Josefsson wrote: > Nikos, regarding this patch: > > http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=734f6dd83932f57fda56bb322e64f565ac30dc77 > > It replaces --inder/--outder with --inraw/--outraw in the certtool man > page, but the code just add new --inraw/--outraw. What's the background > here? We can't remove the --inder/--outder parameter now, they are too > widely used and documented. > Is this about openpgp stuff, which aren't DER encoded? I added --inraw, --outraw to have common options in openpgp and x.509 cases. The --inder and --outder options were left for compatibility, but removed from the manpage in favor of the new options. regards, Nikos From simon at josefsson.org Tue Apr 29 00:05:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Apr 2008 00:05:04 +0200 Subject: Handshake fails with Internal error in memory allocation Message-ID: <874p9ld4a7.fsf@mocca.josefsson.org> This error has come up lately, see: http://bugs.debian.org/466477 http://bugs.debian.org/478191 The cause seems clear, the server sends a huge list of CA certs and GnuTLS runs into some fixed size buffer or something. This reproduces it: gnutls-cli -p 25 -s mail3.mclemente.net ehlo foo starttls ^D Nikos, do you have any idea? I could look at it, but have little time right now. /Simon From nmav at gnutls.org Tue Apr 29 00:14:13 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 29 Apr 2008 01:14:13 +0300 Subject: Handshake fails with Internal error in memory allocation In-Reply-To: <874p9ld4a7.fsf@mocca.josefsson.org> References: <874p9ld4a7.fsf@mocca.josefsson.org> Message-ID: <48164C35.7020709@gnutls.org> Simon Josefsson wrote: > This error has come up lately, see: > > http://bugs.debian.org/466477 > http://bugs.debian.org/478191 > > The cause seems clear, the server sends a huge list of CA certs and > GnuTLS runs into some fixed size buffer or something. This reproduces > it: > > gnutls-cli -p 25 -s mail3.mclemente.net > ehlo foo > starttls > ^D > > Nikos, do you have any idea? I could look at it, but have little time > right now. There is this function that can be used to increase the default handshake packet size. The current is 16kb and is used to protect from denial of service. /** * gnutls_handshake_set_max_packet_length - set the maximum length of a handshake message * @session: is a #gnutls_session_t structure. * @max: is the maximum number. * * This function will set the maximum size of a handshake message. * Handshake messages over this size are rejected. The default value * is 16kb which is large enough. Set this to 0 if you do not want to * set an upper limit. * **/ From simon at josefsson.org Tue Apr 29 10:34:05 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Apr 2008 10:34:05 +0200 Subject: Handshake fails with Internal error in memory allocation In-Reply-To: <48164C35.7020709@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 29 Apr 2008 01:14:13 +0300") References: <874p9ld4a7.fsf@mocca.josefsson.org> <48164C35.7020709@gnutls.org> Message-ID: <87iqy1m54y.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Simon Josefsson wrote: >> This error has come up lately, see: >> >> http://bugs.debian.org/466477 >> http://bugs.debian.org/478191 >> >> The cause seems clear, the server sends a huge list of CA certs and >> GnuTLS runs into some fixed size buffer or something. This reproduces >> it: >> >> gnutls-cli -p 25 -s mail3.mclemente.net >> ehlo foo >> starttls >> ^D >> >> Nikos, do you have any idea? I could look at it, but have little time >> right now. > > There is this function that can be used to increase the default > handshake packet size. The current is 16kb and is used to protect from > denial of service. > > /** > * gnutls_handshake_set_max_packet_length - set the maximum length of a > handshake message > * @session: is a #gnutls_session_t structure. > * @max: is the maximum number. > * > * This function will set the maximum size of a handshake message. > * Handshake messages over this size are rejected. The default value > * is 16kb which is large enough. Set this to 0 if you do not want to > * set an upper limit. > * > **/ Ah, thanks for the pointer. It seems this is also used for the _total_ handshake packet size, in gnutls_buffers.c: /* Buffer for handshake packets. Keeps the packets in order * for finished messages to use them. Used in HMAC calculation * and finished messages. */ int _gnutls_handshake_buffer_put (gnutls_session_t session, opaque * data, size_t length) { if (length == 0) return 0; if ((session->internals.max_handshake_data_buffer_size > 0) && ((length + session->internals.handshake_hash_buffer.length) > session->internals.max_handshake_data_buffer_size)) { gnutls_assert (); return GNUTLS_E_HANDSHAKE_TOO_LARGE; } I've increased the default limit to 48kb. One of the servers in these two bug reports needed 25kb to do the handshake. I've also updated the documentation for that function slightly. /Simon From yanagisawa at csg.is.titech.ac.jp Tue Apr 29 11:19:05 2008 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Tue, 29 Apr 2008 18:19:05 +0900 Subject: Camellia block cipher don't work on current developers' releases 2.3.x. Message-ID: <4816E809.6030108@csg.is.titech.ac.jp> Hello, I noticed two problems that prevent camellia block cipher working. One problem is that it becomes invalid cipher even with camellia-enabled gnutls. To repeat the problem, just you execute gnutls-cli with: % gnutls-cli --ciphers camellia -p 5556 test.gnutls.org You will see following error: | *** Fatal error: GnuTLS internal error. | *** Handshake has failed | GNUTLS ERROR: GnuTLS internal error. It is cauesd by a bug in lgl/gc-libgcrypt.c. I put the patch to fix the problem: https://savannah.gnu.org/support/index.php?106314 The other problem is that camellia block cipher is disabled by configure script even if the user using libgcrypt with camellia block cipher and configured with --enable-camellia option. You can repeat the problem by installing libgcrypt to no default directory such as /tmp/test, and then pointing the directory with --with-libgcrypt-prefix=/tmp/test as option of the configure script. I found the workaround to avoid the problem. It is just set CFLAGS="`/tmp/test/bin/libgcrypt-config --cflags`" before executing configure script. However, is this right way to avoid the problem? I suppose that this kind of CFLAGS settings should be done inside configure script. Sincerely, Yoshisato Yanagisawa. -- Yoshisato Yanagisawa (Dr.Sc.) From simon at josefsson.org Tue Apr 29 20:07:15 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Apr 2008 20:07:15 +0200 Subject: GnuTLS 2.3.8 Message-ID: <8763u0fsbw.fsf@mocca.josefsson.org> The GnuTLS 2.3.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. The goals for the 2.3.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4 More ideas are welcome, just create a new ticket. Here are the compressed sources: http://alpha.gnu.org/gnu/gnutls/gnutls-2.3.8.tar.bz2 ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.3.8.tar.bz2 Here is the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.3.8.exe http://josefsson.org/gnutls4win/gnutls-2.3.8.zip Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. News in this release: * Version 2.3.8 (released 2008-04-29) ** libgnutls: Increase default handshake packet size limit to 48kb. The old limit was 16kb and some servers send huge list of trusted CAs, thus running into the limit. FYI, applications can further increase this limit using gnutls_handshake_set_max_packet_length. Thanks to Marc Haber and "Marc F. Clemente" for reporting and providing test servers. ** libgnutls: Add new error code: GNUTLS_E_HANDSHAKE_TOO_LARGE Returned when the handshake data size is too large. Before GNUTLS_E_MEMORY_ERROR was used, which could be confused with other error situations. ** libgnutls: Hide definitions in crypto.h. We have decided that the APIs defined in crypto.h are not stable enough for v2.4, so don't use any of those functions. ** gnutls-cli: exit when hostname doesn't match certificate. Use --insecure to avoid hostname comparison. ** certtool: --inder and --outder replaced by --inraw and --outraw. The reason is to align terminology with OpenPGP, which doesn't use DER. The old parameters will continue to work for some time. ** doc: Add section 'Index of new symbols in 2.4.0' to the GTK-DOC manual. ** doc: Many cosmetic fixes, to silence (most) gtk-doc warnings. ** Mingw32: Revert libgcrypt vasprintf work-around added in last release. Use libgcrypt 1.4.1 or later when building on MinGW32, it removes the vasprintf symbol from the libgcrypt library which caused problems. ** Update of gnulib files. ** tests: New self-test of crypto.h RNG code tests/crypto_rng. ** API and ABI modifications: GNUTLS_E_HANDSHAKE_TOO_LARGE: ADDED. /Simon From alon.barlev at gmail.com Tue Apr 29 20:11:28 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 29 Apr 2008 21:11:28 +0300 Subject: GnuTLS-2.2 gcc-4.3 maintainance release Message-ID: <9e0cf0bf0804291111h7ee95740r3730763d25121547@mail.gmail.com> Hello Simon, Can you please consider releasing official gcc-4.3 enabled GnuTLS-2.2 branch? Thanks! Alon. From simon at josefsson.org Tue Apr 29 20:26:04 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 29 Apr 2008 20:26:04 +0200 Subject: GnuTLS-2.2 gcc-4.3 maintainance release In-Reply-To: <9e0cf0bf0804291111h7ee95740r3730763d25121547@mail.gmail.com> (Alon Bar-Lev's message of "Tue, 29 Apr 2008 21:11:28 +0300") References: <9e0cf0bf0804291111h7ee95740r3730763d25121547@mail.gmail.com> Message-ID: <871w4ofrgj.fsf@mocca.josefsson.org> "Alon Bar-Lev" writes: > Hello Simon, > > Can you please consider releasing official gcc-4.3 enabled GnuTLS-2.2 branch? Hi Alon. I'm preparing a new 2.2 release to be released soon. Hm. Which patch did you think of? The guile -fgnu89-inline stuff? Back-porting that shouldn't be a problem. /Simon From alon.barlev at gmail.com Tue Apr 29 20:28:45 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Tue, 29 Apr 2008 21:28:45 +0300 Subject: GnuTLS-2.2 gcc-4.3 maintainance release In-Reply-To: <871w4ofrgj.fsf@mocca.josefsson.org> References: <9e0cf0bf0804291111h7ee95740r3730763d25121547@mail.gmail.com> <871w4ofrgj.fsf@mocca.josefsson.org> Message-ID: <9e0cf0bf0804291128w3586a2bdice456dc7c17e7a06@mail.gmail.com> On 4/29/08, Simon Josefsson wrote: > "Alon Bar-Lev" writes: > > > Hello Simon, > > > > Can you please consider releasing official gcc-4.3 enabled GnuTLS-2.2 branch? > > > Hi Alon. I'm preparing a new 2.2 release to be released soon. Hm. > Which patch did you think of? The guile -fgnu89-inline stuff? > Back-porting that shouldn't be a problem. Great! Yes http://bugs.gentoo.org/show_bug.cgi?id=218200 Alon From simon at josefsson.org Wed Apr 30 00:20:25 2008 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 30 Apr 2008 00:20:25 +0200 Subject: GnuTLS-2.2 gcc-4.3 maintainance release In-Reply-To: <9e0cf0bf0804291128w3586a2bdice456dc7c17e7a06@mail.gmail.com> (Alon Bar-Lev's message of "Tue, 29 Apr 2008 21:28:45 +0300") References: <9e0cf0bf0804291111h7ee95740r3730763d25121547@mail.gmail.com> <871w4ofrgj.fsf@mocca.josefsson.org> <9e0cf0bf0804291128w3586a2bdice456dc7c17e7a06@mail.gmail.com> Message-ID: <87iqy0l2vq.fsf@mocca.josefsson.org> I've prepared a 2.2.3 release candidate, could you please test that it solves the -fgnu89-inline problem, and generally appears to work? http://josefsson.org/tmp/gnutls-2.2.3.tar.gz Thanks, /Simon "Alon Bar-Lev" writes: > On 4/29/08, Simon Josefsson wrote: >> "Alon Bar-Lev" writes: >> >> > Hello Simon, >> > >> > Can you please consider releasing official gcc-4.3 enabled GnuTLS-2.2 branch? >> >> >> Hi Alon. I'm preparing a new 2.2 release to be released soon. Hm. >> Which patch did you think of? The guile -fgnu89-inline stuff? >> Back-porting that shouldn't be a problem. > > Great! > > Yes > http://bugs.gentoo.org/show_bug.cgi?id=218200 > > Alon