From nico at cryptonector.com Sun Dec 1 03:03:14 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 20:03:14 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385801932.12460.12.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: On Sat, Nov 30, 2013 at 2:58 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 18:03 -0600, Nico Williams wrote: >> It is not safe to use PKCS#11 on the child-side of fork() without >> [...] > > I was referring to his issue. As far as I understood he didn't use PKCS > #11 at all, so there should be no breakage. When ones uses PKCS #11 in > gnutls he is (currently) required to call gnutls_pkcs11_reinit() on a > fork. Remember, we're talking about layered software. This might be a process using PAM and loading multiple PAMs that use GnuTLS, so: which one of them should reinit GnuTLS? No, the library *must* self-[re-]initialize. Always. Period. Full stop. There must be no question of some caller being first to initialize, there must be no way for two callers to step on each others' toes by re-initializing the library and destroying the other caller's state. Yes, nothing should fork() and try to use a non-async-signal-safe interface on the child-side of the fork. That does give a library an excuse to have undefined fork-safety. But it's much, much better to have well-defined fork-safety. It's OK to lose access to all objects/whatever on the child-side of fork(), and it's even OK to leak them (since the data structures in question may not be in a consistent state, the library may not be able to walk them, and free() is not async-signal-safe). It'd even be better to abort() if called on the child-side of fork() than to have undefined behavior -- after all, callers of fork() are not supposed to call async-signal-unsafe code. The key is to have deterministic and *noticeable* behavior. The recipe is simple: - use a InitOnceInitialize/pthread_once interface to initialize once as needed (don't require that the caller initialize the library) - use a pthread_atfork() child-side handler to reinitialize all global state (all locks, ...), leaking all of it OR to set a flag, then abort() if called with this flag set Nico -- From nico at cryptonector.com Sun Dec 1 03:07:35 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 20:07:35 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385802235.12460.16.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> <1385802235.12460.16.camel@aspire.lan> Message-ID: On Sat, Nov 30, 2013 at 3:03 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 15:46 -0800, Andy Lutomirski wrote: >> In any case, getting this right on pthreads systems would be a major >> improvement over getting it wrong everywhere. > > Right or wrong is in the eye of the beholder. A documented behavior is a > documented behavior (rather than right or wrong), and calling > gnutls_global_init() on each and every thread is not only unsafe but a > waste of resources. No, in this case it's clear that not self-initializing automatically is "wrong". Again, the canonical example is something like PAM, or the name service switch -- plugin interfaces where more than one plugin might want to use your utility library: a TLS library in this case, and TLS being as ubiquitous as it is, this example does in fact come up. This is an aspect of DLL Hell. You can make DLL Hell less painful by removing the race to initialize, either by making it safe to race to initialize, or by removing the need to initialize. Since you can remove the need to initialize (on every modern OS, on every modern architecture), and since that simplifies your API *and* your docs, that's clearly the way to go. > Indeed, I can fix the unsafe part with static initializers, and I'll try > to, but that will not fix the waste of resources. What waste of resources? Nico -- From nico at cryptonector.com Sun Dec 1 03:08:34 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 20:08:34 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> <1385802235.12460.16.camel@aspire.lan> Message-ID: I should add that in the canonical multi-threaded, multi-caller-of-your-lib cases the callers can't coordinate their use of your library: they are plugins to a framework that doesn't provide a simple facility for them to do so. From nico at cryptonector.com Sun Dec 1 03:14:01 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 20:14:01 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385802484.12460.19.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385802484.12460.19.camel@aspire.lan> Message-ID: On Sat, Nov 30, 2013 at 3:08 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 18:10 -0600, Nico Williams wrote: >> 4) DO NOT USE ELF .ini sections for thread-safe initialization, [...] > > Have you considered or tried using that approach in your branch of > openssl and backed off? If dependencies are avoided it looks like an > ideal fix, especially if you consider that a global initialization > function would do much more than just initializing mutexes (e.g. > precalculations or CPU type detection). .init sections have all of these problems: - they aren't standard (not part of POSIX) - they're not necessarily available in static linking cases (after all, they are not standard) - they require more autoconf/source/build complexity - the order in which dependencies are loaded and their .init sections run is unstable -- you can help yourself a bit by having no dependencies on anything other than -lc and -lpthread in your .init section, but you can't help anyone else who has a dependency on your library in their .init sections(!) Whereas using pthread_once() and friends is all standard. You can build a pthread_once/InitOnceInitialize out of mutexes if you have static mutex initializers, and you can build those if you have CAS. Besides, the once approach is elegant and lends itself well to doing the Right Thing, which is: automatically and thread-safely self-initialize. Nico -- From luto at amacapital.net Sun Dec 1 03:34:37 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Sat, 30 Nov 2013 18:34:37 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: On Nov 30, 2013 6:03 PM, "Nico Williams" wrote: > > On Sat, Nov 30, 2013 at 2:58 AM, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2013-11-29 at 18:03 -0600, Nico Williams wrote: > >> It is not safe to use PKCS#11 on the child-side of fork() without > >> [...] > > > > I was referring to his issue. As far as I understood he didn't use PKCS > > #11 at all, so there should be no breakage. When ones uses PKCS #11 in > > gnutls he is (currently) required to call gnutls_pkcs11_reinit() on a > > fork. > > Remember, we're talking about layered software. This might be a > process using PAM and loading multiple PAMs that use GnuTLS, so: which > one of them should reinit GnuTLS? No, the library *must* > self-[re-]initialize. Always. Period. Full stop. There must be no > question of some caller being first to initialize, there must be no > way for two callers to step on each others' toes by re-initializing > the library and destroying the other caller's state. > > Yes, nothing should fork() and try to use a non-async-signal-safe > interface on the child-side of the fork. Huh? It should be entirely safe for a single-threaded program to open a TLS connection, close it, fork, and open another connection. The async-signal-safe-only thing applies to multithreaded programs only. --Andy That does give a library an > excuse to have undefined fork-safety. But it's much, much better to > have well-defined fork-safety. It's OK to lose access to all > objects/whatever on the child-side of fork(), and it's even OK to leak > them (since the data structures in question may not be in a consistent > state, the library may not be able to walk them, and free() is not > async-signal-safe). It'd even be better to abort() if called on the > child-side of fork() than to have undefined behavior -- after all, > callers of fork() are not supposed to call async-signal-unsafe code. > The key is to have deterministic and *noticeable* behavior. > > The recipe is simple: > > - use a InitOnceInitialize/pthread_once interface to initialize once as needed > (don't require that the caller initialize the library) > > - use a pthread_atfork() child-side handler to reinitialize all > global state (all locks, ...), leaking all of it OR to set a flag, > then abort() if called with this flag set > > Nico > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Sun Dec 1 03:46:51 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 20:46:51 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: On Saturday, November 30, 2013, Andy Lutomirski wrote: > On Nov 30, 2013 6:03 PM, "Nico Williams" > > wrote: > > Yes, nothing should fork() and try to use a non-async-signal-safe > > interface on the child-side of the fork. > > Huh? It should be entirely safe for a single-threaded program to open a > TLS connection, close it, fork, and open another connection. > > The async-signal-safe-only thing applies to multithreaded programs only. > A program using a TLS library might be threaded unwittingly. What if the TLS library wants to parallelize, say, AES counter mode computation and starts worker threads for doing it? In a layered software case (involving complex plugins, say) you quickly lose control over whether the process is threaded. Nico -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From luto at amacapital.net Sun Dec 1 03:50:56 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Sat, 30 Nov 2013 18:50:56 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: On Nov 30, 2013 6:46 PM, "Nico Williams" wrote: > > > On Saturday, November 30, 2013, Andy Lutomirski wrote: >> >> On Nov 30, 2013 6:03 PM, "Nico Williams" wrote: >> > Yes, nothing should fork() and try to use a non-async-signal-safe >> > interface on the child-side of the fork. >> >> Huh? It should be entirely safe for a single-threaded program to open a TLS connection, close it, fork, and open another connection. >> >> The async-signal-safe-only thing applies to multithreaded programs only. > > > A program using a TLS library might be threaded unwittingly. What if the TLS library wants to parallelize, say, AES counter mode computation and starts worker threads for doing it? A library that starts threads for things like that should document it and offer a way to turn it off. This is especially true for CTR mode stuff. The last thing a heavily threaded, multiple connection program wants is for its TLS library to start threads. --Andy > > In a layered software case (involving complex plugins, say) you quickly lose control over whether the process is threaded. > > Nico > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico at cryptonector.com Sun Dec 1 04:35:37 2013 From: nico at cryptonector.com (Nico Williams) Date: Sat, 30 Nov 2013 21:35:37 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: On Sat, Nov 30, 2013 at 8:50 PM, Andy Lutomirski wrote: > On Nov 30, 2013 6:46 PM, "Nico Williams" wrote: >> A program using a TLS library might be threaded unwittingly. What if the >> TLS library wants to parallelize, say, AES counter mode computation and >> starts worker threads for doing it? > > A library that starts threads for things like that should document it and > offer a way to turn it off. It's not just the TLS library. It's about layered plugin software architectures. The app might be threaded and the TLS library not know it. The app might be single-threaded, but a plugin (e.g., PAM) might use threads. Does PAM say not to start threads in plugins? Once you get a complex-enough case you lose the ability to know for certain. It's best for fork() callers to _exit() or exec*() on the child-side of fork(). Anyways, I'll settle self-initialization of the library, and let callers that fork() and don't exec take their chances. Nico -- From nmav at gnutls.org Sun Dec 1 10:40:54 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 01 Dec 2013 10:40:54 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385802484.12460.19.camel@aspire.lan> Message-ID: <1385890854.1829.9.camel@aspire.lan> On Sat, 2013-11-30 at 20:14 -0600, Nico Williams wrote: > On Sat, Nov 30, 2013 at 3:08 AM, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2013-11-29 at 18:10 -0600, Nico Williams wrote: > >> 4) DO NOT USE ELF .ini sections for thread-safe initialization, [...] > > > > Have you considered or tried using that approach in your branch of > > openssl and backed off? If dependencies are avoided it looks like an > > ideal fix, especially if you consider that a global initialization > > function would do much more than just initializing mutexes (e.g. > > precalculations or CPU type detection). > > .init sections have all of these problems: > > - they aren't standard (not part of POSIX) > > - they're not necessarily available in static linking cases (after > all, they are not standard) > > - they require more autoconf/source/build complexity > > - the order in which dependencies are loaded and their .init sections > run is unstable -- you can help yourself a bit by having no > dependencies on anything other than -lc and -lpthread in your .init > section, but you can't help anyone else who has a dependency on your > library in their .init sections(!) > Whereas using pthread_once() and friends is all standard. You can > build a pthread_once/InitOnceInitialize out of mutexes if you have > static mutex initializers, and you can build those if you have CAS. > Besides, the once approach is elegant and lends itself well to doing > the Right Thing, which is: automatically and thread-safely > self-initialize. The more I think about static initialization of mutexes the more I think they are not a good idea for a library. How would you deinitialize a statically initialized mutex? Never? Then you get a memory/resource leak in the PAM case you are referring to. As these modules are opened with dlopen() and dlclosed later they leave the static mutex initialized. If you deinitialize on the last call to the deinitialization function then assuming you have other threads calling the global initialization function in parallel you may even get crashes during that deinitialization if they try to lock it. There is no easy solution there instead of using a destructor to deinitialize the static mutex. Thus again you are using the "non-standard" destructors. Thus the only elegant solution I see is initialization on a constructor and deinitialization on a destructor. That works on ELF libraries and DLL libraries (yes it doesn't work on static libraries), but that is already a significant fraction of what we want to support. regards, Nikos From nmav at gnutls.org Sun Dec 1 10:52:06 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 01 Dec 2013 10:52:06 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> Message-ID: <1385891526.1829.15.camel@aspire.lan> On Sat, 2013-11-30 at 20:03 -0600, Nico Williams wrote: > - use a InitOnceInitialize/pthread_once interface to initialize once as needed > (don't require that the caller initialize the library) > - use a pthread_atfork() child-side handler to reinitialize all > global state (all locks, ...), leaking all of it OR to set a flag, > then abort() if called with this flag set These are not a bad idea, and p11-kit (the library we use for PKCS #11) already does that (at least partially as I understand to allow detection of uninitialized modules - you cannot perform full pkcs11 module reinitialization in the atfork handler). What is bad though is that we get complaints that we require pthreads, something that makes some slower and thread-safe libc algorithms to kick-in for applications that don't need them. So every solution at this point has a catch. regards, Nikos From nmav at gnutls.org Sun Dec 1 11:00:23 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 01 Dec 2013 11:00:23 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> <1385802235.12460.16.camel@aspire.lan> Message-ID: <1385892023.1829.22.camel@aspire.lan> On Sat, 2013-11-30 at 20:07 -0600, Nico Williams wrote: > Again, the canonical example is something like PAM, or the name > service switch -- plugin interfaces where more than one plugin might > want to use your utility library: a TLS library in this case, and TLS > being as ubiquitous as it is, this example does in fact come up. This > is an aspect of DLL Hell. You can make DLL Hell less painful by > removing the race to initialize, either by making it safe to race to > initialize, or by removing the need to initialize. Since you can > remove the need to initialize (on every modern OS, on every modern > architecture), and since that simplifies your API *and* your docs, > that's clearly the way to go. > > > Indeed, I can fix the unsafe part with static initializers, and I'll try > > to, but that will not fix the waste of resources. > What waste of resources? Like calling an initialization function on each and every thread. An initialization function does much more than setting up mutexes, such as precalculate values etc. A lock added there for thread safety cannot protect from running this function multiple times needlessly. Think of a case where threads are run serialized, and call global_init() and global_deinit(). They will all have to run the initialization routine. regards, Nikos From luto at amacapital.net Sun Dec 1 16:21:07 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Sun, 1 Dec 2013 07:21:07 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385890854.1829.9.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385802484.12460.19.camel@aspire.lan> <1385890854.1829.9.camel@aspire.lan> Message-ID: On Dec 1, 2013 1:41 AM, "Nikos Mavrogiannopoulos" wrote: > > On Sat, 2013-11-30 at 20:14 -0600, Nico Williams wrote: > > On Sat, Nov 30, 2013 at 3:08 AM, Nikos Mavrogiannopoulos > > wrote: > > > On Fri, 2013-11-29 at 18:10 -0600, Nico Williams wrote: > > >> 4) DO NOT USE ELF .ini sections for thread-safe initialization, [...] > > > > > > Have you considered or tried using that approach in your branch of > > > openssl and backed off? If dependencies are avoided it looks like an > > > ideal fix, especially if you consider that a global initialization > > > function would do much more than just initializing mutexes (e.g. > > > precalculations or CPU type detection). > > > > .init sections have all of these problems: > > > > - they aren't standard (not part of POSIX) > > > > - they're not necessarily available in static linking cases (after > > all, they are not standard) > > > > - they require more autoconf/source/build complexity > > > > - the order in which dependencies are loaded and their .init sections > > run is unstable -- you can help yourself a bit by having no > > dependencies on anything other than -lc and -lpthread in your .init > > section, but you can't help anyone else who has a dependency on your > > library in their .init sections(!) > > Whereas using pthread_once() and friends is all standard. You can > > build a pthread_once/InitOnceInitialize out of mutexes if you have > > static mutex initializers, and you can build those if you have CAS. > > Besides, the once approach is elegant and lends itself well to doing > > the Right Thing, which is: automatically and thread-safely > > self-initialize. > > The more I think about static initialization of mutexes the more I think > they are not a good idea for a library. How would you deinitialize a > statically initialized mutex? Never? Then you get a memory/resource leak > in the PAM case you are referring to. As these modules are opened with > dlopen() and dlclosed later they leave the static mutex initialized. > > If you deinitialize on the last call to the deinitialization function > then assuming you have other threads calling the global initialization > function in parallel you may even get crashes during that > deinitialization if they try to lock it. > > There is no easy solution there instead of using a destructor to > deinitialize the static mutex. Thus again you are using the > "non-standard" destructors. I think that this "leak" is okay. First, unloading a library before exit is rare. Second, there isn't actually a leak on sensible platforms (Linux) where an unlocked mutex is literally just the memory occupied by the struct pthread_mutex_t. As far as I know, Windows is the only platform that distinguishes library unload from process shutdown in destructors, and destroying mutexes at process shutdown risks annoying crashes if a multithreaded program calls exit. --Andy > > Thus the only elegant solution I see is initialization on a constructor > and deinitialization on a destructor. That works on ELF libraries and > DLL libraries (yes it doesn't work on static libraries), but that is > already a significant fraction of what we want to support. > > regards, > Nikos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Sun Dec 1 20:04:59 2013 From: code at funwithsoftware.org (Patrick Pelletier) Date: Sun, 01 Dec 2013 11:04:59 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process In-Reply-To: <1385802044.12460.13.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> <1385802044.12460.13.camel@aspire.lan> Message-ID: <529B885B.6080600@funwithsoftware.org> On 11/30/13, 1:00 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 18:00 -0600, Nico Williams wrote: >> See http://stackoverflow.com/questions/3555859/is-it-possible-to-do-static-initialization-of-mutexes-in-windows > That looks interesting thanks. My preferred way of handling this on Windows is similar, but uses a CRITICAL_SECTION instead of a mutex, because CRITICAL_SECTIONs are handled in userspace if possible, much like pthread mutexes are on Linux. --Patrick -------------- next part -------------- /** * Return *loc after executing a memory barrier. */ #define ob_atomic_pointer_ref(loc) (MemoryBarrier(), *(loc)) /** * Set *loc to \a shall_be, and then execute a memory barrier. */ #define ob_atomic_pointer_set(loc, shall_be) \ do \ { *(loc) = (shall_be); \ MemoryBarrier (); \ } while (0) /** * If *loc equals \a was, then set *loc to \a shall_be and return * true. Otherwise, leave *loc unchanged and return false. */ #define ob_atomic_pointer_compare_and_swap(loc, was, shall_be) \ ob_private_atomic_pointer_compare_and_swap ((void**) (loc), (was), (shall_be)) static inline bool ob_private_atomic_pointer_compare_and_swap (void **loc, void *was, void *shall_be) { return (was == InterlockedCompareExchangePointer (loc, shall_be, was)); } /** * Windows critical sections seem to have a problem; you have * to initialize them with InitializeCriticalSection() before * you can use them. If you want to protect a global object, and * are worried about the "initialization order fiasco": * http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12 * then there's no good time to initialize it. * * This function solves that problem by using atomic ops to make * sure the critical section gets initialized before the first * time it is used. (Unfortunately, DeleteCriticalSection will * never be called, but I think that's okay for objects of global * scope, because the OS should reclaim the resources on program * termination.) * * To use it, have a global/static variable of type "void *" * that represents your critical section. (Which will start out * as NULL.) Then call ob_fetch_critical() with the address of * your void * variable whenever you want to use the critical * section. You'll get back a pointer to the critical section, * which will be allocated and initialized if necessary. */ CRITICAL_SECTION *ob_fetch_critical (void **vpp) { void *vp = ob_atomic_pointer_ref (vpp); if (!vp) { CRITICAL_SECTION *cs = (CRITICAL_SECTION *) calloc (1, sizeof (CRITICAL_SECTION)); if (!cs || !InitializeCriticalSectionAndSpinCount (cs, 4000)) { free (cs); return NULL; } if (ob_atomic_pointer_compare_and_swap (vpp, NULL, cs)) vp = cs; // we won else { // somebody else beat us to it, so deallocate our critical // section, because it didn't "win" DeleteCriticalSection (cs); free (cs); vp = ob_atomic_pointer_ref (vpp); // get the guy who did win } } return (CRITICAL_SECTION *) vp; } From nico at cryptonector.com Sun Dec 1 20:07:31 2013 From: nico at cryptonector.com (Nico Williams) Date: Sun, 1 Dec 2013 13:07:31 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385890854.1829.9.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385802484.12460.19.camel@aspire.lan> <1385890854.1829.9.camel@aspire.lan> Message-ID: On Sun, Dec 1, 2013 at 3:40 AM, Nikos Mavrogiannopoulos wrote: > The more I think about static initialization of mutexes the more I think > they are not a good idea for a library. How would you deinitialize a > statically initialized mutex? Never? Then you get a memory/resource leak > in the PAM case you are referring to. As these modules are opened with > dlopen() and dlclosed later they leave the static mutex initialized. This is what atexit() and thread-specific destructors are for. Also, global locks don't really need destruction, and most apps that use them never destroy them. And on last dlclose() then re-dlopen() the RTLD should setup a brand new bss and re-map data, so there's no real problem with leaving locks initialized. On BSD/Unix/Linux systems there's no real problem with leaking init-time resources anyways. And even on Windows, I suspect a library like GnuTLS never gets unloaded. > If you deinitialize on the last call to the deinitialization function > then assuming you have other threads calling the global initialization > function in parallel you may even get crashes during that > deinitialization if they try to lock it. See above. Nico -- From nico at cryptonector.com Sun Dec 1 20:11:31 2013 From: nico at cryptonector.com (Nico Williams) Date: Sun, 1 Dec 2013 13:11:31 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385891526.1829.15.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> <1385891526.1829.15.camel@aspire.lan> Message-ID: The obvious things to do re: complaints about having to link with -lpthread: a) "sorry, too bad", or b) "ok, you can build w/o thread support; good luck", or c) audo-detect pthread presence at init time using weak symbols or dlsym() on RTLD_DEFAULT. (c) is dangerous: the app might dlopen() something that links with -lpthread and uses your library in addition to the app using your library. It's best to require a threaded model everywhere (even if only one thread is ever used). Nico -- From nico at cryptonector.com Mon Dec 2 00:13:33 2013 From: nico at cryptonector.com (Nico Williams) Date: Sun, 1 Dec 2013 17:13:33 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <1385801932.12460.12.camel@aspire.lan> <1385891526.1829.15.camel@aspire.lan> Message-ID: Another thing you can do if you're really concerned about unload is to tell the link-editor/RTLD to not unload the GnuTLS object(s), or dlopen() yourself at self-init time and purposefully leak the handle. It's ok to leak a small, *fixed* amount of resources. In particular it's far more important to support the layered plugin use case, including racing callers in different objects, than to not leak anything on last dlclose(). (There is something to lose from not being unloadable randomized load addresses changing over the life of one process, but it'd be nice to have an existence proof that real apps with long-running processes actually unload add reload modules.) Nico -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Tue Dec 3 23:20:24 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 03 Dec 2013 17:20:24 -0500 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? Message-ID: <8761r560gn.fsf@alice.fifthhorseman.net> I find myself wishing that GnuTLS could report a "weakest link security level summary" for an established session. I know this is generally a gross oversimplification, but i think many library users actually want simplifications, so we should give them to them. So, for example, if you used a server-side RSA key of 4096 bits (HIGH), with AES-256 (HIGH), and ECDHE with CURVE-SECP192R1 (LEGACY), it would report "LEGACY". I'm thinking this would be useful for programs that want to ensure all of the knobs are turned at least to a certain level, or perhaps to behave differently if the knobs are *not* set to a certain level (as opposed to just refusing to communicate). For example, i can imagine a MTA (acting as a server) that will respond differently to an "RCPT TO: secureaccount at example.org" depending on whether the "weakest link" of the connection is "NORMAL" or higher. I could also imagine a web application that chooses to display different data depending on the security level selected (e.g. a warning box that says "we are allowing this connection, but you really should upgrade your client"). This information is currently extractable from things like gnutls_dh_get_prime_bits, etc, but the user needs to know a lot about TLS to figure out how to extract the various pieces of information and compare them against each other. And as new ciphersuites and new modes are introduced into GnuTLS, library users might miss out on some relevant details, so it seems like it would be better to have this summary feature in the library itself, for users who *want* a gross simplification without having to get into the details themselves. What do folks think about this idea? Open questions: 0) should this summary include things like the size of the intermediate or root CAs, or the digest algorithms used in those certificates? 1) how do we track something like this across TLS renegotiation? if a session starts off with a weakest link of LEGACY, and then renegotiates to NORMAL, is the current session "NORMAL"? or would we consider it LEGACY because the original connection was LEGACY? 2) when uncommon mechanisms come into play, if they are the "weakest link" (e.g. when an otherwise "HIGH" session encounters a "LEGACY" client-side cert), should this summary info drop accordingly? 3) i can imagine some frustration from users if they find out that the summary is lower than they want but they don't know how to identify the weak link itself. Should such a sec_param summary also indicate which parts of the connection are at the weakest sec_param level? I can imagine a bitfield that indicates KX|SERVERKEY|CERTSIG|MAC|CIPHER|etc, which would be returned along with the sec_param, so that users who wanted to know which part of the negotiated parameters ought to be improved, but i don't know how to enumerate that. 4) i'm not sure how to properly represent qualitative shifts like cipher block chaining modes in this analysis -- at the moment, i'm just imagining that AES-256-CBC would be rated the same level as AES-256-GCM based on key size strength, even though i know that's not really the accepted wisdom at the moment. Some of these decisions will likely be judgement calls, but i think it's worth baking a set of reasonable judgement calls based on our current knowledge into the library for users who don't want to have to learn how to make those calls themselves. In the event that knowledge changes, we can push out a modified version of these judgement calls in an upgrade, rather than requiring all of our users to update their code or configurations. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From ott at mirix.org Wed Dec 4 00:11:54 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Wed, 04 Dec 2013 00:11:54 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <8761r560gn.fsf@alice.fifthhorseman.net> References: <8761r560gn.fsf@alice.fifthhorseman.net> Message-ID: <529E653A.8070309@mirix.org> On 2013-12-03 23:20, Daniel Kahn Gillmor wrote: > I find myself wishing that GnuTLS could report a "weakest link security > level summary" for an established session. I know this is generally a > gross oversimplification, but i think many library users actually want > simplifications, so we should give them to them. > > So, for example, if you used a server-side RSA key of 4096 bits (HIGH), > with AES-256 (HIGH), and ECDHE with CURVE-SECP192R1 (LEGACY), it would > report "LEGACY". I wonder whether LEGACY and NORMAL are good categories. I think the actual security levels need some more thinking. Unfortunately I don't have good answers either. > I'm thinking this would be useful for programs that want to ensure all > of the knobs are turned at least to a certain level, or perhaps to > behave differently if the knobs are *not* set to a certain level (as > opposed to just refusing to communicate). > > For example, i can imagine a MTA (acting as a server) that will respond > differently to an "RCPT TO: secureaccount at example.org" depending on > whether the "weakest link" of the connection is "NORMAL" or higher. I > could also imagine a web application that chooses to display different > data depending on the security level selected (e.g. a warning box that > says "we are allowing this connection, but you really should upgrade > your client"). > > This information is currently extractable from things like > gnutls_dh_get_prime_bits, etc, but the user needs to know a lot about > TLS to figure out how to extract the various pieces of information and > compare them against each other. And as new ciphersuites and new modes > are introduced into GnuTLS, library users might miss out on some > relevant details, so it seems like it would be better to have this > summary feature in the library itself, for users who *want* a gross > simplification without having to get into the details themselves. In mod_gnutls, mod_ssl and nginx, you could implement this as a library that reads environment variables of the request (e.g. SSL_CIPHER in mod_gnutls and mod_ssl) and computes the security from this ? no patches for TLS libraries required. For other types of software this could be implemented as a separate library as well. > What do folks think about this idea? +1 Businesses with regulatory requirements that must use a certain set of cryptography algorithms or must ensure a minimal key length etc. could also make use of this. > Open questions: > > 0) should this summary include things like the size of the intermediate > or root CAs, or the digest algorithms used in those certificates? Depends on if the software uses Trust On First Use, Certificate Pinning, Certificate Notaries etc. which make CAs less important. > 1) how do we track something like this across TLS renegotiation? if a > session starts off with a weakest link of LEGACY, and then > renegotiates to NORMAL, is the current session "NORMAL"? or would > we consider it LEGACY because the original connection was LEGACY? Can you give an example of an implementation with this behaviour? I vaguely remember that SChannel on Windows 7 and Internet Explorer 9 had some problems when experimented with GnuTLS and ECDH and ECDSA only cipher suites (it pretended to know only 3DES and RSA or something like this). > 2) when uncommon mechanisms come into play, if they are the "weakest > link" (e.g. when an otherwise "HIGH" session encounters a "LEGACY" > client-side cert), should this summary info drop accordingly? Yes, the overall security is just as good as its weakest link. > 3) i can imagine some frustration from users if they find out that the > summary is lower than they want but they don't know how to identify > the weak link itself. Should such a sec_param summary also indicate > which parts of the connection are at the weakest sec_param level? I > can imagine a bitfield that indicates > KX|SERVERKEY|CERTSIG|MAC|CIPHER|etc, which would be returned along > with the sec_param, so that users who wanted to know which part of > the negotiated parameters ought to be improved, but i don't know how > to enumerate that. Tt's not clear to me whether you mean developers using GnuTLS or ?end-users?. End-users probably need more practical advice like ?You are using an oudated version of web browser/application XY that is not secure by todays standards. Thus you can only access limited information. Please upgrade to version A.B to gain full access?. This definitely doesn't belong in a TLS library. > 4) i'm not sure how to properly represent qualitative shifts like > cipher block chaining modes in this analysis -- at the moment, i'm > just imagining that AES-256-CBC would be rated the same level as > AES-256-GCM based on key size strength, even though i know that's > not really the accepted wisdom at the moment. Some of these > decisions will likely be judgement calls, but i think it's worth > baking a set of reasonable judgement calls based on our current > knowledge into the library for users who don't want to have to learn > how to make those calls themselves. In the event that knowledge > changes, we can push out a modified version of these judgement calls > in an upgrade, rather than requiring all of our users to update > their code or configurations. You could make this a rule-based system with a separate rule set so that users can adapt to their needs and receive automatic updates for standard rule sets. Some thinking needs to be done on howto generate proper error messages for end-users with existing rule engines. Is your focus on web sites and applications (seems easier) or on all software which uses TLS? Regards, Matthias-Christian From nmav at gnutls.org Wed Dec 4 09:47:02 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Dec 2013 09:47:02 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <8761r560gn.fsf@alice.fifthhorseman.net> References: <8761r560gn.fsf@alice.fifthhorseman.net> Message-ID: <1386146822.2047.46.camel@aspire.lan> On Tue, 2013-12-03 at 17:20 -0500, Daniel Kahn Gillmor wrote: > I find myself wishing that GnuTLS could report a "weakest link security > level summary" for an established session. I know this is generally a > gross oversimplification, but i think many library users actually want > simplifications, so we should give them to them. > > So, for example, if you used a server-side RSA key of 4096 bits (HIGH), > with AES-256 (HIGH), and ECDHE with CURVE-SECP192R1 (LEGACY), it would > report "LEGACY". Hello Daniel, That's something I've spent quite some time thinking at. I believe it is a nice idea, and doable, but it is not an easy mapping. That is there are few factors: 1. Confidentiality What level of confidentiality does this ciphersuite offer? (depends on the cipher, the key exchange, and the certificates) 2. Tampering What level of tamper-resistance this ciphersuite offers? (depends on the HMAC used). Since for (2) only online attacks are a concern one could tolerate algorithms that have a lower security margin (e.g., HMAC-MD5) than their confidentiality counter-parts (e.g., AES-128). To make things worse, in the DH key exchange, the client can only presume the security level, as he cannot know, whether the prime sent by the server is of some weak form. Nevertheless, despite the difficulties, I think it would be very good to have an estimator of the security of the overall session. > Open questions: > > 0) should this summary include things like the size of the intermediate > or root CAs, or the digest algorithms used in those certificates? To be complete it should, but you can start without it. > 1) how do we track something like this across TLS renegotiation? if a > session starts off with a weakest link of LEGACY, and then > renegotiates to NORMAL, is the current session "NORMAL"? or would > we consider it LEGACY because the original connection was LEGACY? I think it would be good to keep it simple and refer only to the current session and not any previous ones. > 2) when uncommon mechanisms come into play, if they are the "weakest > link" (e.g. when an otherwise "HIGH" session encounters a "LEGACY" > client-side cert), should this summary info drop accordingly? I guess so. For such an indicator all parameters should come into play. However, in that case the question is "is LEGACY but client authenticated better than NORMAL but without client authentication?". I don't have an answer for that :) > 3) i can imagine some frustration from users if they find out that the > summary is lower than they want but they don't know how to identify > the weak link itself. Should such a sec_param summary also indicate > which parts of the connection are at the weakest sec_param level? I > can imagine a bitfield that indicates > KX|SERVERKEY|CERTSIG|MAC|CIPHER|etc, which would be returned along > with the sec_param, so that users who wanted to know which part of > the negotiated parameters ought to be improved, but i don't know how > to enumerate that. You could have a function that reports the overall level, and another that reports the level per section (KX,CERT,MAC ...) - or one function combining everything. > 4) i'm not sure how to properly represent qualitative shifts like > cipher block chaining modes in this analysis -- at the moment, i'm > just imagining that AES-256-CBC would be rated the same level as > AES-256-GCM based on key size strength, even though i know that's > not really the accepted wisdom at the moment. Since we have all the known counter-measures implemented that would be pretty much ok, but I see your point. More important issue would be how to rate RC4... regards, Nikos From dkg at fifthhorseman.net Wed Dec 4 15:40:51 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 04 Dec 2013 09:40:51 -0500 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <529E653A.8070309@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> Message-ID: <529F3EF3.6060401@fifthhorseman.net> On 12/03/2013 06:11 PM, Matthias-Christian Ott wrote: > I wonder whether LEGACY and NORMAL are good categories. I think the > actual security levels need some more thinking. Unfortunately I don't > have good answers either. I think most users need something simple for guidance. A small set of levels like EXPORT,LEGACY,NORMAL,HIGH,ULTRA fits the bill. People who have very specific needs can still have access to all the grubby details and could just as well ignore this summary sec_param. > In mod_gnutls, mod_ssl and nginx, you could implement this as a library > that reads environment variables of the request (e.g. SSL_CIPHER in > mod_gnutls and mod_ssl) and computes the security from this ? no patches > for TLS libraries required. For other types of software this could be > implemented as a separate library as well. i don't think you can do this. For example, SSL_CIPHER doesn't expose the number of bits in the DHE key exchange handshake. Also, the underlying TLS library could itself add new features that this hypothetical external library doesn't know anything about. I think the TLS library itself (which has all of the specific knowledge about the transport layer) is the right place for this. I see it as in some ways analogous to the xssl API -- simplicity and a minimum of knobs, for users without specialized needs, but who want to be able to tell how secure their connections are. > Businesses with regulatory requirements that must use a certain set of > cryptography algorithms or must ensure a minimal key length etc. could > also make use of this. For this specific use case, where there is a hard limit, i think the user would be better off using the priority string. >> 1) how do we track something like this across TLS renegotiation? if a >> session starts off with a weakest link of LEGACY, and then >> renegotiates to NORMAL, is the current session "NORMAL"? or would >> we consider it LEGACY because the original connection was LEGACY? > > Can you give an example of an implementation with this behaviour? I > vaguely remember that SChannel on Windows 7 and Internet Explorer 9 had > some problems when experimented with GnuTLS and ECDH and ECDSA only > cipher suites (it pretended to know only 3DES and RSA or something like > this). each peer can choose to trigger a renegotiation (a new TLS handshake) at any time. It's not a I haven't done much testing with this, though. > Tt's not clear to me whether you mean developers using GnuTLS or > ?end-users?. End-users probably need more practical advice like ?You are > using an oudated version of web browser/application XY that is not > secure by todays standards. Thus you can only access limited > information. Please upgrade to version A.B to gain full access?. This > definitely doesn't belong in a TLS library. right; I'm talking about developers who use the GnuTLS library, not end users. The TLS library seems like the right place to provide this information to the developers, so that they can decide what to display to the end user. > Is your focus on web sites and applications (seems easier) or on all > software which uses TLS? I'd like to provide this information at the TLS layer itself, so that web sites and applications can make use of it. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Dec 4 15:52:10 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 04 Dec 2013 09:52:10 -0500 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: References: <8761r560gn.fsf@alice.fifthhorseman.net> <1386146822.2047.46.camel@aspire.lan> Message-ID: <529F419A.5010009@fifthhorseman.net> On 12/04/2013 03:57 AM, Alfredo Pironti wrote: > Indeed, an implementation could check whether the server prime is in a > "white list" of known good primes. A bit like negotiating a named > elliptic curve, or like SSH does by negotiating named DH groups. I > actually don't understand why TLS leaves all this dangerous freedom, > and does not allow negotiation of named groups; sounds a bit like > those NSA-instilled bugs... ;-) the more i learn about the underlying math and the protocol itself, the more i agree with this sentiment. I'm starting work on a DH negotiation TLS extension that will include (and encourage) named groups; i hope to publish a (i'm sure very rough) first draft for review in the TLS WG sometime next week. I would be very happy to get feedback or collaboration on that if you're interested. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From jaak.ristioja at cyber.ee Mon Dec 9 13:27:14 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 09 Dec 2013 14:27:14 +0200 Subject: [gnutls-devel] Question about gnutls_record_uncork Message-ID: <52A5B722.8010508@cyber.ee> Hi! Looking at the source code of the gnutls_record_uncork function in lib/gnutls_record.c it appears that the following might happen: ... ret = gnutls_record_send(...); /* ret >= 0 */ ... total += ret; ... ret = gnutls_record_send(...); /* ret < 0 */ ... return ret; Hence, whatever was stored in the variable "total", is lost even in case of EAGAIN when flags != GNUTLS_RECORD_WAIT. The problem here is that the code calling gnutls_record_uncork has no way to tell how much data was actually sent. For example: gnutls_record_uncork(...); /* ret == 10: have sent 10 bytes */ gnutls_record_uncork(...); /* ret == 10: have sent 20 bytes */ gnutls_record_uncork(...); /* ret < 0: have sent 20 + ??? bytes */ gnutls_record_uncork(...); /* ret == 10: have sent 30 + ??? bytes */ Are there any other means to check how much pending output data TLS has buffered? Can somebody please comment on this? Thanks! Best regards, Jaak From nmav at gnutls.org Mon Dec 9 13:46:28 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Dec 2013 13:46:28 +0100 Subject: [gnutls-devel] Question about gnutls_record_uncork In-Reply-To: <52A5B722.8010508@cyber.ee> References: <52A5B722.8010508@cyber.ee> Message-ID: On Mon, Dec 9, 2013 at 1:27 PM, Jaak Ristioja wrote: > Hi! > Looking at the source code of the gnutls_record_uncork function in > lib/gnutls_record.c it appears that the following might happen: > ... > ret = gnutls_record_send(...); /* ret >= 0 */ > ... > total += ret; > ... > ret = gnutls_record_send(...); /* ret < 0 */ > ... > return ret; > Hence, whatever was stored in the variable "total", is lost even in case > of EAGAIN when flags != GNUTLS_RECORD_WAIT. The problem here is that the > code calling gnutls_record_uncork has no way to tell how much data was > actually sent. [...] > Are there any other means to check how much pending output data TLS has > buffered? Can somebody please comment on this? Thanks! You cannot get this information. It is kept internally and will be used to send the rest of the data when you call gnutls_record_uncork() again. Could you explain about your use-case and why you think you need that? regards, Nikos From jaak.ristioja at cyber.ee Mon Dec 9 14:24:31 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 09 Dec 2013 15:24:31 +0200 Subject: [gnutls-devel] Question about gnutls_record_uncork In-Reply-To: References: <52A5B722.8010508@cyber.ee> Message-ID: <52A5C48F.5030303@cyber.ee> On 09.12.2013 14:46, Nikos Mavrogiannopoulos wrote: > On Mon, Dec 9, 2013 at 1:27 PM, Jaak Ristioja wrote: >> Hi! >> Looking at the source code of the gnutls_record_uncork function in >> lib/gnutls_record.c it appears that the following might happen: >> ... >> ret = gnutls_record_send(...); /* ret >= 0 */ >> ... >> total += ret; >> ... >> ret = gnutls_record_send(...); /* ret < 0 */ >> ... >> return ret; >> Hence, whatever was stored in the variable "total", is lost even in case >> of EAGAIN when flags != GNUTLS_RECORD_WAIT. The problem here is that the >> code calling gnutls_record_uncork has no way to tell how much data was >> actually sent. > [...] >> Are there any other means to check how much pending output data TLS has >> buffered? Can somebody please comment on this? Thanks! > > You cannot get this information. It is kept internally and will be > used to send the rest of the data when you call gnutls_record_uncork() > again. Could you explain about your use-case and why you think you > need that? The use case is very complicated, but basically it needs to keep track of whether all corked data has actually been sent or not. Using GNUTLS_RECORD_WAIT is not an option for us, because in some cases the underlying TCP buffers get full on both endpoints at the same time hence causing a livelock (async. I/O, can't call gnutls_record_recv while the other thread is in gnutls_record_uncork; both endpoints try to uncork at the same time). What might help would be a function to return the value of the variable session->internals.record_presend_buffer.length. However, I think I will currently use something like this to work around the problem: void flush() { int ret; for (;;) { { Lock lock(m_sessionLock); ret = gnutls_record_uncork(m_session, 0); } if (ret == 0) break; if (ret < 0 && ret != GNUTLS_E_INTERRUPTED && ret != GNUTLS_E_AGAIN) throw Exception(...); sleepSome(); if (needToStop) break; } } Regards, Jaak PS: The documentation states that "On success the number of transmitted data is returned" by gnutls_record_uncork. Because the non-negative return value can't be reasonably used, maybe it were be better to state "On success, a non-negative number is returned". From nmav at gnutls.org Thu Dec 12 08:04:44 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Dec 2013 08:04:44 +0100 Subject: [gnutls-devel] Question about gnutls_record_uncork In-Reply-To: <52A5C48F.5030303@cyber.ee> References: <52A5B722.8010508@cyber.ee> <52A5C48F.5030303@cyber.ee> Message-ID: <1386831884.6039.4.camel@aspire.lan> On Mon, 2013-12-09 at 15:24 +0200, Jaak Ristioja wrote: > The use case is very complicated, but basically it needs to keep track > of whether all corked data has actually been sent or not. Using > GNUTLS_RECORD_WAIT is not an option for us, because in some cases the > underlying TCP buffers get full on both endpoints at the same time hence > causing a livelock (async. I/O, can't call gnutls_record_recv while the > other thread is in gnutls_record_uncork; both endpoints try to uncork at > the same time). > > What might help would be a function to return the value of the variable > session->internals.record_presend_buffer.length. However, I think I will > currently use something like this to work around the problem: I've added gnutls_record_check_corked() to check the amount of data present in the cork buffer, to be included in 3.2.8. That would not be of much use to you as you worked it around, but I there are indeed other use cases where such a function would simplify things. > PS: The documentation states that "On success the number of transmitted > data is returned" by gnutls_record_uncork. Because the non-negative > return value can't be reasonably used, maybe it were be better to state > "On success, a non-negative number is returned". I think that depends on the definition of success. I've made that more explicit now. regards, Nikos From mariusz.ornowski at ict-project.pl Thu Dec 12 11:11:26 2013 From: mariusz.ornowski at ict-project.pl (Mariusz Ornowski) Date: Thu, 12 Dec 2013 11:11:26 +0100 Subject: [gnutls-devel] BUG - Changes in 'struct sha1_ctx' and 'struct sha256_ctx' - nettle Message-ID: <52a98bcf.0524980a.60d2.ffffb682@mx.google.com> Hi, I tried to compile gnutls-3.2.7 using latest nettle (from git repository). Following errors had occurred: //=================================== sha-padlock.c: In function 'padlock_sha1_update': sha-padlock.c:80:2: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:80:2: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c:80:2: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:80:2: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha256_update': sha-padlock.c:87:2: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:87:2: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c:87:2: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:87:2: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha1_digest': sha-padlock.c:142:13: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:142:38: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c:143:12: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha256_digest': sha-padlock.c:164:13: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:164:38: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c:165:12: error: 'struct sha256_ctx' has no member named 'count_low' //=================================== I've looked into nettle log and I've found following change: //=================================== @@ -48,7 +48,7 @@ extern "C" { struct sha1_ctx { uint32_t state[_SHA1_DIGEST_LENGTH]; /* State variables */ - uint32_t count_low, count_high; /* 64-bit block count */ + uint64_t count; /* 64-bit block count */ uint8_t block[SHA1_DATA_SIZE]; /* SHA1 data buffer */ unsigned int index; /* index into buffer */ }; commit b8bfc32ff2fe1084614332bdda4d3b7805f62da0 Author: Niels M?ller Date: Fri Apr 26 10:28:57 2013 +0200 Use size_t rather than unsigned for all hash-related functions. //=================================== Probably this is the issue. Regards, Mariusz Ornowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Dec 12 12:11:52 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Dec 2013 12:11:52 +0100 Subject: [gnutls-devel] BUG - Changes in 'struct sha1_ctx' and 'struct sha256_ctx' - nettle In-Reply-To: <52a98bcf.0524980a.60d2.ffffb682@mx.google.com> References: <52a98bcf.0524980a.60d2.ffffb682@mx.google.com> Message-ID: On Thu, Dec 12, 2013 at 11:11 AM, Mariusz Ornowski wrote: > Hi, > I tried to compile gnutls-3.2.7 using latest nettle (from git repository). > Following errors had occurred: Hello Mariusz, The master branch of nettle has broken the API (and ABI). As it is not released yet it is pointless for gnutls to try to convert to the new API. You may use any of the released nettle versions. regards, Nikos From tim.krieger at posteo.de Thu Dec 12 22:45:45 2013 From: tim.krieger at posteo.de (Tim Krieger) Date: Thu, 12 Dec 2013 22:45:45 +0100 Subject: [gnutls-devel] internetbanking.gad.de Message-ID: <1386884745.1062.17.camel@localhost.localdomain> Hello, i'm not sure if my problem is related to gnutls. With epiphany (3.10.3, Arch Linux, gnutls 3.2.7.1) i can't access to: https://internetbanking.gad.de/ptlweb/WebPortal?bankid=4967 The server redirects me to: https://internetbanking.gad.de/ptlweb/pages/portalerror.html Internetbanking.gad.de is a famous german page for homebanking. Best regards Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Tue Dec 17 08:42:12 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Dec 2013 08:42:12 +0100 Subject: [gnutls-devel] internetbanking.gad.de In-Reply-To: <1386884745.1062.17.camel@localhost.localdomain> References: <1386884745.1062.17.camel@localhost.localdomain> Message-ID: <1387266132.1948.7.camel@aspire.lan> On Thu, 2013-12-12 at 22:45 +0100, Tim Krieger wrote: > Hello, > > i'm not sure if my problem is related to gnutls. > > With epiphany (3.10.3, Arch Linux, gnutls 3.2.7.1) i can't access to: > > https://internetbanking.gad.de/ptlweb/WebPortal?bankid=4967 > The server redirects me to: > https://internetbanking.gad.de/ptlweb/pages/portalerror.html Hello Tim, If you connect to the site and it can redirect you, then it cannot be a gnutls error. regards, Nikos From fedor.brunner at azet.sk Tue Dec 17 23:31:48 2013 From: fedor.brunner at azet.sk (Fedor Brunner) Date: Tue, 17 Dec 2013 23:31:48 +0100 Subject: [gnutls-devel] ChaCha20 and Poly1305 Message-ID: <52B0D0D4.3000700@azet.sk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, have you considered to implement ChaCha20 and Poly1305 based Cipher Suites in GnuTLS? https://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.html ChaCha20 is a stream cipher developed by D. J. Bernstein. It is a refinement of Salsa20 and was used as the core of the SHA-3 finalist, BLAKE. ChaCha20 and Poly1305 for TLS will be supported in Chrome, Google servers and probably will be supported also in Android, so many clients and servers. OpenSSH also supports ChaCha20 and Poly1305 http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html Regards, Fedor -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSsNDUAAoJEG4XQJVAVmOtg5wP/28RyvntbhSC36LEw4FTs7fR 1LGSvcKB0lRGQ8vK7xLBiMzv+FLYXz/+HLO2dDqA+DORdHzYEbZaDeFbrpdNYTFJ KT+GBJsX8NtxP/dXrWvW8F3Pt4v2jgYZGlu27cLNv5aOeF38pHE2ZBi9KA5Oifx4 iRLW50s6+OWMcN1gB8j61S/WatVg2HSLsvMTvX0RyGrua8aZJAreTyRvib2Es0BN fjJ7r/RKORmFUa05DEPhqYR6sK1bOBQgnHRGG2EwWXMX/KncbgVoECGz3v9OESnh Jtid0Oe0RYKxaE43VE4b5hW0jOPvvfYTXtFwd5+IU6XmxK/D8CIxHoiv/SkAuAZ8 wu6Nltdz8TyNzq3zdJf9G+G7DtkH+Pp/2zAR6FxwBeVc7OT6LzfZ620jhOYUVdmw 3AdjbBSAjzA40YmclNaywWXiKTU3TlElU0OWjvMeFcwXWDHbzA+SvFmnGLsD4ofo EB4gp/cLvVse91tuEsZXz1YfHa/gjka3WWiC8iqkW4OfiW566qn74ZltQYlhd6/3 kh0/x90iE3m1MYyUZBiozsi0JZKsk4I5pvPZvM2iu7DiJLmxz5LIRArAMTW27sKn CuD0SHqR+eKtrcTN9SLxVQ+640hDeAmBdUxIthGs7IZ8U4WaNIjE2qatgieLC4YF M4H5QZe8zvrVe4dJuPDo =7C4+ -----END PGP SIGNATURE----- From hongyi.zhao at gmail.com Fri Dec 20 13:53:18 2013 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Fri, 20 Dec 2013 20:53:18 +0800 Subject: [gnutls-devel] The issue when compiling gnutls-3.2.6. Message-ID: Hi all, I use Debian Wheezy, and downloading the gnutls-3.2.6 from here: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz When I compile it with make, I meet the following error: --------- CCLD psktool ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_crypt' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_update' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_nonce' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_set_nonce' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_set_key' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_digest' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20_set_iv' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac128_digest' ../lib/.libs/libgnutls.so: undefined reference to `nettle_salsa20r12_crypt' ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_update' collect2: error: ld returned 1 exit status make[4]: *** [psktool] Error 1 --------- Any hints? Thanks -- Hongyi Zhao Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Dec 20 16:06:26 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 20 Dec 2013 10:06:26 -0500 Subject: [gnutls-devel] The issue when compiling gnutls-3.2.6. In-Reply-To: References: Message-ID: <52B45CF2.1000800@fifthhorseman.net> On 12/20/2013 07:53 AM, Hongyi Zhao wrote: > I use Debian Wheezy, and downloading the gnutls-3.2.6 from here: > > ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz > > When I compile it with make, I meet the following error: > > --------- > CCLD psktool > ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key' [...] hi there! According to m4/hooks.m4, it looks like you need nettle >= 2.7. Debian wheezy has nettle 2.4-3. What version of nettle do you have installed? It looks to me like wheezy-backports has 2.7.1-1~bpo70+1 -- perhaps you could upgrade nettle-dev to the version in wheezy backports and try re-building? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Fri Dec 20 19:46:21 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Dec 2013 19:46:21 +0100 Subject: [gnutls-devel] gnutls 3.2.8 Message-ID: <1387565181.12920.2.camel@aspire.lan> Hello, I've just released gnutls 3.2.8. This release fixes bugs, adds optimizations and some few new features on next stable branch. * Version 3.2.8 (released 2013-12-20) ** libgnutls: Updated code for AES-NI. That prevents an uninitialized variable complaint from valgrind. ** libgnutls: Enforce a maximum size for DH primes. ** libgnutls: Added SSSE3 optimized SHA1, and SHA256, using Andy Polyakov's code. ** libgnutls: Added SSSE3 optimized AES using Mike Hamburg's code. ** libgnutls: It only links to librt if the required functions are not present in libc. This also prevents an indirect linking to libpthread. ** libgnutls: Fixed issue with gnulib strerror replacement by adding the strerror gnulib module. ** libgnutls: The time provided in the TLS random values is only precise on its first 3 bytes. That prevents leakage of the precise system time (at least on the client side when only few connections are done on a single server). ** certtool: The --verify option will use the system CAs if the load-ca-certificate option is not provided. ** configure: Added option --with-default-blacklist-file to allow specifying a certificate blacklist file. ** configure: Added --disable-non-suiteb-curves option. This option restricts the supported curves to SuiteB curves. ** API and ABI modifications: gnutls_record_check_corked: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.8.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Dec 20 19:47:42 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Dec 2013 19:47:42 +0100 Subject: [gnutls-devel] gnutls 3.1.18 Message-ID: <1387565262.12920.4.camel@aspire.lan> Hello, I've just released gnutls 3.1.18. This is a bug fix release on the current stable branch. * Version 3.1.18 (released 2013-12-20) ** libgnutls: Updated code for AES-NI. That prevents an uninitialized variable complaint from valgrind. ** libgnutls: Enforce a maximum size for DH primes. ** configure: Added option --with-default-blacklist-file to allow specifying a certificate blacklist file. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.18.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Fri Dec 20 23:03:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Dec 2013 23:03:48 +0100 Subject: [gnutls-devel] ChaCha20 and Poly1305 Message-ID: <1387577028.17365.10.camel@aspire.lan> > Hi, > have you considered to implement ChaCha20 and Poly1305 based Cipher > Suites in GnuTLS? > https://tools.ietf.org/id/draft-agl-tls-chacha20poly1305-04.html > ChaCha20 is a stream cipher developed by D. J. Bernstein. It is a > refinement of Salsa20 and was used as the core of the SHA-3 finalist, > BLAKE. [for some reason this was tagged as spam and I missed it] Hello, We already have salsa20 as an experimental cipher, and even a poly-mac version with UMAC-96 (see [0] and its 03 version). We proposed it to IETF, earlier this year, but as you see other different proposals followed. We will certainly add any ciphersuite accepted by the TLS working group but I don't see any point into adding more experimental ciphersuites. We'll reconsider of course if the TLS WG doesn't decide on the topic. regards, Nikos [0]. http://tools.ietf.org/html/draft-josefsson-salsa20-tls-04 From nmav at gnutls.org Sat Dec 21 12:37:14 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Dec 2013 12:37:14 +0100 Subject: [gnutls-devel] gnutls 3.2.8 In-Reply-To: <1387565181.12920.2.camel@aspire.lan> References: <1387565181.12920.2.camel@aspire.lan> Message-ID: <1387625834.2690.7.camel@aspire.lan> On Fri, 2013-12-20 at 19:46 +0100, Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 3.2.8. This release fixes bugs, adds > optimizations and some few new features on next stable branch. Note, that I've realized that this release has issues with the assembly files in win32 and macosx systems. In these systems use gnutls 3.2.8.1. regards, Nikos From hongyi.zhao at gmail.com Sat Dec 21 13:53:30 2013 From: hongyi.zhao at gmail.com (Hongyi Zhao) Date: Sat, 21 Dec 2013 20:53:30 +0800 Subject: [gnutls-devel] The issue when compiling gnutls-3.2.6. In-Reply-To: <52B45CF2.1000800@fifthhorseman.net> References: <52B45CF2.1000800@fifthhorseman.net> Message-ID: On Fri, 20 Dec 2013 10:06:26 -0500, Daniel Kahn Gillmor wrote: > hi there! According to m4/hooks.m4, it looks like you need nettle >= > 2.7. Debian wheezy has nettle 2.4-3. I installed the nettle-2.7.1 compiled by myself. > > What version of nettle do you have installed? See the following info: werner at debian-asus:~$ nettle-hash --version nettle-hash (nettle 2.7.1) > > It looks to me like wheezy-backports has 2.7.1-1~bpo70+1 -- perhaps you > could upgrade nettle-dev to the version in wheezy backports and try > re-building? If I installed the self compiled version of nettle 2.7.1 from source, how should I tell the guntls use the corresponding nettle-dev files instead of the older versions? Regards -- .: Hongyi Zhao [ hongyi.zhao AT gmail.com ] Free as in Freedom :. 2013/12/20 Daniel Kahn Gillmor > On 12/20/2013 07:53 AM, Hongyi Zhao wrote: > > I use Debian Wheezy, and downloading the gnutls-3.2.6 from here: > > > > ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.6.tar.xz > > > > When I compile it with make, I meet the following error: > > > > --------- > > CCLD psktool > > ../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key' > > [...] > > hi there! According to m4/hooks.m4, it looks like you need nettle >= > 2.7. Debian wheezy has nettle 2.4-3. > > What version of nettle do you have installed? > > It looks to me like wheezy-backports has 2.7.1-1~bpo70+1 -- perhaps you > could upgrade nettle-dev to the version in wheezy backports and try > re-building? > > Regards, > > --dkg > > -- Hongyi Zhao Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sat Dec 21 20:39:13 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 21 Dec 2013 14:39:13 -0500 Subject: [gnutls-devel] The issue when compiling gnutls-3.2.6. In-Reply-To: References: <52B45CF2.1000800@fifthhorseman.net> Message-ID: <52B5EE61.7000608@fifthhorseman.net> On 12/21/2013 07:53 AM, Hongyi Zhao wrote: > I installed the nettle-2.7.1 compiled by myself. Is there a reason to avoid the version installed from wheezy-backports? > werner at debian-asus:~$ nettle-hash --version > nettle-hash (nettle 2.7.1) and where are these tools installed? are they in /usr/local/ someplace, or in your home directory? > If I installed the self compiled version of nettle 2.7.1 from source, how > should I tell the guntls use the corresponding nettle-dev files instead > of the older versions? it looks to me like gnutls finds the paths for nettle based on the output of pkg-config, which itself uses the .pc files stored (on debian at least) in /usr/lib/$archtriple/pkgconfig/*.pc (e.g. $archtriple might be x86_64-linux-gnu). Is it possible that your local nettle compilation failed to place a *.pc file someplace that pkgconfig would prefer it over your system-installed nettle.pc and hogweed.pc? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From alon.barlev at gmail.com Sun Dec 22 20:47:56 2013 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 22 Dec 2013 21:47:56 +0200 Subject: [gnutls-devel] [PATCH] build: fix librt requirement Message-ID: <1387741676-685-1-git-send-email-alon.barlev@gmail.com> The librt is added by the gl m4 macros, AC_CHECK_FUNCS to will not fail to find functions. Move the AC_CHECK_FUNCS above gl initialization. Signed-off-by: Alon Bar-Lev --- configure.ac | 73 ++++++++++++++++++++++++++++++++---------------------------- 1 file changed, 39 insertions(+), 34 deletions(-) diff --git a/configure.ac b/configure.ac index fadb954..b8eefc2 100644 --- a/configure.ac +++ b/configure.ac @@ -149,6 +149,45 @@ AM_GNU_GETTEXT_VERSION([0.18]) AC_C_BIGENDIAN +dnl No fork on MinGW, disable some self-tests until we fix them. +dnl Check clock_gettime and pthread_mutex_lock in libc (avoid linking to other libs) +AC_CHECK_FUNCS([fork getrusage getpwuid_r nanosleep daemon getpid clock_gettime pthread_mutex_lock iconv localtime vasprintf],,) +AM_CONDITIONAL(HAVE_FORK, test "$ac_cv_func_fork" != "no") + +AC_LIB_HAVE_LINKFLAGS(rt,, [#include +#include +], [timer_create (0,0,0);]) + +if test "$ac_cv_func_pthread_mutex_lock" != "yes";then + AC_LIB_HAVE_LINKFLAGS(pthread,, [#include ], [pthread_mutex_lock (0);]) +fi + +if test "$ac_cv_func_nanosleep" != "yes";then + AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [nanosleep (0, 0);]) + gnutls_needs_librt=yes +fi + +if test "$ac_cv_func_clock_gettime" != "yes";then + AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [clock_gettime (0, 0);]) + gnutls_needs_librt=yes +fi + +ac_have_unicode=no +if test "$ac_cv_func_iconv" != "yes";then + AC_LIB_HAVE_LINKFLAGS(iconv,, [#include ], [iconv (0, 0, 0, 0, 0);]) + if test "$HAVE_LIBICONV" = "yes";then + ac_have_unicode=yes + fi +else + ac_have_unicode=yes +fi + +if test "$ac_have_unicode" != "yes";then + if test "$have_win" = "yes";then + ac_have_unicode=yes + fi +fi + gl_INIT ggl_INIT @@ -224,40 +263,6 @@ AC_LIBTOOL_WIN32_DLL AC_PROG_LIBTOOL -dnl No fork on MinGW, disable some self-tests until we fix them. -dnl Check clock_gettime and pthread_mutex_lock in libc (avoid linking to other libs) -AC_CHECK_FUNCS([fork getrusage getpwuid_r nanosleep daemon getpid clock_gettime pthread_mutex_lock iconv localtime vasprintf],,) -AM_CONDITIONAL(HAVE_FORK, test "$ac_cv_func_fork" != "no") - -AC_LIB_HAVE_LINKFLAGS(rt,, [#include -#include -], [timer_create (0,0,0);]) - -if test "$ac_cv_func_pthread_mutex_lock" != "yes";then - AC_LIB_HAVE_LINKFLAGS(pthread,, [#include ], [pthread_mutex_lock (0);]) -fi - -if test "$ac_cv_func_nanosleep" != "yes";then - AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [nanosleep (0, 0);]) - gnutls_needs_librt=yes -fi - -ac_have_unicode=no -if test "$ac_cv_func_iconv" != "yes";then - AC_LIB_HAVE_LINKFLAGS(iconv,, [#include ], [iconv (0, 0, 0, 0, 0);]) - if test "$HAVE_LIBICONV" = "yes";then - ac_have_unicode=yes - fi -else - ac_have_unicode=yes -fi - -if test "$ac_have_unicode" != "yes";then - if test "$have_win" = "yes";then - ac_have_unicode=yes - fi -fi - AC_MSG_CHECKING([whether to build libdane]) AC_ARG_ENABLE(libdane, AS_HELP_STRING([--disable-libdane], -- 1.8.3.2 From alon.barlev at gmail.com Sun Dec 22 20:49:18 2013 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 22 Dec 2013 21:49:18 +0200 Subject: [gnutls-devel] [PATCH] build: fix librt requirement In-Reply-To: <1387741676-685-1-git-send-email-alon.barlev@gmail.com> References: <1387741676-685-1-git-send-email-alon.barlev@gmail.com> Message-ID: Please see[1] [1] https://bugs.gentoo.org/show_bug.cgi?id=494940 On Sun, Dec 22, 2013 at 9:47 PM, Alon Bar-Lev wrote: > The librt is added by the gl m4 macros, AC_CHECK_FUNCS to will not fail > to find functions. > > Move the AC_CHECK_FUNCS above gl initialization. > > Signed-off-by: Alon Bar-Lev > --- > configure.ac | 73 > ++++++++++++++++++++++++++++++++---------------------------- > 1 file changed, 39 insertions(+), 34 deletions(-) > > diff --git a/configure.ac b/configure.ac > index fadb954..b8eefc2 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -149,6 +149,45 @@ AM_GNU_GETTEXT_VERSION([0.18]) > > AC_C_BIGENDIAN > > +dnl No fork on MinGW, disable some self-tests until we fix them. > +dnl Check clock_gettime and pthread_mutex_lock in libc (avoid linking to > other libs) > +AC_CHECK_FUNCS([fork getrusage getpwuid_r nanosleep daemon getpid > clock_gettime pthread_mutex_lock iconv localtime vasprintf],,) > +AM_CONDITIONAL(HAVE_FORK, test "$ac_cv_func_fork" != "no") > + > +AC_LIB_HAVE_LINKFLAGS(rt,, [#include > +#include > +], [timer_create (0,0,0);]) > + > +if test "$ac_cv_func_pthread_mutex_lock" != "yes";then > + AC_LIB_HAVE_LINKFLAGS(pthread,, [#include ], > [pthread_mutex_lock (0);]) > +fi > + > +if test "$ac_cv_func_nanosleep" != "yes";then > + AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [nanosleep (0, 0);]) > + gnutls_needs_librt=yes > +fi > + > +if test "$ac_cv_func_clock_gettime" != "yes";then > + AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [clock_gettime (0, 0);]) > + gnutls_needs_librt=yes > +fi > + > +ac_have_unicode=no > +if test "$ac_cv_func_iconv" != "yes";then > + AC_LIB_HAVE_LINKFLAGS(iconv,, [#include ], [iconv (0, 0, 0, 0, > 0);]) > + if test "$HAVE_LIBICONV" = "yes";then > + ac_have_unicode=yes > + fi > +else > + ac_have_unicode=yes > +fi > + > +if test "$ac_have_unicode" != "yes";then > + if test "$have_win" = "yes";then > + ac_have_unicode=yes > + fi > +fi > + > gl_INIT > ggl_INIT > > @@ -224,40 +263,6 @@ AC_LIBTOOL_WIN32_DLL > AC_PROG_LIBTOOL > > > -dnl No fork on MinGW, disable some self-tests until we fix them. > -dnl Check clock_gettime and pthread_mutex_lock in libc (avoid linking to > other libs) > -AC_CHECK_FUNCS([fork getrusage getpwuid_r nanosleep daemon getpid > clock_gettime pthread_mutex_lock iconv localtime vasprintf],,) > -AM_CONDITIONAL(HAVE_FORK, test "$ac_cv_func_fork" != "no") > - > -AC_LIB_HAVE_LINKFLAGS(rt,, [#include > -#include > -], [timer_create (0,0,0);]) > - > -if test "$ac_cv_func_pthread_mutex_lock" != "yes";then > - AC_LIB_HAVE_LINKFLAGS(pthread,, [#include ], > [pthread_mutex_lock (0);]) > -fi > - > -if test "$ac_cv_func_nanosleep" != "yes";then > - AC_LIB_HAVE_LINKFLAGS(rt,, [#include ], [nanosleep (0, 0);]) > - gnutls_needs_librt=yes > -fi > - > -ac_have_unicode=no > -if test "$ac_cv_func_iconv" != "yes";then > - AC_LIB_HAVE_LINKFLAGS(iconv,, [#include ], [iconv (0, 0, 0, 0, > 0);]) > - if test "$HAVE_LIBICONV" = "yes";then > - ac_have_unicode=yes > - fi > -else > - ac_have_unicode=yes > -fi > - > -if test "$ac_have_unicode" != "yes";then > - if test "$have_win" = "yes";then > - ac_have_unicode=yes > - fi > -fi > - > AC_MSG_CHECKING([whether to build libdane]) > AC_ARG_ENABLE(libdane, > AS_HELP_STRING([--disable-libdane], > -- > 1.8.3.2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Dec 23 11:33:13 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Dec 2013 11:33:13 +0100 Subject: [gnutls-devel] [PATCH] build: fix librt requirement In-Reply-To: <1387741676-685-1-git-send-email-alon.barlev@gmail.com> References: <1387741676-685-1-git-send-email-alon.barlev@gmail.com> Message-ID: On Sun, Dec 22, 2013 at 8:47 PM, Alon Bar-Lev wrote: > The librt is added by the gl m4 macros, AC_CHECK_FUNCS to will not fail > to find functions. > > Move the AC_CHECK_FUNCS above gl initialization. > Applied. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at zacarias.com.ar Thu Dec 26 17:13:03 2013 From: gustavo at zacarias.com.ar (Gustavo Zacarias) Date: Thu, 26 Dec 2013 13:13:03 -0300 Subject: [gnutls-devel] [PATCH] Add LIB_CLOCK_GETTIME to crywrap Message-ID: <1388074383-6080-1-git-send-email-gustavo@zacarias.com.ar> It's used indirectly thus causing build breakage on versions of glibc where it's defined in librt rather than libc directly. Signed-off-by: Gustavo Zacarias --- src/crywrap/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/crywrap/Makefile.am b/src/crywrap/Makefile.am index ca41259..d86ca55 100644 --- a/src/crywrap/Makefile.am +++ b/src/crywrap/Makefile.am @@ -29,3 +29,4 @@ bin_PROGRAMS = crywrap crywrap_SOURCES = crywrap.c primes.h crywrap.h crywrap_LDADD = ../../lib/libgnutls.la $(LIBIDN_LIBS) #../../gl/libgnu.la +crywrap_LDADD += $(LIB_CLOCK_GETTIME) -- 1.8.3.2 From nmav at gnutls.org Fri Dec 27 10:36:33 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 27 Dec 2013 10:36:33 +0100 Subject: [gnutls-devel] [PATCH] Add LIB_CLOCK_GETTIME to crywrap In-Reply-To: <1388074383-6080-1-git-send-email-gustavo@zacarias.com.ar> References: <1388074383-6080-1-git-send-email-gustavo@zacarias.com.ar> Message-ID: <1388136993.2030.8.camel@aspire.lan> On Thu, 2013-12-26 at 13:13 -0300, Gustavo Zacarias wrote: > It's used indirectly thus causing build breakage on versions of glibc > where it's defined in librt rather than libc directly. Applied, thank you. From ametzler at bebt.de Fri Dec 27 15:22:21 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 27 Dec 2013 15:22:21 +0100 Subject: [gnutls-devel] xssl exports unneeded symbols Message-ID: <20131227142221.GC3199@downhill.g.la> Hello, gnutls-xssl exports loads of symbols (e.g. _gnutls_*, base64_encode), I guess this shouldn't hurt: --- gnutls28-3.2.8.1.orig/lib/Makefile.am +++ gnutls28-3.2.8.1/lib/Makefile.am @@ -191,7 +191,7 @@ pkix_asn1_tab.c: $(srcdir)/pkix.asn gnutls_asn1_tab.c: $(srcdir)/gnutls.asn -asn1Parser $(srcdir)/gnutls.asn gnutls_asn1_tab.c -libgnutls_xssl_la_LDFLAGS = -no-undefined +libgnutls_xssl_la_LDFLAGS = -no-undefined -export-symbols-regex '^xssl.*' cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sat Dec 28 07:59:14 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 Dec 2013 07:59:14 +0100 Subject: [gnutls-devel] xssl exports unneeded symbols In-Reply-To: <20131227142221.GC3199@downhill.g.la> References: <20131227142221.GC3199@downhill.g.la> Message-ID: <1388213954.9389.0.camel@aspire.lan> On Fri, 2013-12-27 at 15:22 +0100, Andreas Metzler wrote: > Hello, > > gnutls-xssl exports loads of symbols (e.g. _gnutls_*, base64_encode), > I guess this shouldn't hurt: > -libgnutls_xssl_la_LDFLAGS = -no-undefined > +libgnutls_xssl_la_LDFLAGS = -no-undefined -export-symbols-regex '^xssl.*' Thanks, applied. Nikos From ott at mirix.org Sat Dec 28 14:16:52 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Sat, 28 Dec 2013 14:16:52 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <529E653A.8070309@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> Message-ID: <52BECF44.7060606@mirix.org> On 12/04/13 00:11, Matthias-Christian Ott wrote: > On 2013-12-03 23:20, Daniel Kahn Gillmor wrote: >> What do folks think about this idea? > > +1 I thought about this for some time and want to revise my position. There are three categories of cipher suites: insecure, possibly insecure and secure. At the moment a software developer or administrator categorises the available cipher suites as either insecure (drop connection) or secure (accept connection). Daniel proposed to add at least another category: possibly insecure/low security margin. If the cipher suite is in this category the application accepts the connection, but displays only data with a low confidentiality level or something similar to limit the damage in case of a MITM attack. The scenario I had in mind was the following: The application has a client-server architecture. The server has all the data and is operated by security-concious people (e.g. a web server of a bank). However, these people have no control over the client (e.g. a web browser). The client only supports cipher suites in the possibly insecure category. Instead of dropping the connection and letting the client display an for a user not understandable generic message (e.g. ?connection dropped, no common cipher suites?), the server accepts the connection, but displays a detailed warning and perhaps allows limited access to the data. Now suppose the chosen cipher suite is insecure and an attacker can perform an active MITM attack. Then the attacker can read the limited data, which was already anticipated and is part of the risk model. On a website the attacker can also prompt the user for credentials, which the user will supply because she or he saw the padlock in the address bar and thinks the connection is secure. This may nor may not work with native applications (depends on the protocol). If the TLS connection uses PKIX, the current PKIX system works, no attacker can be issued a fake certificates and all cipher suites in the possibly insecure category only include weak symmetric cryptographic primitives, this attack could have been prevented by dropping the connection when only cipher suites from the possibly insecure category are available. To summarise: I think the idea makes only sense for a few organisations. The situations in which I would recommend to implement this idea are as follows: Your application has a client-server architecture. You run the server and the server has all data. Interoperability with client software that supports only cipher suites from the possibly insecure category is more important than security to your organisation. You think that displaying a warning message instead of dropping the connection is of great benefit to your organisation (increased sales, fewer support calls), because too many clients run software that only support possibly insecure cipher suites, and a MITM attack is a low risk scenario for you (in comparison to the benefits). A typical example would be a retail company which fears decreased sales if they don't support some older web browser version. For everything else it makes little or no sense, especially if a user's privacy is at risk or you run the server as a private person. I would rather implement this directly in the web application instead of GnuTLS (I can't think of a native application where you could display a warning) and would be even stricter than GnuTLS is currently in all other cases (only support high security cipher suites and key lengths and TLS 1.2 or later etc.) instead of categorising cipher suites. Regards, Matthias-Christian From ott at mirix.org Sat Dec 28 14:20:09 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Sat, 28 Dec 2013 14:20:09 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <529F3EF3.6060401@fifthhorseman.net> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <529F3EF3.6060401@fifthhorseman.net> Message-ID: <52BED009.4050508@mirix.org> On 12/04/13 15:40, Daniel Kahn Gillmor wrote: > On 12/03/2013 06:11 PM, Matthias-Christian Ott wrote: >> In mod_gnutls, mod_ssl and nginx, you could implement this as a library >> that reads environment variables of the request (e.g. SSL_CIPHER in >> mod_gnutls and mod_ssl) and computes the security from this ? no patches >> for TLS libraries required. For other types of software this could be >> implemented as a separate library as well. > > i don't think you can do this. For example, SSL_CIPHER doesn't expose > the number of bits in the DHE key exchange handshake. Also, the > underlying TLS library could itself add new features that this > hypothetical external library doesn't know anything about. You could a variables for the asymmetric key lengths and of course you have keep both libraries in sync (SSL_VERSION_LIBRARY will allow you to adapt to different versions of the TLS library). Regards, Matthias-Christian From ametzler at bebt.de Sat Dec 28 14:55:12 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 28 Dec 2013 14:55:12 +0100 Subject: [gnutls-devel] dane - limited usability die to (indirect) OpenSSL dependency Message-ID: <20131228135512.GB3225@downhill.g.la> Hello, I do not know whether you are aware of it but distributing libgnutls-dane does not make a lot of sense currently: (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.2.8/libdane$ objdump -p .libs/libgnutls-dane.so | grep '^ *NEED' NEEDED libgnutls.so.28 NEEDED libunbound.so.2 NEEDED libc.so.6 (SID)ametzler at argenau:/tmp/GNUTLS/gnutls-3.2.8/libdane$ objdump -p /usr/lib/i386-linux-gnu/libunbound.so.2 | grep '^ *NEED' NEEDED libssl.so.1.0.0 NEEDED libldns.so.1 NEEDED libdl.so.2 NEEDED libcrypto.so.1.0.0 NEEDED libpthread.so.0 NEEDED libc.so.6 gnutls is LGPLv2.1+ (with a LGPLv3+ dependency), libunbound seems to be BSD-ish (3-clause) but depends on OpenSSL. (Debian binary distribution.) As a curiosity there is also danetool(1) which is GPLv3+ and therefore may not[1] be distributed linked against OpenSSL. Apart from the licensing issue it is imho more than a little bit ugly that software using libgnutls-dane links against both GnuTLS and OpenSSL. Checking unbound's ./configure I see that it could also be built against NSS instead of OpenSSL. This would get rid of the OpenSSL license problem, but still any libgnutls-dane user would depend on not only one, but two of the three major TLS toolkits. cu Andreas [1] I am aware that there are divided opinions on this subject. e.g. Fedora uses the system library exeption clause for OpenSSL. But e.g. Debian has always tried to not ship GPL software linked against OpenSSL and although this might change would not count on it. -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sat Dec 28 15:34:18 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 Dec 2013 15:34:18 +0100 Subject: [gnutls-devel] dane - limited usability die to (indirect) OpenSSL dependency In-Reply-To: <20131228135512.GB3225@downhill.g.la> References: <20131228135512.GB3225@downhill.g.la> Message-ID: <1388241258.14170.10.camel@aspire.lan> On Sat, 2013-12-28 at 14:55 +0100, Andreas Metzler wrote: > Hello, > Apart from the licensing issue it is imho more than a little bit ugly > that software using libgnutls-dane links against both GnuTLS and > OpenSSL. > Checking unbound's ./configure I see that it could also be built > against NSS instead of OpenSSL. This would get rid of the OpenSSL > license problem, but still any libgnutls-dane user would depend on not > only one, but two of the three major TLS toolkits. Hello Andreas, I understand that and this was the reason libgnutls-dane was made a separate library. On my part I don't think there is much I can do. Libunbound is the only dnssec library I could find, so switching to another isn't (currently) an option. At the time adding this support I thought that having support for DANE was more important than linking and dependency issues. > [1] I am aware that there are divided opinions on this subject. e.g. > Fedora uses the system library exeption clause for OpenSSL. > > But e.g. Debian has always tried to not ship GPL software linked > against OpenSSL and although this might change would not count on it. I understand Debian's approach but I cannot think of anything I could do in gnutls-dane to solve that. While I'd be happy to drop unbound and use another library for dnssec resolving, I know of no other alternatives. regards, Nikos From nmav at gnutls.org Sat Dec 28 15:39:25 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 Dec 2013 15:39:25 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52BED009.4050508@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <529F3EF3.6060401@fifthhorseman.net> <52BED009.4050508@mirix.org> Message-ID: <1388241565.14170.14.camel@aspire.lan> On Sat, 2013-12-28 at 14:20 +0100, Matthias-Christian Ott wrote: > > i don't think you can do this. For example, SSL_CIPHER doesn't expose > > the number of bits in the DHE key exchange handshake. Also, the > > underlying TLS library could itself add new features that this > > hypothetical external library doesn't know anything about. > You could a variables for the asymmetric key lengths and of course you > have keep both libraries in sync (SSL_VERSION_LIBRARY will allow you to > adapt to different versions of the TLS library). There many more details that only the crypto library knows. The high level applications should be able to set the security policy, but they shouldn't be expected to find out all the details of the session by themselves (why should an application developer know about DH and the sizes of the prime, or the sub-group sizes?). regards, Nikos From ametzler at bebt.de Sat Dec 28 17:43:52 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 28 Dec 2013 17:43:52 +0100 Subject: [gnutls-devel] dane - limited usability die to (indirect) OpenSSL dependency In-Reply-To: <1388241258.14170.10.camel@aspire.lan> References: <20131228135512.GB3225@downhill.g.la> <1388241258.14170.10.camel@aspire.lan> Message-ID: <20131228164352.GA3186@downhill.g.la> On 2013-12-28 Nikos Mavrogiannopoulos wrote: [...] > Hello Andreas, > I understand that and this was the reason libgnutls-dane was made a > separate library. On my part I don't think there is much I can do. > Libunbound is the only dnssec library I could find, so switching to > another isn't (currently) an option. [...] > I understand Debian's approach but I cannot think of anything I could do > in gnutls-dane to solve that. While I'd be happy to drop unbound and use > another library for dnssec resolving, I know of no other alternatives. Hello Nikos, good to know that you were aware of this from the start on. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From andreas at enge.fr Sat Dec 28 11:26:41 2013 From: andreas at enge.fr (Andreas Enge) Date: Sat, 28 Dec 2013 11:26:41 +0100 Subject: [gnutls-devel] Dependency of gnutls-dane on openssl? Message-ID: <20131228102641.GA20686@debian> Hello, gnutls as currently packaged for guix, the gnu system, issues the following warning at configuration: *** libunbound was not found. Libdane will not be built. I tried to build libunbound, but it depends on "SSL", which I take to mean openssl. If this is true, then gnutls with dane support would depend on openssl, which would be an absurd situation. Do you see an easy solution? Andreas From ametzler at bebt.de Sun Dec 29 13:28:44 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 29 Dec 2013 13:28:44 +0100 Subject: [gnutls-devel] Dependency of gnutls-dane on openssl? In-Reply-To: <20131228102641.GA20686@debian> References: <20131228102641.GA20686@debian> Message-ID: <20131229122843.GA3239@downhill.g.la> On 2013-12-28 Andreas Enge wrote: > gnutls as currently packaged for guix, the gnu system, issues the following > warning at configuration: > *** libunbound was not found. Libdane will not be built. > I tried to build libunbound, but it depends on "SSL", which I take to > mean openssl. If this is true, then gnutls with dane support would depend > on openssl, which would be an absurd situation. > Do you see an easy solution? No, not really. See yesterday's thread. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From dkg at fifthhorseman.net Mon Dec 30 22:37:54 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 30 Dec 2013 16:37:54 -0500 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52BECF44.7060606@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> Message-ID: <52C1E7B2.7000200@fifthhorseman.net> On 12/28/2013 08:16 AM, Matthias-Christian Ott wrote: > There are three categories of cipher suites: insecure, possibly insecure > and secure. At the moment a software developer or administrator > categorises the available cipher suites as either insecure (drop > connection) or secure (accept connection). Daniel proposed to add at > least another category: possibly insecure/low security margin. i think this might be a mischaracterization of what i was proposing. My main point was that TLS is a complex security protocol, with many possible variants and modifications. We cannot expect application authors to know in detail about every possible knob or tweak available to the TLS stack. Indeed, as TLS itself evolves, the application may have even bee written against an implementation of TLS that was unaware of certain knobs or settings. In practice, the authors of a TLS library will often know much more about the TLS stack itself than the application authors will know. So as authors of a TLS library, we really should provide a *simple* interface that provides an application author with a rough estimate of our belief about the strength of the weakest link, without requiring the application authors to be experts in the nuances of TLS. (for application authors who happen to actually be experts in the nuances of TLS, we should of course continue to provide decent access to the full parameters of the TLS session, and useful ways to control them; but we shouldn't require this kind of knowledge of our users). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From ott at mirix.org Tue Dec 31 00:52:55 2013 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 31 Dec 2013 00:52:55 +0100 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C1E7B2.7000200@fifthhorseman.net> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> Message-ID: <52C20757.2020902@mirix.org> On 12/30/13 22:37, Daniel Kahn Gillmor wrote: > On 12/28/2013 08:16 AM, Matthias-Christian Ott wrote: >> There are three categories of cipher suites: insecure, possibly insecure >> and secure. At the moment a software developer or administrator >> categorises the available cipher suites as either insecure (drop >> connection) or secure (accept connection). Daniel proposed to add at >> least another category: possibly insecure/low security margin. > > i think this might be a mischaracterization of what i was proposing. My > main point was that TLS is a complex security protocol, with many > possible variants and modifications. I would rather say it was a misunderstanding and if it was a mischaracterisation, it was not deliberate. Let me see if I get it right this time. What you are saying is the following: In addition to gnutls_priority_set_direct (OpenSSL has something similar), which has some categories for cipher suites, you want to estimate the security of the negotiated security parameters? Either the parameters are secure and you allow the connection or they aren't and you drop the connection. I'm a bit confused. gnutls_priority_set_direct with perhaps some more keywords seems to be exactly what you want. An application developer calls gnutls_priority_set_direct or uses the defaults which should be secure (although this is debatable) and GnuTLS enforces a specific security level where a lot of parameters are controllable by ?TLS experts?. I think you can't make it simpler than doing nothing and using the defaults. I would rather find it more useful if GnuTLS had keywords for certain standards and regulatory institutions built-in. At a previous job we had to conform to a privacy policy. Nobody could tell me what some data security requirements meant in terms of concrete key lengths and cryptographic primitives, so I decided to use the recommendations of the BSI and BNetzA as they seem legally authoritative for Germany. It required me to find, read and translate their documents into an OpenSSL cipher list and to choose the key lengths accordingly. When new recommendations are available, I would have to repeat this procedure. I would prefer it if GnuTLS had a keyword BSI or something similar to always conform to the latest recommendation (other systems administrators I know who run TLS protected web sites don't even know what a key length or a certain cipher is (sic!) and probably wouldn't make any efforts to comply with the recommendations). keylength.com lists other recommendations of other institutions that might be relevant. Also GnuTLS already has some Suite B support. Because of different software versions, TLS implementations and especially proprietary software, it is also very difficult to agree on a safe default cipher suite list and security parameters. One user might need compatibility with SChannel or OpenSSL from 10 years ago because her or his employer uses software that needs to be compatible while another user wants only ciphers and parameters that are secure by today's standards. I would like to see that GnuTLS only enables PFS and HIGH or ULTRA security parameters by default, but unless you control all software that is part of your distributed system that uses TLS that's not feasible and will only lead to system administrators searching for copy & paste solutions on the web which they don't understand (believe me, if seen grotesque situations with IPv6, where people disable it because they don't understand it or think that it's ?insecure? because there is commonly no NAT and other things). This probably has been discussed in the TLS WG as TLS heavily relies on cryptographic agility and questionable cipher suites are still not deprecated. What I understand from Adam Langley's discussion of this issue is that it heavily depends on other stakeholders involved (not just the implementors of one TLS implementation) and on the operating environment you use TLS in (using only GnuTLS in our internal application software is not the same as serving your website or providing e-mail access to your customers ? try explaining an average customer or even your help desk staff that they can't use some ancient version of Microsoft Internet Explorer or Outlook Express because a cipher suite negotiation failed). Though I generally with NaCl's explanation of this topic, in practice it's not as easy as that. Just some thoughts. Regards, Matthias-Christian From dkg at fifthhorseman.net Tue Dec 31 01:41:49 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 30 Dec 2013 19:41:49 -0500 Subject: [gnutls-devel] overall sec_param (weakest link) for a gnutls session? In-Reply-To: <52C20757.2020902@mirix.org> References: <8761r560gn.fsf@alice.fifthhorseman.net> <529E653A.8070309@mirix.org> <52BECF44.7060606@mirix.org> <52C1E7B2.7000200@fifthhorseman.net> <52C20757.2020902@mirix.org> Message-ID: <52C212CD.1000307@fifthhorseman.net> On 12/30/2013 06:52 PM, Matthias-Christian Ott wrote: > I would rather say it was a misunderstanding and if it was a > mischaracterisation, it was not deliberate. sure, i didn't mean it adversarially :) > gnutls_priority_set_direct with perhaps some more keywords seems to be > exactly what you want. Right, so one direction is to have a few keywords or to be able to use ULTRA vs. MEDIUM vs. WEAK or something in the priority string directly. This is the way that a service administrator could make a hard cutoff. But you're right that i'm also asking for something else: i'd like a way that gnutls could expose a "weakest link" value for connections that *are* made. This would make it possible to do a simpler audit of existing traffic patterns, for example, or to identify (and possibly respond differently to) particular peers whose traffic patterns are below average, or to have a probationary period for these weaker configurations before they are removed entirely. > An application developer calls > gnutls_priority_set_direct or uses the defaults which should be secure > (although this is debatable) and GnuTLS enforces a specific security > level where a lot of parameters are controllable by ?TLS experts?. I > think you can't make it simpler than doing nothing and using the defaults. The trouble with "just using the defaults" is that different TLS-using applications (quite reasonably) have different defaults. For example, for SMTP, where the default will almost certainly be for negotiating peers to fall back to cleartext and avoid the TLS stack entirely, you probably don't want to be super strict about what you accept. (but you still might want to have a sense of what strength was used by a given peer, for example, to amass a list of common SMTP peers with poor crypto practices, whose administrators you could contact and encourage to improve their configurations) Likewise, some web site operators offer their same site under both HTTP and HTTPS -- they are willing to talk to clients who don't use TLS at all. they are likely to have lower-bar requirements for their TLS choices than would a site that expecting all access to arrive via HTTPS. > I would rather find it more useful if GnuTLS had keywords for certain > standards and regulatory institutions built-in. I don't think this is a mutually-exclusive suggestion. Being able to say (for example) LATEST-ENISA-LONGTERM in a priority string would be very handy. This is a separate feature request, though. > Because of different software versions, TLS implementations and > especially proprietary software, it is also very difficult to agree on a > safe default cipher suite list and security parameters. I agree with your analysis here: In the face of old and outdated, heterogenous peers that you need to allow to access your system, TLS's algorithm agility is actually difficult beast to use effectively. OTOH, that agility is what has allowed us to continue to use TLS rather than having to invent entirely new transport layer (which would have even worse compatibility issues). building in reporting of weakest-link negotiated parameters to gnutls would help operators of gnutls-backed services to be proactive about reviewing and planning to use TLS's algorithm agility to stay current, and to identify which peers (if any) in a typical traffic pattern might need to be repaired/replaced before tightening up the requirements. i hope this helps explain why i think such a feature would be useful. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From grubba at grubba.org Mon Dec 30 19:03:02 2013 From: grubba at grubba.org (=?ISO-8859-15?Q?Henrik_Grubbstr=F6m?=) Date: Mon, 30 Dec 2013 19:03:02 +0100 (CET) Subject: [gnutls-devel] _gnutls_extension_list_check() isn't RFC 5746 compliant Message-ID: Hi. The gnutls-cli-debug 3.2.8 test "Checking for SSL 3.0 support" fails against servers that implement RFC 5746. The client code sends the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV: Received on the server from the client: 10 : SSL_rsa_with_3des_ede_cbc_sha 5 : SSL_rsa_with_rc4_128_sha 4 : SSL_rsa_with_rc4_128_md5 22 : SSL_dhe_rsa_with_3des_ede_cbc_sha 19 : SSL_dhe_dss_with_3des_ede_cbc_sha 49170 : TLS_ecdhe_rsa_with_3des_ede_cbc_sha 49169 : TLS_ecdhe_rsa_with_rc4_128_sha 49160 : TLS_ecdhe_ecdsa_with_3des_ede_cbc_sha 49159 : TLS_ecdhe_ecdsa_with_rc4_128_sha 255 : TLS_empty_renegotiation_info_scsv For which according to RFC 5746 3.6 the server should: o When a ClientHello is received, the server MUST check if it includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, set the secure_renegotiation flag to TRUE. o If the secure_renegotiation flag is set to TRUE, the server MUST include an empty "renegotiation_info" extension in the ServerHello message. However the test in _gnutls_extension_list_check() doesn't like receiving extensions it didn't request as extensions, and the test fails: |<3>| HSK[0x657090]: SERVER HELLO (2) was received. Length 67[67], frag offset 0, frag length: 67, sequence: 0 |<3>| HSK[0x657090]: Server's version: 3.0 |<3>| HSK[0x657090]: SessionID length: 16 |<3>| HSK[0x657090]: SessionID: 52c1acce50696b6553534c3300000000 |<3>| HSK[0x657090]: Selected cipher suite: ECDHE_RSA_ARCFOUR_128_SHA1 |<3>| HSK[0x657090]: Selected compression method: NULL (0) |<3>| EXT[0x657090]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<2>| ASSERT: gnutls_extensions.c:177 I see a couple of possible approaches to fixing the bug (in order of desirability): o Have SAFE RENEGOTIATION added to session->internals.extensions_sent whenever TLS_EMPTY_RENEGOTIATION_INFO_SCSV is in the list of supported cipher suites. o Have a special case in _gnutls_extension_list_check() that just ignores this extension. o Stop sending TLS_EMPTY_RENEGOTIATION_INFO_SCSV in this test. Thanks and a Happy New Year! -- Henrik Grubbstr?m grubba at grubba.org Roxen Internet Software AB grubba at roxen.com From grubba at roxen.com Mon Dec 30 19:22:29 2013 From: grubba at roxen.com (=?ISO-8859-15?Q?Henrik_Grubbstr=F6m?=) Date: Mon, 30 Dec 2013 19:22:29 +0100 (CET) Subject: [gnutls-devel] _gnutls_extension_list_check() isn't RFC 5746 compliant In-Reply-To: References: Message-ID: On Mon, 30 Dec 2013, Henrik Grubbstr?m wrote: > Hi. > > The gnutls-cli-debug 3.2.8 test "Checking for SSL 3.0 support" fails against > servers that implement RFC 5746. Oops, sorry, please disregard. The problem was that my server sent the EC_POINT_FORMATS extension always when negotiating an ECC cipher suite, even when the client hadn't provided the extension, and thus breaking RFC 4492 5.2: The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite. Once again Happy New Year! -- Henrik Grubbstr?m grubba at grubba.org Roxen Internet Software AB grubba at roxen.com