From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:24:58 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:24:58 +0100 Subject: Interoperability issue with The Bat (Debian Bug #316522) Message-ID: <20080103002458.GA14155@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #316522, http://bugs.debian.org/316522 ================================================= Simon writes: > When the email client TheBat talks with exim4 4.50-8, gnutls (in > exim4) will log (gnutls_handshake): An error was encountered at the > TLS Finished packet calculation. Other clients than TheBat reportedly > works. An older version of Exim4, specifically 4.32-2, worked though. > It is unclear whether the version of GnuTLS changed when exim4 was > upgraded from 4.32-2 to 4.50-8. Unfortunately, I wasn't able to find out which GnuTLS library exim4 4.32-2 was compiled against since snapshot.debian.net is incomplete here. 4.32-4 was built for Debian on April 26, 2004. Exim 4.50-8 in Debian has a binary depends on libgnutls11 (>= 1.0.16). > There is no discussion of whether changing to OpenSSL would solve the > problem. Conclusion: The problem with TheBat warrants debugging. > However, this do not seem to be a widely reported problem. Further, > TheBat is not free software so we cannot help debug it. Questions: > The reported said earlier versions worked, which GnuTLS versions was > this? Can the problem be pin-pointed to a specific GnuTLS release or > Exim4 release? Does the problem go away with OpenSSL? Can you ask these questions to the submitter on the BTS? It might be possible (judging from https://www.ritlabs.com/bt/view.php?id=5785) that The Bat by default refuses to talk TLS to a server presenting a self-signed certificate. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:32:14 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:32:14 +0100 Subject: Uses too much entropy (Debian Bug #343085) Message-ID: <20080103003214.GB14155@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #343085, http://bugs.debian.org/343085 ================================================= This is an example bug for the entropy issue which seems to be the most pressing issue with Exim4 and GnuTLS at the moment. Let me give you a little background: Exim4's documentation used to recommend deleting the dh-parameter file needed for some crypto operations on a regular basis. The cron job used to remove the file, and exim then proceeded to re-built the file on the next TLS operation. This generation reads from /dev/random, blocks if no entropy is available, which leads to entropy starvation and an interrupted e-mail service. We have reacted to this issue by removing the RSAEXPORT algorithms, eliminating the need for the blocking operation. However, this issue has left our user base in some kind of sensitiveness when exim4's TLS operations goof in the presence of low entropy. Currently, our research has shown that using exim4 as a TLS server will not block, but keep the system's entropy at a very low level during even only moderately busy operation. As a result of this issue, GnuTLS bugs http://savannah.gnu.org/support/?106113 and http://savannah.gnu.org/support/?106112 were filed. The entropy issue is also mentioned in http://bugs.debian.org/446036 and http://bugs.debian.org/448775. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:34:06 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:34:06 +0100 Subject: MAC padding (Debian Bug #390712) Message-ID: <20080103003406.GC14155@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #390712, http://bugs.debian.org/390712 ================================================= Simon writes: > Appears to be triggered by GnuTLS implementing MAC padding to solve a > security problem in TLS. OpenSSL reportedly does not implement the > same work around, and would thus appear to be vulnerable to that > problem. > Conclusion: Appears to be a ???wontfix??? bug. Personally, I think GnuTLS > could provide a simpler mechanism to disable MAC padding if > applications deem this necessary. Someone could double check how > important the MAC padding security concern is. I disagree about the "wontfix" bug. We have an interoperability issue here, where the end user notices "things work when I use OpenSSL or do not use TLS at all, only GnuTLS breaks". In the result, the end user will use OpenSSL or no TLS at all, which reduces GnuTLS user base and cryptography coverage. I would like to see a mechanism to disable MAC padding if it is really the culprit here. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:36:06 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:36:06 +0100 Subject: Problems with specific certificate/key (Debian Bug #426013) Message-ID: <20080103003606.GD14155@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #426013, http://bugs.debian.org/426013 ================================================= Simon writes: > Appears to be an unreprodicible problem with a specific > certificate/key which the user cannot reveal. Another certificate/key > from the same CA works fine. Theory: could it be CRLF problems? Other > non-ASCII characters in the file? Nothing indicates a real GnuTLS > problem here. > Conclusion: Likely not a GnuTLS problem. I think that this conclusion was built too fast, but we do not have sufficient information to know this. The original reporter has said in the mean time that there are no non-ascii chars in the file and that there are no CRLF issues here. Currently, it is suspected that GnuTLS has issues with the fact that the certificate is a wildcard certificate. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:38:36 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:38:36 +0100 Subject: Does not support full certificate chain lookups (Debian Bug #446036) Message-ID: <20080103003836.GE14155@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #446036, http://bugs.debian.org/446036 ================================================= This issue is only one of the arguments given in the bug report, but the others have been addressed in other places, and others again I am willing to ignore for the time being. Simon writes: > The other claim is that ???openssl actually supports full certificate > chain lookups, so you can be guaranteed that this cert was signed was > signed by that ca. gnutls does not, to the best of my knowledge.???. As > far as I can understand with Stephen Gran refers to, that is simply > false. Can you comment this inside the bug report, please? I do not feel that it would be a good idea for me to be mail and information relay. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Thu Jan 3 01:39:01 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 01:39:01 +0100 Subject: Interoperability issues (Debian Bug #348046) Message-ID: <20080103003901.GA14027@torres.zugschlus.de> Hi, Simon Josefsson has suggested to me (a member of the maintainer team for Exim's packages for the Debian Operating System) that it might be a good idea to move a technical debate from our blogs (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) to gnutls-devel as this list is a better medium for archived discussion. I'll send a dedicated mail for each of Debian's bug reports, so that the threads are not going to intermix. Debian Bug #348046, http://bugs.debian.org/348046 ================================================= Simon writes: > Bug #348046 is so complex that I cannot judge it. If the submitters > are willing, it may be best to re-submit each problem separately. The > problem with TheBat is interesting, but given the non-free status of > TheBat and no other reports, it doesn???t seem serious. To reduce > entropy consumption is something we should work on, but it is a > ???wishlist??? kind of bug, and to some extent may have already been > solved by removing the DH generation code which depleats the entropy > pool quickly. The rest appears to be already solved or should be > tagged as ???wontfix???. To me, after cursory inspection, this looks like: (A) Original bug submitter complaining about "A TLS packet with unexpected length was received" when the local Exim is a _client_ (Message 5). (B) jarek saying "me too", but saying that his local Exim says "A TLS packet with unexpected length was received" while his Exim is a _server_ (Message 45) (C) Ian Zimmerman trying to debug issue (B) but having trouble with gnutls-cli (Message 58) (D) gnutls-cli-debug not having an --starttls option (is this a bug in gnutls-cli-debug? What is gnutls-cli-debug's Differnence from gnutls-cli in the first place?) (E) Marc F .Clemente saying "me too" to (B) (Message 110) (F) Vincent Lefevre saying (Message 130), that outgoign messages also reduce entropy. (G) Andrew McGlashan finding it impossible to connect to gnutls-serv with incredimail (giving debug output in Message 224). Can you comment about (D) and (G)? > Bug #348046 > This is a long bug report by several submitters. The initial report > from Martin A. Brooks is stalled when he doesn???t respond to the > (appropriate and relevant) questions that Marc Haber asks. The > problem that Ian Zimmerman reports seems to be different, now GnuTLS > clients work fine but OpenSSL clients fail to connect to the > Exim4/GnuTLS server. The OpenSSL errors may suggest it only wants to > talk SSLv2 for some reason (local configuration?). Debugging the > OpenSSL problem further would be the appropriate response, and should > likely be treated as an OpenSSL bug (!) until more evidence can be > gathered. Later, Andrew McGlashan reports a problem where neither > GnuTLS and OpenSSL works against the ???Incredimail??? MUA. > Conclusion: The bug should really be forked into several problems, > one for the initial reports where the submitter stopped responding, > one for the OpenSSL problem, and one for the Incredimail problem (and > as Incredimail isn???t a Debian package, it???s not Debian???s problem). > Caveat: I may have missunderstood some parts of this bug report > because different problems are discussed at the same time. Once that > is done we can try to address each problem separetely. Which issue is the OpenSSL thing? I think this is a good case to show what happens when the error messages are too simple. This bug report is a mess of different issues since GnuTLS obviously returns the same, quite generic, error message text for a number of different issues. People look into the BTS for their error message and attach their issue to the existing bug report, leading to the horrible mess this bug report is. I'd like to use this opportunity to pledge for more distinctive error messages. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From ametzler at downhill.at.eu.org Thu Jan 3 16:51:00 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 3 Jan 2008 16:51:00 +0100 Subject: MAC padding (Debian Bug #390712) In-Reply-To: <20080103003406.GC14155@torres.zugschlus.de> References: <20080103003406.GC14155@torres.zugschlus.de> Message-ID: <20080103155100.GA4714@downhill.g.la> On 2008-01-03 Marc Haber wrote: [...] > Debian Bug #390712, http://bugs.debian.org/390712 > ================================================= > Simon writes: > > Appears to be triggered by GnuTLS implementing MAC padding to solve a > > security problem in TLS. OpenSSL reportedly does not implement the > > same work around, and would thus appear to be vulnerable to that > > problem. > > Conclusion: Appears to be a ???wontfix??? bug. Personally, I think GnuTLS > > could provide a simpler mechanism to disable MAC padding if > > applications deem this necessary. Someone could double check how > > important the MAC padding security concern is. > I disagree about the "wontfix" bug. We have an interoperability issue > here, where the end user notices "things work when I use OpenSSL or do > not use TLS at all, only GnuTLS breaks". In the result, the end user > will use OpenSSL or no TLS at all, which reduces GnuTLS user base and > cryptography coverage. > I would like to see a mechanism to disable MAC padding if it is really > the culprit here. Hello, AFAIUI that has been done on the gnutls side of things: ------------------------------ * Version 2.0.3 (released 2007-11-10) ** Added gnutls_record_disable_padding() to allow servers talking to buggy clients that complain if the TLS 1.0 record protocol padding is used. ** Introduced gnutls_session_enable_compatibility_mode() to allow enabling all supported compatibility options (like disabling padding). ------------------------------ thanks, 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 mh+gnutls-devel at zugschlus.de Thu Jan 3 17:54:13 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Thu, 3 Jan 2008 17:54:13 +0100 Subject: MAC padding (Debian Bug #390712) In-Reply-To: <20080103155100.GA4714@downhill.g.la> References: <20080103003406.GC14155@torres.zugschlus.de> <20080103155100.GA4714@downhill.g.la> Message-ID: <20080103165413.GB31766@torres.zugschlus.de> On Thu, Jan 03, 2008 at 04:51:00PM +0100, Andreas Metzler wrote: > AFAIUI that has been done on the gnutls side of things: > ------------------------------ > * Version 2.0.3 (released 2007-11-10) > > ** Added gnutls_record_disable_padding() to allow servers talking to > buggy clients that complain if the TLS 1.0 record protocol padding is > used. > > ** Introduced gnutls_session_enable_compatibility_mode() to allow > enabling all supported compatibility options (like disabling padding). > ------------------------------ Is it possible to disable this at run time without having to modify exim? Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From ametzler at downhill.at.eu.org Thu Jan 3 17:59:55 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Thu, 3 Jan 2008 17:59:55 +0100 Subject: MAC padding (Debian Bug #390712) In-Reply-To: <20080103165413.GB31766@torres.zugschlus.de> References: <20080103003406.GC14155@torres.zugschlus.de> <20080103155100.GA4714@downhill.g.la> <20080103165413.GB31766@torres.zugschlus.de> Message-ID: <20080103165955.GC4714@downhill.g.la> On 2008-01-03 Marc Haber wrote: > On Thu, Jan 03, 2008 at 04:51:00PM +0100, Andreas Metzler wrote: > > AFAIUI that has been done on the gnutls side of things: > > ------------------------------ > > * Version 2.0.3 (released 2007-11-10) > > > > ** Added gnutls_record_disable_padding() to allow servers talking to > > buggy clients that complain if the TLS 1.0 record protocol padding is > > used. > > > > ** Introduced gnutls_session_enable_compatibility_mode() to allow > > enabling all supported compatibility options (like disabling padding). > > ------------------------------ > Is it possible to disable this at run time without having to modify > exim? Hello, Afaik no, exim would need to change. Probably adding a new global option to configure this. 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 simon at josefsson.org Thu Jan 3 22:28:29 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 03 Jan 2008 22:28:29 +0100 Subject: MAC padding (Debian Bug #390712) In-Reply-To: <20080103165955.GC4714@downhill.g.la> (Andreas Metzler's message of "Thu, 3 Jan 2008 17:59:55 +0100") References: <20080103003406.GC14155@torres.zugschlus.de> <20080103155100.GA4714@downhill.g.la> <20080103165413.GB31766@torres.zugschlus.de> <20080103165955.GC4714@downhill.g.la> Message-ID: <87ve6aha4i.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2008-01-03 Marc Haber wrote: >> On Thu, Jan 03, 2008 at 04:51:00PM +0100, Andreas Metzler wrote: >> > AFAIUI that has been done on the gnutls side of things: >> > ------------------------------ >> > * Version 2.0.3 (released 2007-11-10) >> > >> > ** Added gnutls_record_disable_padding() to allow servers talking to >> > buggy clients that complain if the TLS 1.0 record protocol padding is >> > used. >> > >> > ** Introduced gnutls_session_enable_compatibility_mode() to allow >> > enabling all supported compatibility options (like disabling padding). >> > ------------------------------ > >> Is it possible to disable this at run time without having to modify >> exim? > > Hello, > > Afaik no, exim would need to change. Probably adding a new > global option to configure this. Agreed, but please use the new cipher preference API instead (see below) since it can be used to control much more things, and is more suitable for application configuration. A reasonable default priority to have in the exim configuration file would be 'NORMAL'. Administrators that want to lower their security level (possibly for just a particular IP address range? Not sure if that kind of flexibility is allowed by exim) can replace the string with 'NORMAL:%COMPAT' or similar. That would disable MAC padding. Note that this API was introduced with gnutls v2.2. /Simon /** * gnutls_priority_init - Sets priorities for the cipher suites supported by gnutls. * @priority_cache: is a #gnutls_prioritity_t structure. * @priorities: is a string describing priorities * @err_pos: In case of an error this will have the position in the string the error occured * * Sets priorities for the ciphers, key exchange methods, macs and * compression methods. This is to avoid using the * gnutls_*_priority() functions. * * The #priorities option allows you to specify a semi-colon * separated list of the cipher priorities to enable. * * Unless the first keyword is "NONE" the defaults are: * Protocols: TLS1.1, TLS1.0, and SSL3.0. * Compression: NULL. * Certificate types: X.509, OpenPGP. * * You can also use predefined sets of ciphersuites: "PERFORMANCE" * all the "secure" ciphersuites are enabled, limited to 128 bit * ciphers and sorted by terms of speed performance. * * "NORMAL" option enables all "secure" ciphersuites. The 256-bit ciphers * are included as a fallback only. The ciphers are sorted by security margin. * * "SECURE128" flag enables all "secure" ciphersuites with ciphers up to * 128 bits, sorted by security margin. * * "SECURE256" flag enables all "secure" ciphersuites including the 256 bit * ciphers, sorted by security margin. * * "EXPORT" all the ciphersuites are enabled, including the * low-security 40 bit ciphers. * * "NONE" nothing is enabled. This disables even protocols and * compression methods. * * Special keywords: * '!' or '-' appended with an algorithm will remove this algorithm. * '+' appended with an algorithm will add this algorithm. * '%COMPAT' will enable compatibility features for a server. * * To avoid collisions in order to specify a compression algorithm in * this string you have to prefix it with "COMP-", protocol versions * with "VERS-" and certificate types with "CTYPE-". All other * algorithms don't need a prefix. * * For key exchange algorithms when in NORMAL or SECURE levels the * perfect forward secrecy algorithms take precendence of the other * protocols. In all cases all the supported key exchange algorithms * are enabled (except for the RSA-EXPORT which is only enabled in * EXPORT level). * * Note that although one can select very long key sizes (such as 256 bits) * for symmetric algorithms, to actually increase security the public key * algorithms have to use longer key sizes as well. * * Examples: "NORMAL:!AES-128-CBC", * "EXPORT:!VERS-TLS1.0:+COMP-DEFLATE:+CTYPE-OPENPGP", * "NONE:+VERS-TLS1.0:+AES-128-CBC:+RSA:+SHA1:+COMP-NULL", "NORMAL", * "NORMAL:%COMPAT". * * Returns: On syntax error %GNUTLS_E_INVALID_REQUEST is returned, * %GNUTLS_E_SUCCESS on success, or an error code. **/ int gnutls_priority_init (gnutls_priority_t * priority_cache, const char *priorities, const char **err_pos) From simon at josefsson.org Fri Jan 4 00:18:16 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 4 Jan 2008 00:18:16 +0100 Subject: Does not support full certificate chain lookups (Debian Bug #446036) In-Reply-To: <20080103003836.GE14155@torres.zugschlus.de> References: <20080103003836.GE14155@torres.zugschlus.de> Message-ID: <6065E80D-1514-46F7-AB51-664C654A83DA@josefsson.org> On 3 jan 2008, at 01.38, Marc Haber wrote: > Debian Bug #446036, http://bugs.debian.org/446036 > ================================================= > This issue is only one of the arguments given in the bug report, but > the others have been addressed in other places, and others again I am > willing to ignore for the time being. > > Simon writes: >> The other claim is that ???openssl actually supports full >> certificate >> chain lookups, so you can be guaranteed that this cert was signed >> was >> signed by that ca. gnutls does not, to the best of my >> knowledge.???. As >> far as I can understand with Stephen Gran refers to, that is simply >> false. > > Can you comment this inside the bug report, please? I do not feel that > it would be a good idea for me to be mail and information relay. I added my comments to the bug, see: . Thanks, /Simon From n.mavrogiannopoulos at gmail.com Fri Jan 4 08:39:32 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 4 Jan 2008 09:39:32 +0200 Subject: Problems with specific certificate/key (Debian Bug #426013) In-Reply-To: <20080103003606.GD14155@torres.zugschlus.de> References: <20080103003606.GD14155@torres.zugschlus.de> Message-ID: On Jan 3, 2008 2:36 AM, Marc Haber wrote: > Hi, > > Simon writes: > > Appears to be an unreprodicible problem with a specific > > certificate/key which the user cannot reveal. Another certificate/key > > from the same CA works fine. Theory: could it be CRLF problems? Other > > non-ASCII characters in the file? Nothing indicates a real GnuTLS > > problem here. > > Conclusion: Likely not a GnuTLS problem. > > I think that this conclusion was built too fast, but we do not have > sufficient information to know this. > > The original reporter has said in the mean time that there are no > non-ascii chars in the file and that there are no CRLF issues here. > Currently, it is suspected that GnuTLS has issues with the fact that > the certificate is a wildcard certificate. By reading this report, I'm really curious which gnutls version is used, and whether the gnutls-serv and exim are linked on the same version of gnutls. Does this occur if exim is linked on gnutls 2.2? regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Fri Jan 4 08:56:28 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 4 Jan 2008 09:56:28 +0200 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080103003214.GB14155@torres.zugschlus.de> References: <20080103003214.GB14155@torres.zugschlus.de> Message-ID: On Jan 3, 2008 2:32 AM, Marc Haber wrote: > Hi, > > Debian Bug #343085, http://bugs.debian.org/343085 > This is an example bug for the entropy issue which seems to be the > most pressing issue with Exim4 and GnuTLS at the moment. Let me give > you a little background: Exim4's documentation used to recommend > deleting the dh-parameter file needed for some crypto operations on a > regular basis. The cron job used to remove the file, and exim then > proceeded to re-built the file on the next TLS operation. This > generation reads from /dev/random, blocks if no entropy is available, > which leads to entropy starvation and an interrupted e-mail service. > > We have reacted to this issue by removing the RSAEXPORT algorithms, > eliminating the need for the blocking operation. However, this issue > has left our user base in some kind of sensitiveness when exim4's TLS > operations goof in the presence of low entropy. Currently, our > research has shown that using exim4 as a TLS server will not block, > but keep the system's entropy at a very low level during even only > moderately busy operation. As a result of this issue, GnuTLS bugs > http://savannah.gnu.org/support/?106113 and > http://savannah.gnu.org/support/?106112 were filed. > > The entropy issue is also mentioned in http://bugs.debian.org/446036 > and http://bugs.debian.org/448775. My point of view was: > This looks more like a bug of the implementation of /dev/random and /dev/urandom rather than a gnutls bug. GnuTLS (libgcrypt) reads >some bytes per process from /dev/urandom in order to be able to initialize it's PRNG. Since exim uses lots of processes the > /dev/urandom pool could be exhausted. Since /dev/urandom is public the security of the system shouldn't depend on someone reading >bytes from it. You replied: > have to disagree with this being a kernel bug. man 4 random on Linux documents how /dev/urandom behaves, and is supposed to behave. > "Some bytes" looks more like "a few hundred bytes", and Exim does not exhaust /dev/urandom as badly when OpenSSL is used. If > GnuTLS wants to be a free (speech) alternative to OpenSSL, it does not need more issues that OpenSSL, it needs to do things actually better. We don't market gnutls as an openssl replacement. It is an alternative to it and it has different inner workings. We do provide a complete documentation of these so anybody can create his software using it. We (or better I) are not interested into creating a plug and play openssl replacement. However on the point. I still believe it is a kernel issue. A process should not be able to deplete randomness in a system. There are algorithms that can do that, and there were even rejected kernel patches that implemented them. A workaround might be to use the libgcrypt's random number process feature which uses a single server process to feed other processes with entropy (I've never worked with it so I don't know if it can be used in that case). This might solve this issue. regards, Nikos From ametzler at downhill.at.eu.org Fri Jan 4 10:48:48 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 4 Jan 2008 10:48:48 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: References: <20080103003214.GB14155@torres.zugschlus.de> Message-ID: <20080104094848.GB4528@downhill.g.la> On 2008-01-04 Nikos Mavrogiannopoulos wrote: > On Jan 3, 2008 2:32 AM, Marc Haber wrote: [...] >> http://savannah.gnu.org/support/?106113 and >> http://savannah.gnu.org/support/?106112 were filed. >> The entropy issue is also mentioned in http://bugs.debian.org/446036 >> and http://bugs.debian.org/448775. > My point of view was: >> This looks more like a bug of the implementation of /dev/random >> and /dev/urandom rather than a gnutls bug. GnuTLS (libgcrypt) >> reads >some bytes per process from /dev/urandom in order to be >> able to initialize it's PRNG. Since exim uses lots of processes >> the /dev/urandom pool could be exhausted. Since /dev/urandom is >> public the security of the system shouldn't depend on someone >> reading bytes from it. You replied: >> have to disagree with this being a kernel bug. man 4 random on >> Linux documents how /dev/urandom behaves, and is supposed to >> behave. "Some bytes" looks more like "a few hundred bytes", and >> Exim does not exhaust /dev/urandom as badly when OpenSSL is used. Hello, The amount of data read from /dev/urandom in Gnutls/Gcrypt is on a different scale than in openssl: When acting as a server gnutls pulls that much data from /dev/urandom that entropy available for /dev/random is down to its minimum safeguard. ((it is not possible to completely deplete /dev/random by reading from /dev/urandom in current kernels) ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && gnutls-serv --x 509keyfile /tmp/CERT/exim.key --x509certfile /tmp/CERT/exim.crt & sleep 1 && ca t /proc/sys/kernel/random/entropy_avail [1] 5356 3591 Echo Server ready. Listening to port '5556'. 139 ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && openssl s_serve r -cert /tmp/CERT/exim.crt -key /tmp/CERT/exim.key -accept 5556 & sleep 1 && cat /proc/sys/kernel/random/entropy_avail [1] 7139 3596 [...] 3361 The same thing happens when gnutls acts as a client (It does not matter whether the server is gnutls-serv or openssl s_client since both do no fork but setup the RNG at startup.) ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && echo xx | open ssl s_client -connect localhost:5556 && cat /proc/sys/kernel/random/entropy_avail 3585 [...] 3329 ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && echo xx | gnutls-cli -p 5556 localhost > /dev/null 2>&1 && cat /proc/sys/kernel/random/entrop y_avail 3593 [...] 140 (Tests done with GnuTLS 1.4.4., I don't think there have been substantial changes in the libraries in that respect. 2.0.4 behaves the same.) So with a forking daemon (therefore initialising the RNG for every in- and outgoing connection) GnuTLS will deplete entropy_avail to its bare minimum vor every single connection, while openssl only takes about 7%. What is the actual cause of this difference in resource usage? 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 Fri Jan 4 10:59:58 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 4 Jan 2008 11:59:58 +0200 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104094848.GB4528@downhill.g.la> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> Message-ID: On Jan 4, 2008 11:48 AM, Andreas Metzler wrote: > >> have to disagree with this being a kernel bug. man 4 random on > >> Linux documents how /dev/urandom behaves, and is supposed to > >> behave. "Some bytes" looks more like "a few hundred bytes", and > >> Exim does not exhaust /dev/urandom as badly when OpenSSL is used. > > Hello, > The amount of data read from /dev/urandom in Gnutls/Gcrypt is on a > different scale than in openssl: > [...] > So with a forking daemon (therefore initialising the RNG for every in- > and outgoing connection) GnuTLS will deplete entropy_avail to its > bare minimum vor every single connection, while openssl only takes > about 7%. > What is the actual cause of this difference in resource usage? This is mostly a question for libgcrypt developers, but I believe libgcrypt initializes the PRNG in a more conservative way. regards, Nikos From simon at josefsson.org Fri Jan 4 12:27:50 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 12:27:50 +0100 Subject: Problems with specific certificate/key (Debian Bug #426013) In-Reply-To: <20080103003606.GD14155@torres.zugschlus.de> (Marc Haber's message of "Thu, 3 Jan 2008 01:36:06 +0100") References: <20080103003606.GD14155@torres.zugschlus.de> Message-ID: <87ejcxhlu1.fsf@mocca.josefsson.org> Marc Haber writes: > Hi, > > Simon Josefsson has suggested to me (a member of the maintainer team > for Exim's packages for the Debian Operating System) that it might be > a good idea to move a technical debate from our blogs > (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, > http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) > to gnutls-devel as this list is a better medium for archived discussion. > > I'll send a dedicated mail for each of Debian's bug reports, so that > the threads are not going to intermix. > > Debian Bug #426013, http://bugs.debian.org/426013 > ================================================= > Simon writes: >> Appears to be an unreprodicible problem with a specific >> certificate/key which the user cannot reveal. Another certificate/key >> from the same CA works fine. Theory: could it be CRLF problems? Other >> non-ASCII characters in the file? Nothing indicates a real GnuTLS >> problem here. >> Conclusion: Likely not a GnuTLS problem. > > I think that this conclusion was built too fast, but we do not have > sufficient information to know this. > > The original reporter has said in the mean time that there are no > non-ascii chars in the file and that there are no CRLF issues here. > Currently, it is suspected that GnuTLS has issues with the fact that > the certificate is a wildcard certificate. The error message 'base64 decoding' error suggests decoding fails early -- before gnutls has a chance of knowing whether it is a wildcard certificate or not. So I believe that conclusion is most likely wrong. The code in question in exim4 is: if (cert_expanded != NULL) { DEBUG(D_tls) debug_printf("certificate file = %s\nkey file = %s\n", cert_expanded, key_expanded); rc = gnutls_certificate_set_x509_key_file(x509_cred, CS cert_expanded, CS key_expanded, GNUTLS_X509_FMT_PEM); if (rc < 0) { uschar *msg = string_sprintf("cert/key setup: cert=%s key=%s", cert_expanded, key_expanded); return tls_error(msg, host, rc); } } Note how the error message in the report subtly differ from what's in the source code (s/setup/set up/), which seems strange but may be due to cut'n'paste. I have asked the original submitter a few questions in the bug report. /Simon From wk at gnupg.org Fri Jan 4 12:25:54 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jan 2008 12:25:54 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 4 Jan 2008 11:59:58 +0200") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> Message-ID: <87tzlt6ddp.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 10:59, nmav at gnutls.org said: > This is mostly a question for libgcrypt developers, but I believe > libgcrypt initializes the PRNG in a more conservative way. Right, we even implement failsafe methods in case /dev/random does not work like expected. In fact we don't know ehther /dev/random is a good RNG or not. There is no serious study on the quality of /dev/random and in the past we have seen major over-estimations on the available entropy. The problem with exim is that it does not use a random seed file which greatly helps libgcrypt to initializes its internal pool. I recall that we discussed this quite some time ago. I just looked at the current Sid source of Exim and I can't find any call to libgcrypt. IIRC, gnutls does not cope with global libcgrypt setting and thus there is no saving of a seend file. Exim should properly intialize libgcrypt and create a random seed file. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From smurf at smurf.noris.de Fri Jan 4 12:38:47 2008 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Fri, 4 Jan 2008 12:38:47 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: References: <20080103003214.GB14155@torres.zugschlus.de> Message-ID: <20080104113847.GJ22955@kiste.smurf.noris.de> Hi, Nikos Mavrogiannopoulos: > However on the point. I still believe it is a kernel > issue. A process should not be able to deplete randomness in a system. There's a trade-off between "make /dev/urandom as random as possible" (which requires mixing in random bits from hardware), and "make /dev/random have as many unique, used-only-once, truly-random bits as possible" (which obviously requires *not* doing that for /dev/urandom). You can't have both. The kernel defaults to the former, because /dev/random should only be used if you need to generate a ultra-secure long-term public key, or something else along these lines. /dev/urandom is more than sufficient for anything else, to the best of our knowledge. I'd hazard that nobody who is in their right mind would run *anything* on a system used for generating a highly secure key (other than the key generator of course :-P). Thus, jobs which deplete the randomness pool by reading /dev/urandom are not an issue on such a system. > There are algorithms that can do that, and there were even rejected > kernel patches that implemented them. > There's nothing to implement. There already is /dev/urandom. Just use it (exclusively). > A workaround might be to use the libgcrypt's random number process > feature which uses a single server process to feed other processes > with entropy (I've never worked with it so I don't know if it can be > used in that case). This might solve this issue. Disagree. * /dev/(u)random is more difficult to subvert than a daemon. * The kernel has access to more sources of randomness. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Computers are useless. They can only give you answers. -- Pablo Picasso From n.mavrogiannopoulos at gmail.com Fri Jan 4 12:55:48 2008 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 4 Jan 2008 13:55:48 +0200 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104113847.GJ22955@kiste.smurf.noris.de> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> Message-ID: > > A workaround might be to use the libgcrypt's random number process > > feature which uses a single server process to feed other processes > > with entropy (I've never worked with it so I don't know if it can be > > used in that case). This might solve this issue. > > Disagree. > > * /dev/(u)random is more difficult to subvert than a daemon. > > * The kernel has access to more sources of randomness. I don't understand these comments. The libgcrypt's generator can be used in a separate processes. It doesn't mean it gathers any entropy except for using /dev/urandom as usual. regards, Nikos From simon at josefsson.org Fri Jan 4 13:06:41 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 13:06:41 +0100 Subject: Interoperability issues (Debian Bug #348046) In-Reply-To: <20080103003901.GA14027@torres.zugschlus.de> (Marc Haber's message of "Thu, 3 Jan 2008 01:39:01 +0100") References: <20080103003901.GA14027@torres.zugschlus.de> Message-ID: <87tzltbxri.fsf@mocca.josefsson.org> Marc Haber writes: > Hi, > > Simon Josefsson has suggested to me (a member of the maintainer team > for Exim's packages for the Debian Operating System) that it might be > a good idea to move a technical debate from our blogs > (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, > http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) > to gnutls-devel as this list is a better medium for archived discussion. > > I'll send a dedicated mail for each of Debian's bug reports, so that > the threads are not going to intermix. > > Debian Bug #348046, http://bugs.debian.org/348046 > ================================================= > > Simon writes: >> Bug #348046 is so complex that I cannot judge it. If the submitters >> are willing, it may be best to re-submit each problem separately. The >> problem with TheBat is interesting, but given the non-free status of >> TheBat and no other reports, it doesn???t seem serious. To reduce >> entropy consumption is something we should work on, but it is a >> ???wishlist??? kind of bug, and to some extent may have already been >> solved by removing the DH generation code which depleats the entropy >> pool quickly. The rest appears to be already solved or should be >> tagged as ???wontfix???. > > To me, after cursory inspection, this looks like: > (A) Original bug submitter complaining about "A TLS packet with > unexpected length was received" when the local Exim is a _client_ > (Message 5). > (B) jarek saying "me too", but saying that his local Exim says > "A TLS packet with unexpected length was received" while his Exim > is a _server_ (Message 45) Right. > (C) Ian Zimmerman trying to debug issue (B) but having trouble with > gnutls-cli (Message 58) Ian's initial problem (in 58) appear to be with 'openssl s_client'. The problem with gnutls-cli-debug in message 63 was a user error, gnutls-cli-debug doesn't work with TLS over SMTP, but you figured that out. In message 98 gnutls appears to work fine, but openssl s_client does not seem to work, which was Ian's initial concern. The reason the openssl command doesn't work is explained by adding 'debug' to the command line: yxa-iv:~# openssl s_client -connect kniv.josefsson.org:25 -starttls smtp -debug CONNECTED(00000003) read from 080B1BB0 [080AC740] (8192 bytes => 72 (0x48)) 0000 - 32 32 30 20 6b 6e 69 76-2e 6a 6f 73 65 66 73 73 220 kniv.josefss 0010 - 6f 6e 2e 6f 72 67 20 45-53 4d 54 50 20 45 78 69 on.org ESMTP Exi 0020 - 6d 20 34 2e 36 33 20 46-72 69 2c 20 30 34 20 4a m 4.63 Fri, 04 J 0030 - 61 6e 20 32 30 30 38 20-31 32 3a 33 39 3a 31 36 an 2008 12:39:16 0040 - 20 2b 30 31 30 30 0d 0a- +0100.. write to 080B1BB0 [BF816D80] (10 bytes => 10 (0xA)) 0000 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS.. read from 080B1BB0 [080AA738] (8192 bytes => 47 (0x2F)) 0000 - 35 30 33 20 53 54 41 52-54 54 4c 53 20 63 6f 6d 503 STARTTLS com 0010 - 6d 61 6e 64 20 75 73 65-64 20 77 68 65 6e 20 6e mand used when n 0020 - 6f 74 20 61 64 76 65 72-74 69 73 65 64 0d 0a ot advertised.. write to 080B1BB0 [080B1BF8] (142 bytes => 142 (0x8E)) 0000 - 80 8c 01 03 01 00 63 00-00 00 20 00 00 39 00 00 ......c... ..9.. 0010 - 38 00 00 35 00 00 16 00-00 13 00 00 0a 07 00 c0 8..5............ 0020 - 00 00 33 00 00 32 00 00-2f 03 00 80 00 00 66 00 ..3..2../.....f. 0030 - 00 05 00 00 04 01 00 80-08 00 80 00 00 63 00 00 .............c.. 0040 - 62 00 00 61 00 00 15 00-00 12 00 00 09 06 00 40 b..a...........@ 0050 - 00 00 65 00 00 64 00 00-60 00 00 14 00 00 11 00 ..e..d..`....... 0060 - 00 08 00 00 06 04 00 80-00 00 03 02 00 80 84 0f ................ 0070 - d2 b8 0b 21 74 5f 8a 9d-d5 42 3e 74 a0 63 5d 05 ...!t_...B>t.c]. 0080 - b7 4d e1 8e 79 c5 52 1b-de 71 39 b4 3e cd .M..y.R..q9.>. read from 080B1BB0 [080B7158] (7 bytes => 7 (0x7)) 0000 - 35 30 31 20 4e 55 4c 501 NUL 12040:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:478: yxa-iv:~# In other words, openssl doesn't implement the TLS over SMTP protocol properly, and exim4 rejects the connection. This is clearly an openssl bug and has nothing to do with gnutls. > (D) gnutls-cli-debug not having an --starttls option (is this a bug in > gnutls-cli-debug? What is gnutls-cli-debug's Differnence from > gnutls-cli in the first place?) Right, gnutls-cli-debug doesn't support starttls. If someone wants to work on providing that capability, feel free to submit patches... I note that openssl doesn't have any similar tool with starttls support either. The difference between gnutls-cli and gnutls-cli-debug is that the former is a simple interactive TLS client (with some starttls support) and the latter is a non-interactive debug tool. > (E) Marc F .Clemente saying "me too" to (B) (Message 110) It would help if he could run gnutls-serv in debug mode and try to reproduce the problem with thunderbird. I'll ask him in the bug report to do this. I'd add another item here: (EE) Vincent Lefevre says (Message 120) that the first message each morning fails with this error message too. One theory here could be some firewall acting up the first time every morning, what do you think? As Andreas Metzler says in message 125, there is nothing in the entropy code that could explain this. The error message is also not entropy related. > (F) Vincent Lefevre saying (Message 130), that outgoign messages also > reduce entropy. Which may be true. I'd add another item here too: (FF) Ronny Adsetts reports a problem with a different error message 'A record packet with illegal version was received.' and '(gnutls_handshake): timed out'. To me this looks like a connection problem. The first error typically happens on data corruption (possibly caused by incorrect STARTTLS negotiation) or implementation problems. > (G) Andrew McGlashan finding it impossible to connect to gnutls-serv > with incredimail (giving debug output in Message 224). > > Can you comment about (D) and (G)? First, Andrews' configuration seems confusing. He's using tls_on_connect_ports on ports 587? No wonder OE doesn't work. I don't really understand what's not working and what he wants to do. But I'll try to answer only your question: In the debug log, it seems IM is sending a SSLv2 client hello's. GnuTLS doesn't support SSLv2; for good reasons, its security has been broken. We do support SSLv2 client hellos though, so it should work if the client also supports SSLv3. This may be an area where people have not done enough testing, SSLv2 is almost extinct. So a basic question: Does IM support upwards negotiation from SSLv2 to SSLv3? If not, then this will not ever work. The user might as well use unencrypted connections instead. Without more help from the IM community, I'd be inclined to sign this is off as a IM problem. >> Bug #348046 >> This is a long bug report by several submitters. The initial report >> from Martin A. Brooks is stalled when he doesn???t respond to the >> (appropriate and relevant) questions that Marc Haber asks. The >> problem that Ian Zimmerman reports seems to be different, now GnuTLS >> clients work fine but OpenSSL clients fail to connect to the >> Exim4/GnuTLS server. The OpenSSL errors may suggest it only wants to >> talk SSLv2 for some reason (local configuration?). Debugging the >> OpenSSL problem further would be the appropriate response, and should >> likely be treated as an OpenSSL bug (!) until more evidence can be >> gathered. Later, Andrew McGlashan reports a problem where neither >> GnuTLS and OpenSSL works against the ???Incredimail??? MUA. >> Conclusion: The bug should really be forked into several problems, >> one for the initial reports where the submitter stopped responding, >> one for the OpenSSL problem, and one for the Incredimail problem (and >> as Incredimail isn???t a Debian package, it???s not Debian???s problem). >> Caveat: I may have missunderstood some parts of this bug report >> because different problems are discussed at the same time. Once that >> is done we can try to address each problem separetely. > > Which issue is the OpenSSL thing? The 'openssl s_client' issue I discussed above, and by using the -debug parameter I even resolved it... it is an openssl bug. > I think this is a good case to show what happens when the error > messages are too simple. This bug report is a mess of different issues > since GnuTLS obviously returns the same, quite generic, error message > text for a number of different issues. People look into the BTS for > their error message and attach their issue to the existing bug report, > leading to the horrible mess this bug report is. I'd like to use this > opportunity to pledge for more distinctive error messages. Before we know exactly what is the cause for the various problem, we can't know what a better error message would be. Reporting very narrow error messages is known to lead to security problems, where the other side can use different behaviour based on different error messages to attack the server. So some caution to be very verbose in error message is warranted for security applications. I'm not sure if this message will help much to move things further. There are simply too many completely different problems in this bug report, and the original submitter stopped responding long time ago. But I tried to answer the questions you raised at least. Thanks, /Simon From simon at josefsson.org Fri Jan 4 13:20:17 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 13:20:17 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87tzlt6ddp.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 12:25:54 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> Message-ID: <87odc1bx4u.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 4 Jan 2008 10:59, nmav at gnutls.org said: > >> This is mostly a question for libgcrypt developers, but I believe >> libgcrypt initializes the PRNG in a more conservative way. > > Right, we even implement failsafe methods in case /dev/random does not > work like expected. In fact we don't know ehther /dev/random is a good > RNG or not. There is no serious study on the quality of /dev/random and > in the past we have seen major over-estimations on the available > entropy. Right, and there are studies that suggests the Linux /dev/random device have flaws: http://eprint.iacr.org/2006/086 Being conservative here is a good thing. However, that does not have to be in conflict with working efficiently. Using a random seed file would be one way to address both concerns. /Simon From smurf at smurf.noris.de Fri Jan 4 13:21:16 2008 From: smurf at smurf.noris.de (Matthias Urlichs) Date: Fri, 4 Jan 2008 13:21:16 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> Message-ID: <20080104122116.GK22955@kiste.smurf.noris.de> Hi, Nikos Mavrogiannopoulos: > I don't understand these comments. The libgcrypt's generator can be > used in a separate processes. It doesn't mean it gathers any entropy > except for using /dev/urandom as usual. > Ah, thanks for the correction. In that case, if it's "as usual", why run the daemon in the first place? To clarify: I don't have an issue with gnutls eating randomness from the pool. The randomness is there to be eaten. However, reading 3000+ bits every time a server (or client) starts up does seem a bit excessive. I seriously doubt that it needs that many. -- Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf at smurf.noris.de Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de - - Military justice is to justice what military music is to music. -- Groucho Marx From fweimer at bfk.de Fri Jan 4 13:32:57 2008 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jan 2008 13:32:57 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87tzlt6ddp.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 12:25:54 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> Message-ID: <82wsqpg492.fsf@mid.bfk.de> * Werner Koch: > Exim should properly intialize libgcrypt and create a random seed file. Is this documented somewhere? I'm a bit reluctant to add this kind of layering violation. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Fri Jan 4 13:35:26 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 13:35:26 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104122116.GK22955@kiste.smurf.noris.de> (Matthias Urlichs's message of "Fri, 4 Jan 2008 13:21:16 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> Message-ID: <87k5mpbwfl.fsf@mocca.josefsson.org> Matthias Urlichs writes: > Hi, > > Nikos Mavrogiannopoulos: >> I don't understand these comments. The libgcrypt's generator can be >> used in a separate processes. It doesn't mean it gathers any entropy >> except for using /dev/urandom as usual. >> > Ah, thanks for the correction. > > In that case, if it's "as usual", why run the daemon in the first place? I think the daemon is there to help libgcrypt maintain randomness state between invocations of applications that use randomness from libgcrypt. Libgcrypt talks with it. But I haven't used the feature either (it is experimental) so I don't know for sure. Cc'ing libgcrypt-devel for corrections. > To clarify: I don't have an issue with gnutls eating randomness from the > pool. The randomness is there to be eaten. > > However, reading 3000+ bits every time a server (or client) starts up > does seem a bit excessive. I seriously doubt that it needs that many. The 3000+ bits part doesn't seem excessive to me, but I think the problem is that it is required each time a server or client starts up. Saving a random seeds file would help with this. Or using the libgcrypt daemon, if it works as I think it does. /Simon From simon at josefsson.org Fri Jan 4 13:41:38 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 13:41:38 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <82wsqpg492.fsf@mid.bfk.de> (Florian Weimer's message of "Fri, 04 Jan 2008 13:32:57 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> Message-ID: <87fxxdbw59.fsf@mocca.josefsson.org> Florian Weimer writes: > * Werner Koch: > >> Exim should properly intialize libgcrypt and create a random seed file. > > Is this documented somewhere? I'm a bit reluctant to add this kind of > layering violation. We could consider doing something like that in gnutls too, to help applications avoid having to do it themselves. However, the documentation on UPDATE_SEED seems somewhat discouraging. I'm not sure if gnutls is in a position to save a seeds file properly. It seems to better belong either inside libgcrypt or inside the application. `GCRYCTL_SET_RANDOM_SEED_FILE; Arguments: const char *filename' This command specifies the file, which is to be used as seed file for the PRNG. If the seed file is registered prior to initialization of the PRNG, the seed file's content (if it exists and seems to be valid) is fed into the PRNG pool. After the seed file has been registered, the PRNG can be signalled to write out the PRNG pool's content into the seed file with the following command. `GCRYCTL_UPDATE_RANDOM_SEED_FILE; Arguments: none' Write out the PRNG pool's content into the registered seed file. Multiple instances of the applications sharing the same random seed file can be started in parallel, in which case they will read out the same pool and then race for updating it (the last update overwrites earlier updates). They will differentiate only by the weak entropy that is added in read_seed_file based on the PID and clock, and up to 16 bytes of weak random non-blockingly. The consequence is that the output of these different instances is correlated to some extent. In the perfect scenario, the attacker can control (or at least guess) the PID and clock of the application, and drain the system's entropy pool to reduce the "up to 16 bytes" above to 0. Then the dependencies of the inital states of the pools are completely known. Note that this is not an issue if random of `GCRY_VERY_STRONG_RANDOM' quality is requested as in this case enough extra entropy gets mixed. When building/developing GnuTLS with non-libgcrypt providers, a seed file would definitely help -- Nettle's PRNG maintains one. So building good APIs for this now may help with non-libgcrypt providers in the future too. Anyway, the recommended approach should be documented in the gnutls manual eventually. /Simon From wk at gnupg.org Fri Jan 4 14:14:50 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jan 2008 14:14:50 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87k5mpbwfl.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 13:35:26 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> Message-ID: <87ve694trp.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 13:35, simon at josefsson.org said: > I think the daemon is there to help libgcrypt maintain randomness state > between invocations of applications that use randomness from libgcrypt. Right. And it is still flagged as experimental because it lacks any fair distribution of random to requesting clients. > The 3000+ bits part doesn't seem excessive to me, but I think the > problem is that it is required each time a server or client starts up. > Saving a random seeds file would help with this. Or using the libgcrypt You need a seed file for good performace. That's all. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jan 4 14:45:00 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jan 2008 14:45:00 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87fxxdbw59.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 13:41:38 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> Message-ID: <87r6gx4sdf.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 13:41, simon at josefsson.org said: > We could consider doing something like that in gnutls too, to help > applications avoid having to do it themselves. However, the > documentation on UPDATE_SEED seems somewhat discouraging. I'm not sure Let's say this description is very conservative and mostly written for security evaluations. The "up to 16 bytes of weak random " is not even correct for Linux because there we will always read 16 bytes from /dev/urandom and thus the whole theoretical attack won't work. I'll revise the description a bit. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Fri Jan 4 15:16:57 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 15:16:57 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87r6gx4sdf.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 14:45:00 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> Message-ID: <87tzltr7za.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 4 Jan 2008 13:41, simon at josefsson.org said: > >> We could consider doing something like that in gnutls too, to help >> applications avoid having to do it themselves. However, the >> documentation on UPDATE_SEED seems somewhat discouraging. I'm not sure > > Let's say this description is very conservative and mostly written for > security evaluations. The "up to 16 bytes of weak random " is not even > correct for Linux because there we will always read 16 bytes from > /dev/urandom and thus the whole theoretical attack won't work. I'll > revise the description a bit. Ok. Still, my main question is whether GnuTLS could utilize these hooks somehow. I guess we could have two functions: int gnutls_set_random_seed_file (const char *filename); int gnutls_update_random_seed (); The first function would have to be called before gnutls_global_init(). Then exim could invoke the function, to avoid having to call libgcrypt directly. However, when is it useful for an application to save the seed? Is it useful to do this often, or only when the process exits? Isn't it more reliable to never save the seed file, but to have a cron job to generate a new seed file that can be run every other week or so? Maybe the gnutls_update_random_seed function isn't needed. There is also the problem if something other than gnutls has already initialized libgcrypt. This could happen if exim links to some other library that uses libgcrypt, for example, a LDAP or database library, which gets initialized before. I'm not sure what we can do about this situation. I also dislike global functions like this. /Simon From fweimer at bfk.de Fri Jan 4 15:29:03 2008 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 04 Jan 2008 15:29:03 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 15:16:57 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> Message-ID: <828x35ekb4.fsf@mid.bfk.de> * Simon Josefsson: > Ok. Still, my main question is whether GnuTLS could utilize these hooks > somehow. I guess we could have two functions: > > int > gnutls_set_random_seed_file (const char *filename); > int > gnutls_update_random_seed (); > > The first function would have to be called before gnutls_global_init(). > Then exim could invoke the function, to avoid having to call libgcrypt > directly. I'm not sure how this applies to Exim, though. In many interesting scenarios, we've got a central daemon process. We could try to grab an exclusive log on the seed file, and if it succeeds, call gnutls_set_random_seed_file, and the update function when the daemon exits. However, I'm not really sure if this helps much because GNUTLS isn't run until after a fork, and the library needs to reinitialize the random pool anyway. We'd need a separate daemon for that (IIRC, this is what Cryptlib does). Or we could fix the kernel. The latter is hard because it is kind of difficult to show that there actually is a problem. Portability considerations favor the daemon approach, too, if you aren't interested in shifting blame around. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Fri Jan 4 15:39:20 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 15:39:20 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87ve694trp.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 14:14:50 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> Message-ID: <87prwhr6xz.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 4 Jan 2008 13:35, simon at josefsson.org said: > >> I think the daemon is there to help libgcrypt maintain randomness state >> between invocations of applications that use randomness from libgcrypt. > > Right. And it is still flagged as experimental because it lacks any > fair distribution of random to requesting clients. You mean the problem where one client requests a lot of randomness, which would hurt the randomness received by other clients? Maybe we could simply punt on that problem. The /dev/*random devices have the same problem, doesn't it? What practical problem would there be in documentation that states 'Make sure you don't run clients that requests too much entropy from the daemon'? Another solution, how about to refuse to give out entropy to processes not listed in a world-readable but root-writable file /etc/libgcryptd.conf file? /Simon From wk at gnupg.org Fri Jan 4 16:46:55 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jan 2008 16:46:55 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 15:16:57 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> Message-ID: <87k5mp385s.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 15:16, simon at josefsson.org said: > int > gnutls_set_random_seed_file (const char *filename); I don't think that is a good idea. gnutls does not provide the required thread hook function for libgcrypt and thus the appliaction needs to do this. If you want these functions you should also add the threading wrappers. Another problem is that if gnutls is used indirectly no seed file is used and thus the appliaction needs to do it anyway. The seed file should be application specific and not library specific. Thus I suggest to document this and change the application. > However, when is it useful for an application to save the seed? Is it > useful to do this often, or only when the process exits? Only at exit. In theory libgcrypt could do this automagically, but installing atexit handlers in libaries should in general be avoided. > Isn't it more reliable to never save the seed file, but to have a cron > job to generate a new seed file that can be run every other week or so? No, no. This is specific to libgcrypt and only the libgcrypt process may create it. The format and size may change without notice. > There is also the problem if something other than gnutls has already > initialized libgcrypt. This could happen if exim links to some other > library that uses libgcrypt, for example, a LDAP or database library, > which gets initialized before. I'm not sure what we can do about this > situation. I also dislike global functions like this. You can't do anything about it unless you turn gnutls into an RPC server so that it has its own process. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Fri Jan 4 16:50:45 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jan 2008 16:50:45 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87prwhr6xz.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 15:39:20 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> Message-ID: <87fxxd37ze.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 15:39, simon at josefsson.org said: > You mean the problem where one client requests a lot of randomness, > which would hurt the randomness received by other clients? Right. Though the IPC mechanims allows for several concurrent requests, the hear of the RNG serializes everything. > Maybe we could simply punt on that problem. The /dev/*random devices > have the same problem, doesn't it? Yes /dev/random has the same property. > Another solution, how about to refuse to give out entropy to processes > not listed in a world-readable but root-writable file > /etc/libgcryptd.conf file? Well it is experimental and I had similar ideas. If I remember right I implemented the daemon thing when we first talked about the exim problem or to help other short-living processes. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Fri Jan 4 17:01:20 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 17:01:20 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87k5mp385s.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 16:46:55 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <87k5mp385s.fsf@wheatstone.g10code.de> Message-ID: <8763y9r35b.fsf@mocca.josefsson.org> Werner Koch writes: > On Fri, 4 Jan 2008 15:16, simon at josefsson.org said: > >> int >> gnutls_set_random_seed_file (const char *filename); > > I don't think that is a good idea. gnutls does not provide the required > thread hook function for libgcrypt and thus the appliaction needs to do > this. If you want these functions you should also add the threading > wrappers. Ok. > Another problem is that if gnutls is used indirectly no seed file is > used and thus the appliaction needs to do it anyway. The seed file > should be application specific and not library specific. My idea would be that the filename in the API comes from the application. > Thus I suggest to document this and change the application. Right. So what should applications like exim do exactly? Is there anything more to think about than this: #include int main () { gcry_error_t rc; rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE, "/var/run/exim4/random.seed"); if (rc) error (EXIT_FAILURE, 0, "gcry_control SET_RANDOM_SEED_FILE"); DoIT(); /* initialize gnutls, runs the MTA.. */ rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE); if (rc) fprintf (stderr, "warning: gcry_control UPDATE_RANDOM_SEED_FILE failed (%d): %s", rc, gpg_strerror (rc)); return 0; } /Simon From simon at josefsson.org Fri Jan 4 17:08:03 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 17:08:03 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87fxxd37ze.fsf@wheatstone.g10code.de> (Werner Koch's message of "Fri, 04 Jan 2008 16:50:45 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> Message-ID: <871w8xr2u4.fsf@mocca.josefsson.org> Werner Koch writes: >> Another solution, how about to refuse to give out entropy to processes >> not listed in a world-readable but root-writable file >> /etc/libgcryptd.conf file? > > Well it is experimental and I had similar ideas. If I remember right I > implemented the daemon thing when we first talked about the exim problem > or to help other short-living processes. So I guess the question is for the exim people: which approach do you prefer? 1) Require that the system run the libgcrypt daemon to maintain a global randomness pool. (Or if the user uses a kernel that doesn't have PRNG saturation problems that Linux does... anyone knows if FreeBSD or GNU/Hurd have similar issues?) 2) To make exim link to and call libgcrypt's functions to read and update a random seed file instead? 3) continue discussing other solutions... For simplicity and non-experimentalness, I would recommend 2). I can assist in implementing this in exim, if that would help. We'd definitely need a good example of how to do this in the gnutls manual anyway. /Simon From simon at josefsson.org Fri Jan 4 17:54:08 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 17:54:08 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE Message-ID: <87wsqppm4v.fsf@mocca.josefsson.org> For a long time configure.in has contained: dnl In order to use the reentrant libc functions. dnl I hope it is portable enough. CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE" AM_CFLAGS="${CFLAGS}" The problem with this is that disabling the default -O2 from builds, which is typically done with 'make CFLAGS=-g', doesn't work. I think we could fix that problem by using: CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE" AM_CFLAGS="${AM_CFLAGS} -D_REENTRANT -D_THREAD_SAFE" But then I started to investigate why we need -D_REENTRANT -D_THREAD_SAFE at all. Glibc manual says: -- Macro: _REENTRANT -- Macro: _THREAD_SAFE If you define one of these macros, reentrant versions of several functions get declared. Some of the functions are specified in POSIX.1c but many others are only available on a few other systems or are unique to GNU libc. The problem is the delay in the standardization of the thread safe C library interface. Unlike on some other systems, no special version of the C library must be used for linking. There is only one version but while compiling this it must have been specified to compile as thread safe. Glibc features.h says: ... _GNU_SOURCE All of the above, plus GNU extensions. _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. ... However, grepping for _REENTRANT in /usr/include/* on my systems reveals that it is only used for 'getlogin_r', which we aren't using anyway. My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc systems. Does anyone know of other systems that needs these defines to work properly? I'm inclined to remove the lines from configure.in. If some other system needs this to have working standard C/POSIX functions, we could solve it via a gnulib module, I suppose. Thoughts? /Simon From simon at josefsson.org Fri Jan 4 18:09:29 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 18:09:29 +0100 Subject: Interoperability issues (Debian Bug #348046) In-Reply-To: <87tzltbxri.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 13:06:41 +0100") References: <20080103003901.GA14027@torres.zugschlus.de> <87tzltbxri.fsf@mocca.josefsson.org> Message-ID: <87myrlplfa.fsf@mocca.josefsson.org> Simon Josefsson writes: >> (E) Marc F .Clemente saying "me too" to (B) (Message 110) > > It would help if he could run gnutls-serv in debug mode and try to > reproduce the problem with thunderbird. I'll ask him in the bug report > to do this. Done. However, he never followed up in the bug report after the initial report, and didn't provide exim4 log messages. So there is little to go on here. I would think that if there is a problem between thunderbird and exim4+gnutls we would have seen this reported much more widely? A flaky network connection would explain Marc Clemente's problem report fully, especially since "it does not happen all the time". /Simon From ametzler at downhill.at.eu.org Fri Jan 4 18:06:49 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 4 Jan 2008 18:06:49 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <871w8xr2u4.fsf@mocca.josefsson.org> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> Message-ID: <20080104170649.GA4550@downhill.g.la> On 2008-01-04 Simon Josefsson wrote: [...] > 2) To make exim link to and call libgcrypt's functions to read and > update a random seed file instead? [...] > For simplicity and non-experimentalness, I would recommend 2). I can > assist in implementing this in exim, if that would help. We'd > definitely need a good example of how to do this in the gnutls manual > anyway. [...] Well, the basic patch for testing seems to be this one, basically identical to the skeleton you described. I gets down entropy-usage for a single STARTTLS to <300 bits from > 3000. ---------------------------- diff -Nur exim-orig/src/tls-gnu.c exim-4.68/src/tls-gnu.c --- exim-orig/build-tree/src/tls-gnu.c 2007-08-30 16:31:06.000000000 +0200 +++ exim-4.68/build-tree/src/tls-gnu.c 2008-01-04 15:58:40.000000000 +0100 @@ -20,6 +20,7 @@ #include #include +#include #define UNKNOWN_NAME "unknown" #define DH_BITS 1024 @@ -444,6 +445,8 @@ initialized = (host == NULL)? INITIALIZED_SERVER : INITIALIZED_CLIENT; +gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,"/var/run/exim4/random.seed"); + rc = gnutls_global_init(); if (rc < 0) return tls_error(US"tls-init", host, rc); @@ -1305,6 +1308,7 @@ { if (tls_active < 0) return; /* TLS was not active */ +gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE); if (shutdown) { DEBUG(D_tls) debug_printf("tls_close(): shutting down TLS\n"); ---------------------------- Error checking, and having the file in spool_directory instead (since it is a private directoy present on any exim installation) is missing. 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 simon at josefsson.org Fri Jan 4 18:24:46 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 18:24:46 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104170649.GA4550@downhill.g.la> (Andreas Metzler's message of "Fri, 4 Jan 2008 18:06:49 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> Message-ID: <87ejcxpkpt.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2008-01-04 Simon Josefsson wrote: > [...] >> 2) To make exim link to and call libgcrypt's functions to read and >> update a random seed file instead? > [...] >> For simplicity and non-experimentalness, I would recommend 2). I can >> assist in implementing this in exim, if that would help. We'd >> definitely need a good example of how to do this in the gnutls manual >> anyway. > [...] > > Well, the basic patch for testing seems to be this one, basically > identical to the skeleton you described. I gets down entropy-usage > for a single STARTTLS to <300 bits from > 3000. Nice. How much does a similar server consume using openssl? Do openssl used by exim use a seed file? /Simon From simon at josefsson.org Fri Jan 4 18:25:56 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 18:25:56 +0100 Subject: Interoperability issue with The Bat (Debian Bug #316522) In-Reply-To: <20080103002458.GA14155@torres.zugschlus.de> (Marc Haber's message of "Thu, 3 Jan 2008 01:24:58 +0100") References: <20080103002458.GA14155@torres.zugschlus.de> Message-ID: <87abnlpknv.fsf@mocca.josefsson.org> Marc Haber writes: > Hi, > > Simon Josefsson has suggested to me (a member of the maintainer team > for Exim's packages for the Debian Operating System) that it might be > a good idea to move a technical debate from our blogs > (http://blog.zugschlus.de/archives/585-exim4-vs.-OpenSSL-vs.-GnuTLS.html, > http://blog.josefsson.org/2007/11/09/response-to-gnutls-in-exim-debate/) > to gnutls-devel as this list is a better medium for archived discussion. > > I'll send a dedicated mail for each of Debian's bug reports, so that > the threads are not going to intermix. > > Debian Bug #316522, http://bugs.debian.org/316522 > ================================================= > > Simon writes: >> When the email client TheBat talks with exim4 4.50-8, gnutls (in >> exim4) will log (gnutls_handshake): An error was encountered at the >> TLS Finished packet calculation. Other clients than TheBat reportedly >> works. An older version of Exim4, specifically 4.32-2, worked though. >> It is unclear whether the version of GnuTLS changed when exim4 was >> upgraded from 4.32-2 to 4.50-8. > > Unfortunately, I wasn't able to find out which GnuTLS library exim4 > 4.32-2 was compiled against since snapshot.debian.net is incomplete > here. 4.32-4 was built for Debian on April 26, 2004. > > Exim 4.50-8 in Debian has a binary depends on libgnutls11 (>= 1.0.16). > >> There is no discussion of whether changing to OpenSSL would solve the >> problem. Conclusion: The problem with TheBat warrants debugging. >> However, this do not seem to be a widely reported problem. Further, >> TheBat is not free software so we cannot help debug it. Questions: >> The reported said earlier versions worked, which GnuTLS versions was >> this? Can the problem be pin-pointed to a specific GnuTLS release or >> Exim4 release? Does the problem go away with OpenSSL? > > Can you ask these questions to the submitter on the BTS? Done. > It might be possible (judging from > https://www.ritlabs.com/bt/view.php?id=5785) that The Bat by default > refuses to talk TLS to a server presenting a self-signed certificate. I also note that it is possible to download trial versions of TheBat. If we can get a recipe to reproduce the problem using it, that would help a lot. /Simon From linux at paip.net Fri Jan 4 16:33:43 2008 From: linux at paip.net (Ian Goldberg) Date: Fri, 4 Jan 2008 10:33:43 -0500 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87tzltr7za.fsf@mocca.josefsson.org> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> Message-ID: <20080104153343.GF31039@thunk.cs.uwaterloo.ca> On Fri, Jan 04, 2008 at 03:16:57PM +0100, Simon Josefsson wrote: > There is also the problem if something other than gnutls has already > initialized libgcrypt. This could happen if exim links to some other > library that uses libgcrypt, for example, a LDAP or database library, > which gets initialized before. I'm not sure what we can do about this > situation. I also dislike global functions like this. This is a nontrivial problem. If there are multiple clients of libgcrypt, and they use the globals in different ways, Bad Things happen. I've run into this with the Off-the-Record Messaging (OTR) plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with custom allocation functions), you can easily cause a crash. It would be very nice to have all of the libgcrypt global state encapsulated into a dynamically allocated region that's returned by the libgcrypt initialization, and passed into all other functions. [Macros could be provided that automatically reference the most recent allocation for backwards compatibility purposes.] - Ian From ametzler at downhill.at.eu.org Fri Jan 4 19:07:36 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Fri, 4 Jan 2008 19:07:36 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87ejcxpkpt.fsf@mocca.josefsson.org> References: <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> <87ejcxpkpt.fsf@mocca.josefsson.org> Message-ID: <20080104180736.GB4550@downhill.g.la> On 2008-01-04 Simon Josefsson wrote: > Andreas Metzler writes: > > On 2008-01-04 Simon Josefsson wrote: > > [...] > >> 2) To make exim link to and call libgcrypt's functions to read and > >> update a random seed file instead? > > [...] > >> For simplicity and non-experimentalness, I would recommend 2). I can > >> assist in implementing this in exim, if that would help. We'd > >> definitely need a good example of how to do this in the gnutls manual > >> anyway. > > [...] > > Well, the basic patch for testing seems to be this one, basically > > identical to the skeleton you described. I gets down entropy-usage > > for a single STARTTLS to <300 bits from > 3000. > Nice. How much does a similar server consume using openssl? Do openssl > used by exim use a seed file? Hello, testing with a exim linked against OpenSSL I get *slightly* less entropy usage (235 vs 289 bits in the first testrun) when connecting with swaks (perl/OpenSSL). These numbers were generated with the most simple method possible. - Watch /proc/sys/kernel/random/entropy_avail when STARTTLSing from localhost. Then STARTTLS from localhost to a remote server to find out how much of the the total entropy usage was generated by the client, instead of the server. OpenSSL does not safe any random seed. 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 simon at josefsson.org Fri Jan 4 20:40:44 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 20:40:44 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104180736.GB4550@downhill.g.la> (Andreas Metzler's message of "Fri, 4 Jan 2008 19:07:36 +0100") References: <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> <87ejcxpkpt.fsf@mocca.josefsson.org> <20080104180736.GB4550@downhill.g.la> Message-ID: <87wsqpnzur.fsf@mocca.josefsson.org> Andreas Metzler writes: > On 2008-01-04 Simon Josefsson wrote: >> Andreas Metzler writes: > >> > On 2008-01-04 Simon Josefsson wrote: >> > [...] >> >> 2) To make exim link to and call libgcrypt's functions to read and >> >> update a random seed file instead? >> > [...] >> >> For simplicity and non-experimentalness, I would recommend 2). I can >> >> assist in implementing this in exim, if that would help. We'd >> >> definitely need a good example of how to do this in the gnutls manual >> >> anyway. >> > [...] > >> > Well, the basic patch for testing seems to be this one, basically >> > identical to the skeleton you described. I gets down entropy-usage >> > for a single STARTTLS to <300 bits from > 3000. > >> Nice. How much does a similar server consume using openssl? Do openssl >> used by exim use a seed file? > > Hello, > > testing with a exim linked against OpenSSL I get *slightly* less > entropy usage (235 vs 289 bits in the first testrun) when connecting > with swaks (perl/OpenSSL). For my curiosity, what are those numbers if you run gnutls with a NORMAL:%COMPAT priority? Cipher padding needs one byte of randomness for every encrypted packet, disabling padding may thus reduce the randomness needed further. This assumes you actually sent some data back and forward, I don't whether you did. > These numbers were generated with the most simple method possible. - > Watch /proc/sys/kernel/random/entropy_avail when STARTTLSing from > localhost. Then STARTTLS from localhost to a remote server to find out > how much of the the total entropy usage was generated by the client, > instead of the server. So this result is both good and bad. It is good because we are now on par with openssl on this. It is bad because it suggests busier sites would run into the same problem, with both gnutls and openssl. However, that seems beyond the current problem. > OpenSSL does not safe any random seed. Interesting, 235/8=29.375 bytes. The minimum randomness needed per TLS session would be 28 bytes for client hello random_bytes plus 46 bytes for the PreMasterSecret (if RSA is used for key exchange). If openssl is using /dev/urandom, I think it is overly optimistic about the quality of that data. /Simon From simon at josefsson.org Fri Jan 4 20:29:25 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 04 Jan 2008 20:29:25 +0100 Subject: Interoperability issue with The Bat (Debian Bug #316522) In-Reply-To: <87abnlpknv.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 18:25:56 +0100") References: <20080103002458.GA14155@torres.zugschlus.de> <87abnlpknv.fsf@mocca.josefsson.org> Message-ID: <871w8xpey2.fsf@mocca.josefsson.org> Simon Josefsson writes: >> It might be possible (judging from >> https://www.ritlabs.com/bt/view.php?id=5785) that The Bat by default >> refuses to talk TLS to a server presenting a self-signed certificate. > > I also note that it is possible to download trial versions of TheBat. > If we can get a recipe to reproduce the problem using it, that would > help a lot. TheBat works under Wine, so I downloaded it and debugged this... FWIW, I can reproduce the problem: 2008-01-04 19:03:02 TLS error on connection from xxx.bredband.comhem.se (mocca.local) [x.y.z.q] (gnutls_handshake): An error was encountered at the TLS Finished packet calculation. Using gnutls-serv, I get the connection debug log [1] below. TheBat complains that the CA is untrusted, and I have to click continue. Then it fails with the TLS Finished packet calculation error. However, if I start gnutls-serv with --disable-client-cert I get the debug log [2] which is a successful TLS handshake! Even though the TLS handshake is successful TheBat doesn't send the e-mail though, and I don't know why, it may be because it expects CRLF and I only sent LF. Running openssl works, see debug log [3]. I also cannot TheBat to send the e-mail, possibly due to the same CRLF issue. I don't know why it works with openssl but not gnutls. It needs more debugging. Given that we don't have source for TheBat, this is somewhat difficult. I would want to instrument it to print some information about the TLS Finished computation, to see what it is using. /Simon Debug log [1]: jas at mocca:~$ ~/bin/gnutls-serv -p 5870 -d 4711 --x509keyfile ~/src/www-gnutls/test-credentials/x509-server-key.pem --x509certfile ~/src/www-gnutls/test-credentials/x509-server.pem --x509cafile ~/src/www-gnutls/test-credentials/x509-ca.pem Set static Diffie Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). Echo Server ready. Listening to port '5870'. |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 33 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[0] Handshake(22) with length: 51 |<7>| READ: Got 51 bytes from 5 |<7>| READ: read 51 bytes from 5 |<7>| 0000 - 01 00 00 2f 03 01 47 7e 7f ea 38 35 d5 07 47 e2 |<7>| 0001 - ea 58 fd 1c 39 87 57 76 ad a6 bc 0b a6 41 63 35 |<7>| 0002 - e9 18 0f 44 5a 31 00 00 08 00 35 00 2f 00 05 00 |<7>| 0003 - 0a 01 00 |<7>| RB: Have 5 bytes into buffer. Adding 51 bytes. |<7>| RB: Requested 56 bytes |<4>| REC[8076e00]: Decrypted Packet[0] Handshake(22) with length: 51 |<6>| BUF[HSK]: Inserted 51 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: CLIENT HELLO was received [51 bytes] |<6>| BUF[REC][HD]: Read 47 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 47 bytes of Data |<3>| HSK[8076e00]: Client's version: 3.1 |<2>| ASSERT: gnutls_db.c:327 |<2>| ASSERT: gnutls_db.c:247 |<2>| ASSERT: gnutls_extensions.c:159 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Selected cipher suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Selected Compression Method: NULL |<3>| HSK[8076e00]: SessionID: 674c898acd6cf0febb26777b94beeb83e1fcb9899a30b7cad5eb93dc2713681a |<3>| HSK[8076e00]: SERVER HELLO was send [74 bytes] |<6>| BUF[HSK]: Peeked 51 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[0] Handshake(22) with length: 74 |<7>| WRITE: Will write 79 bytes to 5. |<7>| WRITE: wrote 79 bytes to 5. Left 0 bytes. Total 79 bytes. |<7>| 0000 - 16 03 01 00 4a 02 00 00 46 03 01 47 7e 7f ea c0 |<7>| 0001 - fd 53 26 e1 f9 2f e2 e4 c6 8f 0f 35 ef e7 83 24 |<7>| 0002 - a3 5c da a1 04 7c 22 09 a5 2e c0 20 67 4c 89 8a |<7>| 0003 - cd 6c f0 fe bb 26 77 7b 94 be eb 83 e1 fc b9 89 |<7>| 0004 - 9a 30 b7 ca d5 eb 93 dc 27 13 68 1a 00 35 00 |<4>| REC[8076e00]: Sent Packet[1] Handshake(22) with length: 79 |<3>| HSK[8076e00]: CERTIFICATE was send [612 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[1] Handshake(22) with length: 612 |<7>| WRITE: Will write 617 bytes to 5. |<7>| WRITE: wrote 617 bytes to 5. Left 0 bytes. Total 617 bytes. |<7>| 0000 - 16 03 01 02 64 0b 00 02 60 00 02 5d 00 02 5a 30 |<7>| 0001 - 82 02 56 30 82 01 c1 a0 03 02 01 02 02 04 46 26 |<7>| 0002 - 1d 31 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 |<7>| 0003 - 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 |<7>| 0004 - 4c 53 20 74 65 73 74 20 43 41 30 1e 17 0d 30 37 |<7>| 0005 - 30 34 31 38 31 33 32 39 32 31 5a 17 0d 30 38 30 |<7>| 0006 - 34 31 37 31 33 32 39 32 31 5a 30 37 31 1b 30 19 |<7>| 0007 - 06 03 55 04 0a 13 12 47 6e 75 54 4c 53 20 74 65 |<7>| 0008 - 73 74 20 73 65 72 76 65 72 31 18 30 16 06 03 55 |<7>| 0009 - 04 03 13 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e |<7>| 000a - 6f 72 67 30 81 9c 30 0b 06 09 2a 86 48 86 f7 0d |<7>| 000b - 01 01 01 03 81 8c 00 30 81 88 02 81 80 d7 ba 5c |<7>| 000c - af a3 0c f0 2e a9 27 56 aa 53 8e a8 eb 7f 81 75 |<7>| 000d - 4c 6b 98 be 4a ea b7 1e f8 4b c3 6a c4 da 0d 00 |<7>| 000e - b8 ea 4c 13 1f 36 16 93 de 72 ef c6 a4 5e b2 6e |<7>| 000f - b6 ca 0a 88 55 75 90 96 ed a6 57 bc 0c 3b 76 0d |<7>| 0010 - 97 1e bd e9 ec 7f d3 a9 ec fb 85 64 a0 6b a0 48 |<7>| 0011 - ce 77 7e 73 9c 31 13 ff 3d c8 ae a5 60 6e d9 b6 |<7>| 0012 - 8c 5a 9a 6f b6 be 9f 6a bd a7 f0 a0 33 27 f5 b7 |<7>| 0013 - 1d 92 e5 96 9c 73 52 d6 9f d6 c8 8e b1 02 03 01 |<7>| 0014 - 00 01 a3 81 93 30 81 90 30 0c 06 03 55 1d 13 01 |<7>| 0015 - 01 ff 04 02 30 00 30 1a 06 03 55 1d 11 04 13 30 |<7>| 0016 - 11 82 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 6f |<7>| 0017 - 72 67 30 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b |<7>| 0018 - 06 01 05 05 07 03 01 30 0f 06 03 55 1d 0f 01 01 |<7>| 0019 - ff 04 05 03 03 07 a0 00 30 1d 06 03 55 1d 0e 04 |<7>| 001a - 16 04 14 eb c7 45 6e e5 f8 25 ca 8c 8d 83 0d 74 |<7>| 001b - e9 86 d4 dd 55 b4 75 30 1f 06 03 55 1d 23 04 18 |<7>| 001c - 30 16 80 14 e9 3c 1c fb ad 92 6e e6 06 a4 56 2c |<7>| 001d - a2 e1 c0 53 27 c8 f2 95 30 0b 06 09 2a 86 48 86 |<7>| 001e - f7 0d 01 01 05 03 81 81 00 68 51 0f 4e df bb 6f |<7>| 001f - 3b c1 b8 e7 fb f9 09 9e 41 c9 f6 f6 44 fa 06 cc |<7>| 0020 - a1 d5 11 c9 5d ff 0a 4e 4e 50 45 fc 29 ea 88 1b |<7>| 0021 - a7 de 09 41 67 0d 43 f4 bb 60 31 47 82 50 f5 03 |<7>| 0022 - 05 0d 05 15 f0 77 7a e2 52 c3 27 b3 18 1e 48 3c |<7>| 0023 - 58 05 f2 58 6c 32 de a2 13 41 b2 a6 8f 0c 96 fb |<7>| 0024 - 5d a8 a5 59 b3 10 29 f0 1b 15 0f 1c 9c ec 60 ac |<7>| 0025 - e2 8b 51 04 56 27 42 b7 1f 25 d1 32 16 ea 8d d2 |<7>| 0026 - c8 69 08 82 bd 02 ee 8b 3a |<4>| REC[8076e00]: Sent Packet[2] Handshake(22) with length: 617 |<3>| HSK[8076e00]: CERTIFICATE REQUEST was send [38 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[2] Handshake(22) with length: 38 |<7>| WRITE: Will write 43 bytes to 5. |<7>| WRITE: wrote 43 bytes to 5. Left 0 bytes. Total 43 bytes. |<7>| 0000 - 16 03 01 00 26 0d 00 00 22 02 01 02 00 1d 00 1b |<7>| 0001 - 30 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 |<7>| 0002 - 54 4c 53 20 74 65 73 74 20 43 41 |<4>| REC[8076e00]: Sent Packet[3] Handshake(22) with length: 43 |<3>| HSK[8076e00]: SERVER HELLO DONE was send [4 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[3] Handshake(22) with length: 4 |<7>| WRITE: Will write 9 bytes to 5. |<7>| WRITE: wrote 9 bytes to 5. Left 0 bytes. Total 9 bytes. |<7>| 0000 - 16 03 01 00 04 0e 00 00 00 |<4>| REC[8076e00]: Sent Packet[4] Handshake(22) with length: 9 |<7>| READ: -1 returned from 5, errno=11 gerrno=0 |<2>| ASSERT: gnutls_buffers.c:360 |<2>| ASSERT: gnutls_buffers.c:1152 |<2>| ASSERT: gnutls_handshake.c:1012 |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 07 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[1] Handshake(22) with length: 7 |<7>| READ: Got 7 bytes from 5 |<7>| READ: read 7 bytes from 5 |<7>| 0000 - 0b 00 00 03 00 00 00 |<7>| RB: Have 5 bytes into buffer. Adding 7 bytes. |<7>| RB: Requested 12 bytes |<4>| REC[8076e00]: Decrypted Packet[1] Handshake(22) with length: 7 |<6>| BUF[HSK]: Inserted 7 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: CERTIFICATE was received [7 bytes] |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 3 bytes of Data |<2>| ASSERT: auth_cert.c:877 |<7>| READ: -1 returned from 5, errno=11 gerrno=0 |<2>| ASSERT: gnutls_buffers.c:360 |<2>| ASSERT: gnutls_buffers.c:1152 |<2>| ASSERT: gnutls_handshake.c:1012 |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 86 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[2] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[2] Handshake(22) with length: 134 |<7>| READ: Got 134 bytes from 5 |<7>| READ: read 134 bytes from 5 |<7>| 0000 - 10 00 00 82 00 80 00 4a d8 ba 15 cc c7 3d 07 2d |<7>| 0001 - 24 b3 6a 8b 1a 3f 6d aa d9 63 65 dd 05 e1 71 24 |<7>| 0002 - 84 7b 54 a2 15 b1 90 1d 08 16 bf 7c c4 f8 c0 a6 |<7>| 0003 - 3b 44 80 f4 32 dd 4d 83 72 73 82 b2 4c 26 3d 6e |<7>| 0004 - ef f1 f7 85 32 9b c1 e7 44 80 79 f0 16 fe 1b 63 |<7>| 0005 - 05 1d 0d 9e 7b 9a bd 93 63 12 81 7c 2d e5 cb 70 |<7>| 0006 - 8b ea 33 dc fa dd dd ec 7d b6 09 e2 bd 55 a9 dc |<7>| 0007 - 43 b7 92 57 35 f8 3f ea 9c 9b aa 71 a3 f4 3c 9e |<7>| 0008 - 0e 66 f7 84 fc 1c |<7>| RB: Have 5 bytes into buffer. Adding 134 bytes. |<7>| RB: Requested 139 bytes |<4>| REC[8076e00]: Decrypted Packet[2] Handshake(22) with length: 134 |<6>| BUF[HSK]: Inserted 134 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: CLIENT KEY EXCHANGE was received [134 bytes] |<6>| BUF[REC][HD]: Read 130 bytes of Data(22) |<6>| BUF[HSK]: Peeked 7 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 130 bytes of Data |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 14 03 01 00 01 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[3] Change Cipher Spec(20) with length: 1 |<4>| REC[8076e00]: Received Packet[3] Change Cipher Spec(20) with length: 1 |<7>| READ: Got 1 bytes from 5 |<7>| READ: read 1 bytes from 5 |<7>| 0000 - 01 |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. |<7>| RB: Requested 6 bytes |<4>| REC[8076e00]: ChangeCipherSpec Packet was received |<9>| INT: PREMASTER SECRET[48]: 0301098e27eb8e6550ec38ef93f166867e960aae7ddb720c8639c6ad1671190ce312bb7404f79a8e2c94079be95d5df2 |<9>| INT: CLIENT RANDOM[32]: 477e7fea3835d50747e2ea58fd1c39875776ada6bc0ba6416335e9180f445a31 |<9>| INT: SERVER RANDOM[32]: 477e7feac0fd5326e1f92fe2e4c68f0f35efe78324a35cdaa1047c2209a52ec0 |<9>| INT: MASTER SECRET: d3cd83cf9a7d93e1e29c412d25d22b76db818b4f698dd409d0fd2ab660a421366bc616c0c99fd6371ac12ffefb14e23b |<9>| INT: KEY BLOCK[136]: 02595fa908cf516d7d6ba341e267caeef9a8462e523dd785a40d67c1f2073e11 |<9>| INT: CLIENT WRITE KEY [32]: 0ee1fe93e37314f57e66d59819a600efe8f3735aed5ce459b5b7a18246911b30 |<9>| INT: SERVER WRITE KEY [32]: d9e86b6714ec5f79e612b26f3769b6b1b14ebc14c5cab779b8974c41ac0566e5 |<3>| HSK[8076e00]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Initializing internal [read] cipher sessions |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 30 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[0] Handshake(22) with length: 48 |<7>| READ: Got 48 bytes from 5 |<7>| READ: read 48 bytes from 5 |<7>| 0000 - 7a 84 a5 1a b6 35 01 c4 db 5b 5e 33 9c 5f db aa |<7>| 0001 - 80 e1 31 05 46 ce 43 01 68 03 39 79 68 3b e9 d3 |<7>| 0002 - ea 6f 41 3c 43 35 b4 03 ed 41 04 d6 aa 45 65 49 |<7>| 0003 - |<7>| RB: Have 5 bytes into buffer. Adding 48 bytes. |<7>| RB: Requested 53 bytes |<4>| REC[8076e00]: Decrypted Packet[0] Handshake(22) with length: 16 |<6>| BUF[HSK]: Inserted 16 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: FINISHED was received [16 bytes] |<6>| BUF[REC][HD]: Read 12 bytes of Data(22) |<6>| BUF[HSK]: Peeked 134 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 12 bytes of Data |<2>| ASSERT: gnutls_handshake.c:620 |<2>| ASSERT: gnutls_handshake.c:2502 |<2>| ASSERT: gnutls_handshake.c:2634 |<6>| BUF[HSK]: Cleared Data from buffer Error in handshake Error: An error was encountered at the TLS Finished packet calculation. |<4>| REC: Sending Alert[2|80] - Internal error |<4>| REC[8076e00]: Sending Packet[4] Alert(21) with length: 2 |<7>| WRITE: Will write 7 bytes to 5. |<7>| WRITE: wrote 7 bytes to 5. Left 0 bytes. Total 7 bytes. |<7>| 0000 - 15 03 01 00 02 02 50 |<4>| REC[8076e00]: Sent Packet[5] Alert(21) with length: 7 |<2>| ASSERT: gnutls_record.c:260 Debug log [2]: jas at mocca:~$ ~/bin/gnutls-serv -p 5870 -d 4711 --x509keyfile ~/src/www-gnutls/test-credentials/x509-server-key.pem --x509certfile ~/src/www-gnutls/test-credentials/x509-server.pem --x509cafile ~/src/www-gnutls/test-credentials/x509-ca.pem --disable-client-cert Set static Diffie Hellman parameters, consider --dhparams. Processed 1 CA certificate(s). Echo Server ready. Listening to port '5870'. |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 33 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[0] Handshake(22) with length: 51 |<7>| READ: Got 51 bytes from 5 |<7>| READ: read 51 bytes from 5 |<7>| 0000 - 01 00 00 2f 03 01 47 7e 81 22 69 9e b4 30 84 03 |<7>| 0001 - ac a9 40 27 eb 83 a9 55 a4 60 e1 82 51 ee 2c b0 |<7>| 0002 - 8b a1 ea a9 43 6b 00 00 08 00 35 00 2f 00 05 00 |<7>| 0003 - 0a 01 00 |<7>| RB: Have 5 bytes into buffer. Adding 51 bytes. |<7>| RB: Requested 56 bytes |<4>| REC[8076e00]: Decrypted Packet[0] Handshake(22) with length: 51 |<6>| BUF[HSK]: Inserted 51 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: CLIENT HELLO was received [51 bytes] |<6>| BUF[REC][HD]: Read 47 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 47 bytes of Data |<3>| HSK[8076e00]: Client's version: 3.1 |<2>| ASSERT: gnutls_db.c:327 |<2>| ASSERT: gnutls_db.c:247 |<2>| ASSERT: gnutls_extensions.c:159 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_ARCFOUR_MD5 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 |<3>| HSK[8076e00]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 |<3>| HSK[8076e00]: Selected cipher suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Selected Compression Method: NULL |<3>| HSK[8076e00]: SessionID: ee4e9fb607619b26881520e2db07a39ed2371ab4551ec8974cb8d359ddc5c8d5 |<3>| HSK[8076e00]: SERVER HELLO was send [74 bytes] |<6>| BUF[HSK]: Peeked 51 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[0] Handshake(22) with length: 74 |<7>| WRITE: Will write 79 bytes to 5. |<7>| WRITE: wrote 79 bytes to 5. Left 0 bytes. Total 79 bytes. |<7>| 0000 - 16 03 01 00 4a 02 00 00 46 03 01 47 7e 81 22 b9 |<7>| 0001 - 96 81 9c ac 8b aa ec 38 3e 0a de 6b d6 dd e1 3e |<7>| 0002 - dc 55 2d ee 84 49 c4 0a 98 db 41 20 ee 4e 9f b6 |<7>| 0003 - 07 61 9b 26 88 15 20 e2 db 07 a3 9e d2 37 1a b4 |<7>| 0004 - 55 1e c8 97 4c b8 d3 59 dd c5 c8 d5 00 35 00 |<4>| REC[8076e00]: Sent Packet[1] Handshake(22) with length: 79 |<3>| HSK[8076e00]: CERTIFICATE was send [612 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[1] Handshake(22) with length: 612 |<7>| WRITE: Will write 617 bytes to 5. |<7>| WRITE: wrote 617 bytes to 5. Left 0 bytes. Total 617 bytes. |<7>| 0000 - 16 03 01 02 64 0b 00 02 60 00 02 5d 00 02 5a 30 |<7>| 0001 - 82 02 56 30 82 01 c1 a0 03 02 01 02 02 04 46 26 |<7>| 0002 - 1d 31 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 |<7>| 0003 - 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 |<7>| 0004 - 4c 53 20 74 65 73 74 20 43 41 30 1e 17 0d 30 37 |<7>| 0005 - 30 34 31 38 31 33 32 39 32 31 5a 17 0d 30 38 30 |<7>| 0006 - 34 31 37 31 33 32 39 32 31 5a 30 37 31 1b 30 19 |<7>| 0007 - 06 03 55 04 0a 13 12 47 6e 75 54 4c 53 20 74 65 |<7>| 0008 - 73 74 20 73 65 72 76 65 72 31 18 30 16 06 03 55 |<7>| 0009 - 04 03 13 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e |<7>| 000a - 6f 72 67 30 81 9c 30 0b 06 09 2a 86 48 86 f7 0d |<7>| 000b - 01 01 01 03 81 8c 00 30 81 88 02 81 80 d7 ba 5c |<7>| 000c - af a3 0c f0 2e a9 27 56 aa 53 8e a8 eb 7f 81 75 |<7>| 000d - 4c 6b 98 be 4a ea b7 1e f8 4b c3 6a c4 da 0d 00 |<7>| 000e - b8 ea 4c 13 1f 36 16 93 de 72 ef c6 a4 5e b2 6e |<7>| 000f - b6 ca 0a 88 55 75 90 96 ed a6 57 bc 0c 3b 76 0d |<7>| 0010 - 97 1e bd e9 ec 7f d3 a9 ec fb 85 64 a0 6b a0 48 |<7>| 0011 - ce 77 7e 73 9c 31 13 ff 3d c8 ae a5 60 6e d9 b6 |<7>| 0012 - 8c 5a 9a 6f b6 be 9f 6a bd a7 f0 a0 33 27 f5 b7 |<7>| 0013 - 1d 92 e5 96 9c 73 52 d6 9f d6 c8 8e b1 02 03 01 |<7>| 0014 - 00 01 a3 81 93 30 81 90 30 0c 06 03 55 1d 13 01 |<7>| 0015 - 01 ff 04 02 30 00 30 1a 06 03 55 1d 11 04 13 30 |<7>| 0016 - 11 82 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 6f |<7>| 0017 - 72 67 30 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b |<7>| 0018 - 06 01 05 05 07 03 01 30 0f 06 03 55 1d 0f 01 01 |<7>| 0019 - ff 04 05 03 03 07 a0 00 30 1d 06 03 55 1d 0e 04 |<7>| 001a - 16 04 14 eb c7 45 6e e5 f8 25 ca 8c 8d 83 0d 74 |<7>| 001b - e9 86 d4 dd 55 b4 75 30 1f 06 03 55 1d 23 04 18 |<7>| 001c - 30 16 80 14 e9 3c 1c fb ad 92 6e e6 06 a4 56 2c |<7>| 001d - a2 e1 c0 53 27 c8 f2 95 30 0b 06 09 2a 86 48 86 |<7>| 001e - f7 0d 01 01 05 03 81 81 00 68 51 0f 4e df bb 6f |<7>| 001f - 3b c1 b8 e7 fb f9 09 9e 41 c9 f6 f6 44 fa 06 cc |<7>| 0020 - a1 d5 11 c9 5d ff 0a 4e 4e 50 45 fc 29 ea 88 1b |<7>| 0021 - a7 de 09 41 67 0d 43 f4 bb 60 31 47 82 50 f5 03 |<7>| 0022 - 05 0d 05 15 f0 77 7a e2 52 c3 27 b3 18 1e 48 3c |<7>| 0023 - 58 05 f2 58 6c 32 de a2 13 41 b2 a6 8f 0c 96 fb |<7>| 0024 - 5d a8 a5 59 b3 10 29 f0 1b 15 0f 1c 9c ec 60 ac |<7>| 0025 - e2 8b 51 04 56 27 42 b7 1f 25 d1 32 16 ea 8d d2 |<7>| 0026 - c8 69 08 82 bd 02 ee 8b 3a |<4>| REC[8076e00]: Sent Packet[2] Handshake(22) with length: 617 |<3>| HSK[8076e00]: SERVER HELLO DONE was send [4 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[2] Handshake(22) with length: 4 |<7>| WRITE: Will write 9 bytes to 5. |<7>| WRITE: wrote 9 bytes to 5. Left 0 bytes. Total 9 bytes. |<7>| 0000 - 16 03 01 00 04 0e 00 00 00 |<4>| REC[8076e00]: Sent Packet[3] Handshake(22) with length: 9 |<7>| READ: -1 returned from 5, errno=11 gerrno=0 |<2>| ASSERT: gnutls_buffers.c:360 |<2>| ASSERT: gnutls_buffers.c:1152 |<2>| ASSERT: gnutls_handshake.c:1012 |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 86 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[1] Handshake(22) with length: 134 |<7>| READ: Got 134 bytes from 5 |<7>| READ: read 134 bytes from 5 |<7>| 0000 - 10 00 00 82 00 80 c4 49 53 90 12 3a d4 4c 40 e0 |<7>| 0001 - 1a 70 e1 21 ae 0b 43 4b 26 dd 00 2a 48 b9 70 43 |<7>| 0002 - 7f 75 55 a6 5b 27 05 80 b8 fc 27 81 64 dd 04 28 |<7>| 0003 - 19 b2 1b 64 5f 8e 13 90 a2 cd 31 b6 c5 1a fe 6f |<7>| 0004 - 77 fc a0 d0 9d e0 48 24 93 07 52 31 79 c8 54 77 |<7>| 0005 - 81 6e 36 09 72 04 3e 21 5c 15 6a d2 8c 72 65 c6 |<7>| 0006 - d1 a3 a2 4c e6 44 6f 82 ef b4 34 58 3f f9 3f 72 |<7>| 0007 - 22 99 6b 8a 62 23 46 0c e6 ac b4 83 50 0a 36 9b |<7>| 0008 - 0e 59 6f bf a2 04 |<7>| RB: Have 5 bytes into buffer. Adding 134 bytes. |<7>| RB: Requested 139 bytes |<4>| REC[8076e00]: Decrypted Packet[1] Handshake(22) with length: 134 |<6>| BUF[HSK]: Inserted 134 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: CLIENT KEY EXCHANGE was received [134 bytes] |<6>| BUF[REC][HD]: Read 130 bytes of Data(22) |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 130 bytes of Data |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 14 03 01 00 01 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[2] Change Cipher Spec(20) with length: 1 |<4>| REC[8076e00]: Received Packet[2] Change Cipher Spec(20) with length: 1 |<7>| READ: Got 1 bytes from 5 |<7>| READ: read 1 bytes from 5 |<7>| 0000 - 01 |<7>| RB: Have 5 bytes into buffer. Adding 1 bytes. |<7>| RB: Requested 6 bytes |<4>| REC[8076e00]: ChangeCipherSpec Packet was received |<9>| INT: PREMASTER SECRET[48]: 0301b8adc0c631d4c0b78173285fdf3dd79a8e2a54eedafb47803d4c99f2bffe25d778fe7b7a18a2cb861cd52e70d516 |<9>| INT: CLIENT RANDOM[32]: 477e8122699eb4308403aca94027eb83a955a460e18251ee2cb08ba1eaa9436b |<9>| INT: SERVER RANDOM[32]: 477e8122b996819cac8baaec383e0ade6bd6dde13edc552dee8449c40a98db41 |<9>| INT: MASTER SECRET: 72cb3bd4090aa2280752dd8826ed6c99da143b90071400871e8e00411fe4ae8cf7d5d8847d83b8cb9b8bc04b15b6d4c0 |<9>| INT: KEY BLOCK[136]: e0ed77336974428c9eaa005d4c3f275a982310570200419029264e70437669a6 |<9>| INT: CLIENT WRITE KEY [32]: 2321d92c1e7235b6e570c4c87775d1bc53f4613d4bc954b13c49979c6cd2e670 |<9>| INT: SERVER WRITE KEY [32]: 79579b995d7163b918dbcf1c323785240c628178869214f97193dc643b3acb0a |<3>| HSK[8076e00]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Initializing internal [read] cipher sessions |<7>| READ: Got 5 bytes from 5 |<7>| READ: read 5 bytes from 5 |<7>| 0000 - 16 03 01 00 30 |<7>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<7>| RB: Requested 5 bytes |<4>| REC[8076e00]: Expected Packet[0] Handshake(22) with length: 1 |<4>| REC[8076e00]: Received Packet[0] Handshake(22) with length: 48 |<7>| READ: Got 48 bytes from 5 |<7>| READ: read 48 bytes from 5 |<7>| 0000 - 41 d1 0a e3 00 c5 bd 5a f4 f7 b0 dc 97 f8 9e ad |<7>| 0001 - d6 3b 74 c6 1b 67 1b 69 2c 2b ab 3b 18 41 5a 77 |<7>| 0002 - 29 f4 85 d0 df 06 e7 c2 a1 69 08 ed 6b 58 bf 89 |<7>| 0003 - |<7>| RB: Have 5 bytes into buffer. Adding 48 bytes. |<7>| RB: Requested 53 bytes |<4>| REC[8076e00]: Decrypted Packet[0] Handshake(22) with length: 16 |<6>| BUF[HSK]: Inserted 16 bytes of Data(22) |<6>| BUF[REC][HD]: Read 1 bytes of Data(22) |<6>| BUF[REC][HD]: Read 3 bytes of Data(22) |<3>| HSK[8076e00]: FINISHED was received [16 bytes] |<6>| BUF[REC][HD]: Read 12 bytes of Data(22) |<6>| BUF[HSK]: Peeked 134 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<6>| BUF[HSK]: Inserted 4 bytes of Data |<6>| BUF[HSK]: Inserted 12 bytes of Data |<3>| REC[8076e00]: Sent ChangeCipherSpec |<4>| REC[8076e00]: Sending Packet[3] Change Cipher Spec(20) with length: 1 |<7>| WRITE: Will write 6 bytes to 5. |<7>| WRITE: wrote 6 bytes to 5. Left 0 bytes. Total 6 bytes. |<7>| 0000 - 14 03 01 00 01 01 |<4>| REC[8076e00]: Sent Packet[4] Change Cipher Spec(20) with length: 6 |<3>| HSK[8076e00]: Cipher Suite: RSA_AES_256_CBC_SHA1 |<3>| HSK[8076e00]: Initializing internal [write] cipher sessions |<6>| BUF[HSK]: Peeked 16 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<3>| HSK[8076e00]: FINISHED was send [16 bytes] |<6>| BUF[HSK]: Peeked 0 bytes of Data |<6>| BUF[HSK]: Emptied buffer |<4>| REC[8076e00]: Sending Packet[0] Handshake(22) with length: 16 |<7>| WRITE: Will write 53 bytes to 5. |<7>| WRITE: wrote 53 bytes to 5. Left 0 bytes. Total 53 bytes. |<7>| 0000 - 16 03 01 00 30 ed 01 52 ea 14 a6 8b 80 21 a4 74 |<7>| 0001 - 5c 4e f8 56 e0 94 d6 a9 52 c4 17 37 19 bd 69 45 |<7>| 0002 - c3 64 b5 d4 21 64 8e 17 4e 5c 21 a4 ab 9d 56 16 |<7>| 0003 - 5c ba fc 6d 43 |<4>| REC[8076e00]: Sent Packet[1] Handshake(22) with length: 53 |<6>| BUF[HSK]: Cleared Data from buffer * connection from ::ffff:192.168.1.9, port 43206 - Server has requested a certificate. - Certificate type: X.509 No certificates found! - Peer did not send any certificate. - Version: TLS1.0 - Key Exchange: RSA - Cipher: AES-256-CBC - MAC: SHA1 - Compression: NULL |<7>| READ: -1 returned from 5, errno=11 gerrno=0 |<2>| ASSERT: gnutls_buffers.c:360 Debug log [3]: jas at mocca:~/src/openssl-0.9.8g/apps$ ./openssl s_server -accept 5870 -cert /home/jas/src/www-gnutls/test-credentials/x509-server.pem -key ~/src/www-gnutls/test-credentials/x509-server-key.pem -CAfile ~/src/www-gnutls/test-credentials/x509-ca.pem -debug -msg -chain -verify 0 verify depth is 0 Using default temp DH parameters Using default temp ECDH parameters ACCEPT read from 0x81c56a0 [0x81cad28] (11 bytes => 11 (0xB)) 0000 - 16 03 01 00 33 01 00 00-2f 03 01 ....3.../.. read from 0x81c56a0 [0x81cad33] (45 bytes => 45 (0x2D)) 0000 - 47 7e 88 09 ff e1 e6 1c-f0 13 10 e7 e6 05 19 eb G~.............. 0010 - 7a 1d ee 66 e4 35 50 06-63 75 9f 55 89 ad 36 0f z..f.5P.cu.U..6. 0020 - 00 00 08 00 35 00 2f 00-05 00 0a 01 ....5./..... 002d - <<< TLS 1.0 Handshake [length 0033], ClientHello 01 00 00 2f 03 01 47 7e 88 09 ff e1 e6 1c f0 13 10 e7 e6 05 19 eb 7a 1d ee 66 e4 35 50 06 63 75 9f 55 89 ad 36 0f 00 00 08 00 35 00 2f 00 05 00 0a 01 00 >>> TLS 1.0 Handshake [length 004a], ServerHello 02 00 00 46 03 01 47 7e 88 09 04 ac 62 00 c0 bf 8e a1 10 57 60 3f 86 d4 52 f1 98 6f 74 a2 88 45 9e 3f d9 ed 60 5e 20 17 d5 3f ef 40 42 25 39 e1 37 5f 45 7f 62 11 5a 55 a8 38 9f 15 00 e9 cb d6 10 46 bf 61 6d 77 af 00 35 00 write to 0x81c56a0 [0x81d4ef0] (79 bytes => 79 (0x4F)) 0000 - 16 03 01 00 4a 02 00 00-46 03 01 47 7e 88 09 04 ....J...F..G~... 0010 - ac 62 00 c0 bf 8e a1 10-57 60 3f 86 d4 52 f1 98 .b......W`?..R.. 0020 - 6f 74 a2 88 45 9e 3f d9-ed 60 5e 20 17 d5 3f ef ot..E.?..`^ ..?. 0030 - 40 42 25 39 e1 37 5f 45-7f 62 11 5a 55 a8 38 9f @B%9.7_E.b.ZU.8. 0040 - 15 00 e9 cb d6 10 46 bf-61 6d 77 af 00 35 ......F.amw..5 004f - >>> TLS 1.0 Handshake [length 0452], Certificate 0b 00 04 4e 00 04 4b 00 02 5a 30 82 02 56 30 82 01 c1 a0 03 02 01 02 02 04 46 26 1d 31 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 4c 53 20 74 65 73 74 20 43 41 30 1e 17 0d 30 37 30 34 31 38 31 33 32 39 32 31 5a 17 0d 30 38 30 34 31 37 31 33 32 39 32 31 5a 30 37 31 1b 30 19 06 03 55 04 0a 13 12 47 6e 75 54 4c 53 20 74 65 73 74 20 73 65 72 76 65 72 31 18 30 16 06 03 55 04 03 13 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 6f 72 67 30 81 9c 30 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03 81 8c 00 30 81 88 02 81 80 d7 ba 5c af a3 0c f0 2e a9 27 56 aa 53 8e a8 eb 7f 81 75 4c 6b 98 be 4a ea b7 1e f8 4b c3 6a c4 da 0d 00 b8 ea 4c 13 1f 36 16 93 de 72 ef c6 a4 5e b2 6e b6 ca 0a 88 55 75 90 96 ed a6 57 bc 0c 3b 76 0d 97 1e bd e9 ec 7f d3 a9 ec fb 85 64 a0 6b a0 48 ce 77 7e 73 9c 31 13 ff 3d c8 ae a5 60 6e d9 b6 8c 5a 9a 6f b6 be 9f 6a bd a7 f0 a0 33 27 f5 b7 1d 92 e5 96 9c 73 52 d6 9f d6 c8 8e b1 02 03 01 00 01 a3 81 93 30 81 90 30 0c 06 03 55 1d 13 01 01 ff 04 02 30 00 30 1a 06 03 55 1d 11 04 13 30 11 82 0f 74 65 73 74 2e 67 6e 75 74 6c 73 2e 6f 72 67 30 13 06 03 55 1d 25 04 0c 30 0a 06 08 2b 06 01 05 05 07 03 01 30 0f 06 03 55 1d 0f 01 01 ff 04 05 03 03 07 a0 00 30 1d 06 03 55 1d 0e 04 16 04 14 eb c7 45 6e e5 f8 25 ca 8c 8d 83 0d 74 e9 86 d4 dd 55 b4 75 30 1f 06 03 55 1d 23 04 18 30 16 80 14 e9 3c 1c fb ad 92 6e e6 06 a4 56 2c a2 e1 c0 53 27 c8 f2 95 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 03 81 81 00 68 51 0f 4e df bb 6f 3b c1 b8 e7 fb f9 09 9e 41 c9 f6 f6 44 fa 06 cc a1 d5 11 c9 5d ff 0a 4e 4e 50 45 fc 29 ea 88 1b a7 de 09 41 67 0d 43 f4 bb 60 31 47 82 50 f5 03 05 0d 05 15 f0 77 7a e2 52 c3 27 b3 18 1e 48 3c 58 05 f2 58 6c 32 de a2 13 41 b2 a6 8f 0c 96 fb 5d a8 a5 59 b3 10 29 f0 1b 15 0f 1c 9c ec 60 ac e2 8b 51 04 56 27 42 b7 1f 25 d1 32 16 ea 8d d2 c8 69 08 82 bd 02 ee 8b 3a 00 01 eb 30 82 01 e7 30 82 01 52 a0 03 02 01 02 02 04 46 26 1d 27 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 30 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 4c 53 20 74 65 73 74 20 43 41 30 1e 17 0d 30 37 30 34 31 38 31 33 32 39 31 31 5a 17 0d 30 38 30 34 31 37 31 33 32 39 31 31 5a 30 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 4c 53 20 74 65 73 74 20 43 41 30 81 9c 30 0b 06 09 2a 86 48 86 f7 0d 01 01 01 03 81 8c 00 30 81 88 02 81 80 be ec 98 7a 1d 6f 7e 6b 25 9e e8 20 78 42 a0 64 05 66 43 99 6d 49 d5 18 ec 7d b9 58 64 b2 80 a3 14 61 9d 0a 4f be 2f f0 2e fc d2 ab 5c 36 df 53 ec 43 c7 fc de 91 bc 1e 01 a6 b7 6c b2 07 10 2e cb 61 47 75 ca 03 ce 23 6e 38 f1 34 27 1a 1a cd f7 96 f3 b3 f0 0d 67 7f ca 77 84 3f 9c 29 f4 62 91 f6 12 5b 62 5a cc ba ed 08 2e 32 44 26 ac fd 23 ce 53 1b bb f2 87 fe dc 78 93 7c 59 bf a1 75 02 03 01 00 01 a3 43 30 41 30 0f 06 03 55 1d 13 01 01 ff 04 05 30 03 01 01 ff 30 0f 06 03 55 1d 0f 01 01 ff 04 05 03 03 07 04 00 30 1d 06 03 55 1d 0e 04 16 04 14 e9 3c 1c fb ad 92 6e e6 06 a4 56 2c a2 e1 c0 53 27 c8 f2 95 30 0b 06 09 2a 86 48 86 f7 0d 01 01 05 03 81 81 00 89 a2 11 a8 67 e9 d6 33 e9 35 e5 61 00 12 ba d1 25 34 28 80 32 9e 3b ae ee 41 ea e6 97 94 81 89 fc 25 df 73 37 31 31 04 e1 29 d5 53 a2 a4 6b 1f e8 6e ba a1 00 21 0c 5a 76 a3 cc e4 cf b6 47 ef 5c d1 e0 71 16 2a 85 fa 9f 91 26 9f a0 ef 70 41 ff f6 90 21 9c 6c 4d 1c 90 28 4b b7 33 4c ab ff 24 36 49 86 4a 87 c7 2a c4 d5 fb 8b b2 0e 50 bf 6e 43 4f 0e fe 3d fa 94 a4 88 73 e4 16 e6 ec 9e write to 0x81c56a0 [0x81d4ef0] (1111 bytes => 1111 (0x457)) 0000 - 16 03 01 04 52 0b 00 04-4e 00 04 4b 00 02 5a 30 ....R...N..K..Z0 0010 - 82 02 56 30 82 01 c1 a0-03 02 01 02 02 04 46 26 ..V0..........F& 0020 - 1d 31 30 0b 06 09 2a 86-48 86 f7 0d 01 01 05 30 .10...*.H......0 0030 - 19 31 17 30 15 06 03 55-04 03 13 0e 47 6e 75 54 .1.0...U....GnuT 0040 - 4c 53 20 74 65 73 74 20-43 41 30 1e 17 0d 30 37 LS test CA0...07 0050 - 30 34 31 38 31 33 32 39-32 31 5a 17 0d 30 38 30 0418132921Z..080 0060 - 34 31 37 31 33 32 39 32-31 5a 30 37 31 1b 30 19 417132921Z071.0. 0070 - 06 03 55 04 0a 13 12 47-6e 75 54 4c 53 20 74 65 ..U....GnuTLS te 0080 - 73 74 20 73 65 72 76 65-72 31 18 30 16 06 03 55 st server1.0...U 0090 - 04 03 13 0f 74 65 73 74-2e 67 6e 75 74 6c 73 2e ....test.gnutls. 00a0 - 6f 72 67 30 81 9c 30 0b-06 09 2a 86 48 86 f7 0d org0..0...*.H... 00b0 - 01 01 01 03 81 8c 00 30-81 88 02 81 80 d7 ba 5c .......0.......\ 00c0 - af a3 0c f0 2e a9 27 56-aa 53 8e a8 eb 7f 81 75 ......'V.S.....u 00d0 - 4c 6b 98 be 4a ea b7 1e-f8 4b c3 6a c4 da 0d 00 Lk..J....K.j.... 00e0 - b8 ea 4c 13 1f 36 16 93-de 72 ef c6 a4 5e b2 6e ..L..6...r...^.n 00f0 - b6 ca 0a 88 55 75 90 96-ed a6 57 bc 0c 3b 76 0d ....Uu....W..;v. 0100 - 97 1e bd e9 ec 7f d3 a9-ec fb 85 64 a0 6b a0 48 ...........d.k.H 0110 - ce 77 7e 73 9c 31 13 ff-3d c8 ae a5 60 6e d9 b6 .w~s.1..=...`n.. 0120 - 8c 5a 9a 6f b6 be 9f 6a-bd a7 f0 a0 33 27 f5 b7 .Z.o...j....3'.. 0130 - 1d 92 e5 96 9c 73 52 d6-9f d6 c8 8e b1 02 03 01 .....sR......... 0140 - 00 01 a3 81 93 30 81 90-30 0c 06 03 55 1d 13 01 .....0..0...U... 0150 - 01 ff 04 02 30 00 30 1a-06 03 55 1d 11 04 13 30 ....0.0...U....0 0160 - 11 82 0f 74 65 73 74 2e-67 6e 75 74 6c 73 2e 6f ...test.gnutls.o 0170 - 72 67 30 13 06 03 55 1d-25 04 0c 30 0a 06 08 2b rg0...U.%..0...+ 0180 - 06 01 05 05 07 03 01 30-0f 06 03 55 1d 0f 01 01 .......0...U.... 0190 - ff 04 05 03 03 07 a0 00-30 1d 06 03 55 1d 0e 04 ........0...U... 01a0 - 16 04 14 eb c7 45 6e e5-f8 25 ca 8c 8d 83 0d 74 .....En..%.....t 01b0 - e9 86 d4 dd 55 b4 75 30-1f 06 03 55 1d 23 04 18 ....U.u0...U.#.. 01c0 - 30 16 80 14 e9 3c 1c fb-ad 92 6e e6 06 a4 56 2c 0....<....n...V, 01d0 - a2 e1 c0 53 27 c8 f2 95-30 0b 06 09 2a 86 48 86 ...S'...0...*.H. 01e0 - f7 0d 01 01 05 03 81 81-00 68 51 0f 4e df bb 6f .........hQ.N..o 01f0 - 3b c1 b8 e7 fb f9 09 9e-41 c9 f6 f6 44 fa 06 cc ;.......A...D... 0200 - a1 d5 11 c9 5d ff 0a 4e-4e 50 45 fc 29 ea 88 1b ....]..NNPE.)... 0210 - a7 de 09 41 67 0d 43 f4-bb 60 31 47 82 50 f5 03 ...Ag.C..`1G.P.. 0220 - 05 0d 05 15 f0 77 7a e2-52 c3 27 b3 18 1e 48 3c .....wz.R.'...H< 0230 - 58 05 f2 58 6c 32 de a2-13 41 b2 a6 8f 0c 96 fb X..Xl2...A...... 0240 - 5d a8 a5 59 b3 10 29 f0-1b 15 0f 1c 9c ec 60 ac ]..Y..).......`. 0250 - e2 8b 51 04 56 27 42 b7-1f 25 d1 32 16 ea 8d d2 ..Q.V'B..%.2.... 0260 - c8 69 08 82 bd 02 ee 8b-3a 00 01 eb 30 82 01 e7 .i......:...0... 0270 - 30 82 01 52 a0 03 02 01-02 02 04 46 26 1d 27 30 0..R.......F&.'0 0280 - 0b 06 09 2a 86 48 86 f7-0d 01 01 05 30 19 31 17 ...*.H......0.1. 0290 - 30 15 06 03 55 04 03 13-0e 47 6e 75 54 4c 53 20 0...U....GnuTLS 02a0 - 74 65 73 74 20 43 41 30-1e 17 0d 30 37 30 34 31 test CA0...07041 02b0 - 38 31 33 32 39 31 31 5a-17 0d 30 38 30 34 31 37 8132911Z..080417 02c0 - 31 33 32 39 31 31 5a 30-19 31 17 30 15 06 03 55 132911Z0.1.0...U 02d0 - 04 03 13 0e 47 6e 75 54-4c 53 20 74 65 73 74 20 ....GnuTLS test 02e0 - 43 41 30 81 9c 30 0b 06-09 2a 86 48 86 f7 0d 01 CA0..0...*.H.... 02f0 - 01 01 03 81 8c 00 30 81-88 02 81 80 be ec 98 7a ......0........z 0300 - 1d 6f 7e 6b 25 9e e8 20-78 42 a0 64 05 66 43 99 .o~k%.. xB.d.fC. 0310 - 6d 49 d5 18 ec 7d b9 58-64 b2 80 a3 14 61 9d 0a mI...}.Xd....a.. 0320 - 4f be 2f f0 2e fc d2 ab-5c 36 df 53 ec 43 c7 fc O./.....\6.S.C.. 0330 - de 91 bc 1e 01 a6 b7 6c-b2 07 10 2e cb 61 47 75 .......l.....aGu 0340 - ca 03 ce 23 6e 38 f1 34-27 1a 1a cd f7 96 f3 b3 ...#n8.4'....... 0350 - f0 0d 67 7f ca 77 84 3f-9c 29 f4 62 91 f6 12 5b ..g..w.?.).b...[ 0360 - 62 5a cc ba ed 08 2e 32-44 26 ac fd 23 ce 53 1b bZ.....2D&..#.S. 0370 - bb f2 87 fe dc 78 93 7c-59 bf a1 75 02 03 01 00 .....x.|Y..u.... 0380 - 01 a3 43 30 41 30 0f 06-03 55 1d 13 01 01 ff 04 ..C0A0...U...... 0390 - 05 30 03 01 01 ff 30 0f-06 03 55 1d 0f 01 01 ff .0....0...U..... 03a0 - 04 05 03 03 07 04 00 30-1d 06 03 55 1d 0e 04 16 .......0...U.... 03b0 - 04 14 e9 3c 1c fb ad 92-6e e6 06 a4 56 2c a2 e1 ...<....n...V,.. 03c0 - c0 53 27 c8 f2 95 30 0b-06 09 2a 86 48 86 f7 0d .S'...0...*.H... 03d0 - 01 01 05 03 81 81 00 89-a2 11 a8 67 e9 d6 33 e9 ...........g..3. 03e0 - 35 e5 61 00 12 ba d1 25-34 28 80 32 9e 3b ae ee 5.a....%4(.2.;.. 03f0 - 41 ea e6 97 94 81 89 fc-25 df 73 37 31 31 04 e1 A.......%.s711.. 0400 - 29 d5 53 a2 a4 6b 1f e8-6e ba a1 00 21 0c 5a 76 ).S..k..n...!.Zv 0410 - a3 cc e4 cf b6 47 ef 5c-d1 e0 71 16 2a 85 fa 9f .....G.\..q.*... 0420 - 91 26 9f a0 ef 70 41 ff-f6 90 21 9c 6c 4d 1c 90 .&...pA...!.lM.. 0430 - 28 4b b7 33 4c ab ff 24-36 49 86 4a 87 c7 2a c4 (K.3L..$6I.J..*. 0440 - d5 fb 8b b2 0e 50 bf 6e-43 4f 0e fe 3d fa 94 a4 .....P.nCO..=... 0450 - 88 73 e4 16 e6 ec 9e .s..... >>> TLS 1.0 Handshake [length 002b], CertificateRequest 0d 00 00 23 03 01 02 40 00 1d 00 1b 30 19 31 17 30 15 06 03 55 04 03 13 0e 47 6e 75 54 4c 53 20 74 65 73 74 20 43 41 0e 00 00 00 write to 0x81c56a0 [0x81d4ef0] (48 bytes => 48 (0x30)) 0000 - 16 03 01 00 2b 0d 00 00-23 03 01 02 40 00 1d 00 ....+...#... at ... 0010 - 1b 30 19 31 17 30 15 06-03 55 04 03 13 0e 47 6e .0.1.0...U....Gn 0020 - 75 54 4c 53 20 74 65 73-74 20 43 41 0e uTLS test CA. 0030 - read from 0x81c56a0 [0x81cad28] (5 bytes => 5 (0x5)) 0000 - 16 03 01 00 07 ..... read from 0x81c56a0 [0x81cad2d] (7 bytes => 7 (0x7)) 0000 - 0b 00 00 03 .... 0007 - <<< TLS 1.0 Handshake [length 0007], Certificate 0b 00 00 03 00 00 00 read from 0x81c56a0 [0x81cad28] (5 bytes => 5 (0x5)) 0000 - 16 03 01 00 86 ..... read from 0x81c56a0 [0x81cad2d] (134 bytes => 134 (0x86)) 0000 - 10 00 00 82 00 80 a6 13-63 71 e6 e0 8e 4d 32 4f ........cq...M2O 0010 - ce f0 37 75 3a aa 80 af-b1 35 8e 79 ba f3 14 1b ..7u:....5.y.... 0020 - a3 77 7b d1 4e 1c 7c 96-4c 19 0a 57 f9 44 43 7a .w{.N.|.L..W.DCz 0030 - 7d a2 a8 63 5b 5a 22 e7-46 6b 6b 9c 3e bb 9f 96 }..c[Z".Fkk.>... 0040 - 71 92 32 43 b8 c3 1f 79-54 25 3b 9e 29 83 8d bc q.2C...yT%;.)... 0050 - 9f 07 8e 62 ba 5f d2 bb-83 bf 9d 65 b2 5d 81 bb ...b._.....e.].. 0060 - 2c 46 51 ee 7f 1d da 3c-b4 bc f9 72 fd 02 fd 0f ,FQ....<...r.... 0070 - 3b 2f b2 3a 36 12 42 ba-77 05 2e 32 b7 4f f9 d3 ;/.:6.B.w..2.O.. 0080 - ef 05 b4 24 6e 95 ...$n. <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange 10 00 00 82 00 80 a6 13 63 71 e6 e0 8e 4d 32 4f ce f0 37 75 3a aa 80 af b1 35 8e 79 ba f3 14 1b a3 77 7b d1 4e 1c 7c 96 4c 19 0a 57 f9 44 43 7a 7d a2 a8 63 5b 5a 22 e7 46 6b 6b 9c 3e bb 9f 96 71 92 32 43 b8 c3 1f 79 54 25 3b 9e 29 83 8d bc 9f 07 8e 62 ba 5f d2 bb 83 bf 9d 65 b2 5d 81 bb 2c 46 51 ee 7f 1d da 3c b4 bc f9 72 fd 02 fd 0f 3b 2f b2 3a 36 12 42 ba 77 05 2e 32 b7 4f f9 d3 ef 05 b4 24 6e 95 read from 0x81c56a0 [0x81cad28] (5 bytes => 5 (0x5)) 0000 - 14 03 01 00 01 ..... read from 0x81c56a0 [0x81cad2d] (1 bytes => 1 (0x1)) 0000 - 01 . <<< TLS 1.0 ChangeCipherSpec [length 0001] 01 read from 0x81c56a0 [0x81cad28] (5 bytes => 5 (0x5)) 0000 - 16 03 01 00 30 ....0 read from 0x81c56a0 [0x81cad2d] (48 bytes => 48 (0x30)) 0000 - de 25 c7 3d 3b db f4 f2-58 c5 d4 de b2 06 5c c4 .%.=;...X.....\. 0010 - ce b6 ec cf 38 c6 73 e2-fa 85 ea fb 6b ee 9d 40 ....8.s.....k..@ 0020 - f5 15 b4 da f5 43 fa ca-28 3d 45 c2 dd a3 77 4e .....C..(=E...wN <<< TLS 1.0 Handshake [length 0010], Finished 14 00 00 0c f7 db c2 09 fd 03 0d 27 79 e2 33 40 >>> TLS 1.0 ChangeCipherSpec [length 0001] 01 write to 0x81c56a0 [0x81d4ef0] (6 bytes => 6 (0x6)) 0000 - 14 03 01 00 01 01 ...... >>> TLS 1.0 Handshake [length 0010], Finished 14 00 00 0c 79 a0 30 f7 30 70 8b 5c f3 ca c3 e6 write to 0x81c56a0 [0x81d4ef0] (53 bytes => 53 (0x35)) 0000 - 16 03 01 00 30 2f e5 11-51 bd 0e d2 27 bc 65 bb ....0/..Q...'.e. 0010 - 13 2f a3 9a b5 a2 8c e5-c7 e2 c7 77 99 d8 46 f6 ./.........w..F. 0020 - 80 89 ac f4 a2 67 f6 9f-97 3b e0 ff 3b 93 25 d4 .....g...;..;.%. 0030 - d0 a9 ac c5 88 ..... -----BEGIN SSL SESSION PARAMETERS----- MHUCAQECAgMBBAIANQQgF9U/70BCJTnhN19Ff2IRWlWoOJ8VAOnL1hBGv2Ftd68E MG8bKoF3TF1ynHAWGcytcmhbVh2eDUcT5Zb4r5UBdazPlfojMQhHlmxFAK2ECpR+ 26EGAgRHfogJogQCAgEspAYEBAEAAAA= -----END SSL SESSION PARAMETERS----- Shared ciphers:AES256-SHA:AES128-SHA:RC4-SHA:DES-CBC3-SHA CIPHER is AES256-SHA From mh+gnutls-devel at zugschlus.de Fri Jan 4 21:16:36 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Fri, 4 Jan 2008 21:16:36 +0100 Subject: Interoperability issue with The Bat (Debian Bug #316522) In-Reply-To: <871w8xpey2.fsf@mocca.josefsson.org> References: <20080103002458.GA14155@torres.zugschlus.de> <87abnlpknv.fsf@mocca.josefsson.org> <871w8xpey2.fsf@mocca.josefsson.org> Message-ID: <20080104201636.GC600@torres.zugschlus.de> On Fri, Jan 04, 2008 at 08:29:25PM +0100, Simon Josefsson wrote: > However, if I start gnutls-serv with --disable-client-cert I get the > debug log [2] which is a successful TLS handshake! Interesting. > Even though the TLS handshake is successful TheBat doesn't send the > e-mail though, and I don't know why, it may be because it expects CRLF > and I only sent LF. gnutls-serv is an echo server and will echo everything the client says back to the client. You cannot type on a gnutls-serv's stdin and expect it to sent what you type back to the client. Been there, fallen into this particular pit as well. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mh+gnutls-devel at zugschlus.de Fri Jan 4 21:18:36 2008 From: mh+gnutls-devel at zugschlus.de (Marc Haber) Date: Fri, 4 Jan 2008 21:18:36 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87wsqpnzur.fsf@mocca.josefsson.org> References: <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> <87ejcxpkpt.fsf@mocca.josefsson.org> <20080104180736.GB4550@downhill.g.la> <87wsqpnzur.fsf@mocca.josefsson.org> Message-ID: <20080104201836.GD600@torres.zugschlus.de> On Fri, Jan 04, 2008 at 08:40:44PM +0100, Simon Josefsson wrote: > Interesting, 235/8=29.375 bytes. The minimum randomness needed per TLS > session would be 28 bytes for client hello random_bytes plus 46 bytes > for the PreMasterSecret (if RSA is used for key exchange). If openssl > is using /dev/urandom, I think it is overly optimistic about the quality > of that data. I suspect that it only uses data from /dev/u?random to seed its own PRNG. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 From mrsam at courier-mta.com Sat Jan 5 01:28:51 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 04 Jan 2008 19:28:51 -0500 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE References: <87wsqppm4v.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc > systems. Does anyone know of other systems that needs these defines to > work properly? > > I'm inclined to remove the lines from configure.in. If some other > system needs this to have working standard C/POSIX functions, we could > solve it via a gnulib module, I suppose. You don't even need to do that at all. If someone needs these symbols, they can simply set CPPFLAGS before running configure (the -D flags belong in CPPFLAGS, rather than CFLAGS, in any case). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From simon at josefsson.org Sat Jan 5 10:58:53 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 05 Jan 2008 10:58:53 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: (Sam Varshavchik's message of "Fri, 04 Jan 2008 19:28:51 -0500") References: <87wsqppm4v.fsf@mocca.josefsson.org> Message-ID: <878x34oaoy.fsf@mocca.josefsson.org> Sam Varshavchik writes: > Simon Josefsson writes: > >> My conclusion is that -D_REENTRANT -D_THREAD_SAFE is not needed on glibc >> systems. Does anyone know of other systems that needs these defines to >> work properly? >> >> I'm inclined to remove the lines from configure.in. If some other >> system needs this to have working standard C/POSIX functions, we could >> solve it via a gnulib module, I suppose. > > You don't even need to do that at all. If someone needs these symbols, > they can simply set CPPFLAGS before running configure (the -D flags > belong in CPPFLAGS, rather than CFLAGS, in any case). I have removed them. Let's see if someone complains about it. /Simon From ametzler at downhill.at.eu.org Sat Jan 5 13:09:38 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 5 Jan 2008 13:09:38 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87wsqpnzur.fsf@mocca.josefsson.org> References: <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> <87ejcxpkpt.fsf@mocca.josefsson.org> <20080104180736.GB4550@downhill.g.la> <87wsqpnzur.fsf@mocca.josefsson.org> Message-ID: <20080105120938.GA4579@downhill.g.la> On 2008-01-04 Simon Josefsson wrote: > Andreas Metzler writes: [...] >> testing with a exim linked against OpenSSL I get *slightly* less >> entropy usage (235 vs 289 bits in the first testrun) when connecting >> with swaks (perl/OpenSSL). > For my curiosity, what are those numbers if you run gnutls with a > NORMAL:%COMPAT priority? Sorry, I have no go these numbers a hand, since exim is not using gnutls_priority_init() yet. > Cipher padding needs one byte of randomness > for every encrypted packet, disabling padding may thus reduce the > randomness needed further. This assumes you actually sent some data > back and forward, I don't whether you did. [...] I just sent QUIT over the encrypted channel. 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 ametzler at downhill.at.eu.org Sat Jan 5 14:08:06 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 5 Jan 2008 14:08:06 +0100 Subject: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104170649.GA4550@downhill.g.la> References: <20080104113847.GJ22955@kiste.smurf.noris.de> <20080104122116.GK22955@kiste.smurf.noris.de> <87k5mpbwfl.fsf@mocca.josefsson.org> <87ve694trp.fsf@wheatstone.g10code.de> <87prwhr6xz.fsf@mocca.josefsson.org> <87fxxd37ze.fsf@wheatstone.g10code.de> <871w8xr2u4.fsf@mocca.josefsson.org> <20080104170649.GA4550@downhill.g.la> Message-ID: <20080105130806.GB4579@downhill.g.la> On 2008-01-04 Andreas Metzler wrote: [...] > Well, the basic patch for testing seems to be this one, basically > identical to the skeleton you described. I gets down entropy-usage > for a single STARTTLS to <300 bits from > 3000. [...] > Error checking, and having the file in spool_directory instead (since > it is a private directoy present on any exim installation) is missing. Updated version submitted to http://bugs.exim.org/show_bug.cgi?id=654 cu andreas From guus at debian.org Sat Jan 5 14:17:25 2008 From: guus at debian.org (Guus Sliepen) Date: Sat, 5 Jan 2008 14:17:25 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104094848.GB4528@downhill.g.la> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> Message-ID: <20080105131725.GK3717@sliepen.org> On Fri, Jan 04, 2008 at 10:48:48AM +0100, Andreas Metzler wrote: > When acting as a server gnutls pulls that much data from /dev/urandom > that entropy available for /dev/random is down to its minimum > safeguard. ((it is not possible to completely deplete /dev/random by > reading from /dev/urandom in current kernels) > > ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && gnutls-serv --x > 509keyfile /tmp/CERT/exim.key --x509certfile /tmp/CERT/exim.crt & sleep 1 && ca > t /proc/sys/kernel/random/entropy_avail > [1] 5356 > 3591 > Echo Server ready. Listening to port '5556'. > 139 > > > ametzler at argenau:~$ cat /proc/sys/kernel/random/entropy_avail && openssl s_serve > r -cert /tmp/CERT/exim.crt -key /tmp/CERT/exim.key -accept 5556 & sleep 1 && cat /proc/sys/kernel/random/entropy_avail > [1] 7139 > 3596 > [...] > 3361 Just FYI: I used strace on openssl s_server -nocert and gnutls-serv, and I noticed the following: "openssl s_server" reads 32 bytes from /dev/urandom "gnutls-serv" reads 3000 times 120 bytes from /dev/urandom, yes, 360 kilobytes! It is no wonder that when strong random data is required later on, the entropy pool is completely empty with gnutls-serv. For example, if I just start "gnutls-serv -g", it will always block while trying to read 300 bytes from an empty /dev/random in order to generate temporary RSA parameters. I also noticed that on my machine, /proc/sys/kernel/random/entropy_avail never exceeds 3600, so by reading 300 bytes, you're using 2/3 of a full pool. -- Met vriendelijke groet / with kind regards, Guus Sliepen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From nmav at gnutls.org Sun Jan 6 14:56:51 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 6 Jan 2008 15:56:51 +0200 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: <87wsqppm4v.fsf@mocca.josefsson.org> References: <87wsqppm4v.fsf@mocca.josefsson.org> Message-ID: <200801061556.51625.nmav@gnutls.org> On Friday 04 January 2008, Simon Josefsson wrote: > For a long time configure.in has contained: > > dnl In order to use the reentrant libc functions. > dnl I hope it is portable enough. > CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE" I believe these flags are used in solaris. Probably older systems require them too. regards, Nikos From simon at josefsson.org Sun Jan 6 15:17:05 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 06 Jan 2008 15:17:05 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: <200801061556.51625.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 6 Jan 2008 15:56:51 +0200") References: <87wsqppm4v.fsf@mocca.josefsson.org> <200801061556.51625.nmav@gnutls.org> Message-ID: <87ejcv2g4e.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Friday 04 January 2008, Simon Josefsson wrote: >> For a long time configure.in has contained: >> >> dnl In order to use the reentrant libc functions. >> dnl I hope it is portable enough. >> CFLAGS="${CFLAGS} -D_REENTRANT -D_THREAD_SAFE" > > I believe these flags are used in solaris. Probably older systems > require them too. But does it have any effect for any functions we actually use? libgnutls* uses very few POSIX/C89 functions that have thread-issues, the only one I could find was that we use gmtime_r. I checked on a solaris 5.10 machine, and the _REENTRANT symbol enables prototypes for some functions like getlogin_r, ttyname_r, rand_r, and actually also gmtime_r. However, the gmtime_r prototype, and most other prototypes, are also always declared if !_STRICT_STDC: #if defined(__EXTENSIONS__) || \ (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \ (_POSIX_C_SOURCE - 0 >= 199506L) || defined(_REENTRANT) extern struct tm *gmtime_r(const time_t *_RESTRICT_KYWD, struct tm *_RESTRICT_KYWD); So I think we are safe. To make sure, I'll build the latest daily snapshot and build it on this machine now.. /Simon From simon at josefsson.org Sun Jan 6 16:06:15 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 06 Jan 2008 16:06:15 +0100 Subject: Disabling LZO by default? And removing minilzo copy. Message-ID: <871w8v2dug.fsf@mocca.josefsson.org> I know this has been discussed before, but would anyone object if we disable LZO compression for the next stable series (e.g., in the current devel branch)? I think the simplest would be to let the gnutls code for lzo compression stay around, but you would have to install liblzo manually (and worry about the license issue [1]), and also specify --with-lzo explicitly, in order to use it. Thoughts? If there is no response in a week or so I'll do it. /Simon [1] the liblzo author has promised an updated GPLv3 compatible release From simon at josefsson.org Sun Jan 6 17:05:08 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 06 Jan 2008 17:05:08 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: <87ejcv2g4e.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Sun, 06 Jan 2008 15:17:05 +0100") References: <87wsqppm4v.fsf@mocca.josefsson.org> <200801061556.51625.nmav@gnutls.org> <87ejcv2g4e.fsf@mocca.josefsson.org> Message-ID: <87prwf0wjv.fsf@mocca.josefsson.org> Simon Josefsson writes: > So I think we are safe. To make sure, I'll build the latest daily > snapshot and build it on this machine now.. I built both 2.2.0 and 2.3.0 snapshot without problem. There were no differences in config.h due to this change. There was, however, a problem with HUGE_VAL: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c cfg/shared.c: In function `store_single_arg': cfg/shared.c:727: error: wrong type argument to unary plus cfg/shared.c:727: error: wrong type argument to unary minus The line reads: if (double_val == +HUGE_VAL || double_val == -HUGE_VAL) It seems HUGE_VAL expands (gcc -E) into __builtin_huge_val, but I can't find its definition. It is probably a symbol defined in some library. Replacing HUGE_VAL with HUGE worked, but I'm not sure if that is a good idea... /Simon From mrsam at courier-mta.com Sun Jan 6 17:34:45 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Sun, 06 Jan 2008 11:34:45 -0500 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE References: <87wsqppm4v.fsf@mocca.josefsson.org> <200801061556.51625.nmav@gnutls.org> <87ejcv2g4e.fsf@mocca.josefsson.org> <87prwf0wjv.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > It seems HUGE_VAL expands (gcc -E) into __builtin_huge_val, but I can't > find its definition. It is probably a symbol defined in some library. The __builtin symbols are recognized directly by gcc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fweimer at bfk.de Mon Jan 7 12:50:49 2008 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 07 Jan 2008 12:50:49 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: <87prwf0wjv.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Sun, 06 Jan 2008 17:05:08 +0100") References: <87wsqppm4v.fsf@mocca.josefsson.org> <200801061556.51625.nmav@gnutls.org> <87ejcv2g4e.fsf@mocca.josefsson.org> <87prwf0wjv.fsf@mocca.josefsson.org> Message-ID: <82tzlp7t2e.fsf@mid.bfk.de> * Simon Josefsson: > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c > cfg/shared.c: In function `store_single_arg': > cfg/shared.c:727: error: wrong type argument to unary plus > cfg/shared.c:727: error: wrong type argument to unary minus > > The line reads: > > if (double_val == +HUGE_VAL || double_val == -HUGE_VAL) Looks like a GCC bug to me. I can't reproduce this with: gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mark.phillips at virgin.net Mon Jan 7 15:11:59 2008 From: mark.phillips at virgin.net (mark.phillips at virgin.net) Date: Mon, 7 Jan 2008 14:11:59 +0000 (UTC) Subject: [PATCH] Server name indication encoding fails if multiple server names are given Message-ID: <5389660.1199715119911.JavaMail.?@fh1007.dia.cp.net> The code in lib/ext_server_name.c _gnutls_server_name_send_params() fails when more than one server name is specified (via the gnutls_server_name_set API).The loop in _gnutls_server_name_send_params uses a hardcoded index of "0" (instead of "i") to retrieve the server name which is copied into the ClientHello message, this means that the second server name will be incorrect.The fix is trivial - simply change the [0] to [i] in the following line:- memcpy (p, session->security_parameters.extensions. server_names[0].name, len);This is line 199 of the latest version of the file - http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/ext_server_name.c;hb=0b7c039057a03d3259b296808114adcc2c492f62I have also attached a patch file.CheersMark Phillips -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-multiple-server-names.patch Type: application/octet-stream Size: 469 bytes Desc: not available URL: From simon at josefsson.org Mon Jan 7 22:12:13 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Jan 2008 22:12:13 +0100 Subject: On dropping -D_REENTRANT -D_THREAD_SAFE In-Reply-To: <82tzlp7t2e.fsf@mid.bfk.de> (Florian Weimer's message of "Mon, 07 Jan 2008 12:50:49 +0100") References: <87wsqppm4v.fsf@mocca.josefsson.org> <200801061556.51625.nmav@gnutls.org> <87ejcv2g4e.fsf@mocca.josefsson.org> <87prwf0wjv.fsf@mocca.josefsson.org> <82tzlp7t2e.fsf@mid.bfk.de> Message-ID: <87r6gtl4r6.fsf@mocca.josefsson.org> Florian Weimer writes: > * Simon Josefsson: > >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c >> cfg/shared.c: In function `store_single_arg': >> cfg/shared.c:727: error: wrong type argument to unary plus >> cfg/shared.c:727: error: wrong type argument to unary minus >> >> The line reads: >> >> if (double_val == +HUGE_VAL || double_val == -HUGE_VAL) > > Looks like a GCC bug to me. I can't reproduce this with: > > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I suspect doesn't have enough administrative TLC to have properly installed tools. So unless someone else reports the same issue, let's ignore it. FWIW, I had difficulties using the generated binaries on the machine because they sucked up too much entropy from /dev/random. Sigh. /Simon From simon at josefsson.org Mon Jan 7 22:15:53 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 07 Jan 2008 22:15:53 +0100 Subject: [PATCH] Server name indication encoding fails if multiple server names are given In-Reply-To: <5389660.1199715119911.JavaMail.?@fh1007.dia.cp.net> (mark's message of "Mon, 7 Jan 2008 14:11:59 +0000 (UTC)") References: <5389660.1199715119911.JavaMail.?@fh1007.dia.cp.net> Message-ID: <87myrhl4l2.fsf@mocca.josefsson.org> "mark.phillips at virgin.net" writes: > The code in lib/ext_server_name.c _gnutls_server_name_send_params() fails when > more than one server name is specified (via the gnutls_server_name_set API). > > The loop in _gnutls_server_name_send_params uses a hardcoded index of "0" > (instead of "i") to retrieve the server name which is copied into the > ClientHello message, this means that the second server name will be incorrect. > > The fix is trivial - simply change the [0] to [i] in the following line:- > memcpy (p, > session->security_parameters.extensions. > server_names[0].name, len); > > This is line 199 of the latest version of the file - http:// > git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/ext_server_name.c;hb= > 0b7c039057a03d3259b296808114adcc2c492f62 Many thanks for a good bug report and suggested patch. I have installed the patch. /Simon > diff -u lib/ext_server_name.c.orig lib/ext_server_name.c > --- lib/ext_server_name.c.orig 2008-01-07 14:09:56.574035900 +0000 > +++ lib/ext_server_name.c 2008-01-07 14:10:20.106942500 +0000 > @@ -196,7 +196,7 @@ > > memcpy (p, > session->security_parameters.extensions. > - server_names[0].name, len); > + server_names[i].name, len); > p += len; > break; > default: > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From wk at gnupg.org Tue Jan 8 10:20:46 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 10:20:46 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080104153343.GF31039@thunk.cs.uwaterloo.ca> (Ian Goldberg's message of "Fri, 4 Jan 2008 10:33:43 -0500") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <20080104153343.GF31039@thunk.cs.uwaterloo.ca> Message-ID: <871w8s65ch.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 16:33, linux at paip.net said: > plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which > initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with > custom allocation functions), you can easily cause a crash. At least we have a way to test whether libgcrypt is intialized (modulo threading issues). > It would be very nice to have all of the libgcrypt global state > encapsulated into a dynamically allocated region that's returned by the > libgcrypt initialization, and passed into all other functions. [Macros Right, however that means a complete API break. It is also a sign that such deep linking hierarchies are not very well thought-out. We need to live with it, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Tue Jan 8 10:49:50 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jan 2008 10:49:50 +0100 Subject: GnuTLS 2.3.0 Message-ID: <87sl18ejep.fsf@mocca.josefsson.org> The GnuTLS 2.3.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. News in this release: * Version 2.3.0 (released 2008-01-08) ** LZO compression is now disabled by default. The reason is that LZO compression is not standardized in TLS. If you wish to experiment with it, you will have to supply --with-lzo when invoking ./configure. The internal copy of minilzo is no longer included with GnuTLS, so you will need to install liblzo or liblzo2 on your system to have --with-lzo to be effective. ** More than one server name field is now sent to the server properly. Thanks to mark.phillips at virgin.net. ** Fixes the post_client_hello_function(). The extensions are now parsed in a callback friendly way. ** Fix for certificate selection in servers with certificate callbacks. ** Updated translations. ** Update gnulib files. ** API and ABI modifications: No changes since last version. The goals for the 2.3.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.4 More ideas are welcome, just create a new ticket. Here are the compressed sources: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.3.0.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.3.0.tar.bz2 Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. /Simon From wk at gnupg.org Tue Jan 8 10:50:05 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 10:50:05 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <8763y9r35b.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Fri, 04 Jan 2008 17:01:20 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <87k5mp385s.fsf@wheatstone.g10code.de> <8763y9r35b.fsf@mocca.josefsson.org> Message-ID: <87wsqk4pf6.fsf@wheatstone.g10code.de> On Fri, 4 Jan 2008 17:01, simon at josefsson.org said: > Right. So what should applications like exim do exactly? Is there My suggestion is: int main () { int rc; #ifdef WE_USE_PTHREADS rc = gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); if (rc) error (EXIT_FAILURE, 0, "can't register Pthreads with Libgcrypt: %s\n", gpg_strerror (rc)); #endif #ifndef WE_NEED_SECMEM gcry_control (GCRYCTL_DISABLE_SECMEM, 0); #endif if (!gcry_check_version (NEED_LIBGCRYPT_VERSION) ) error (EXIT_FAILURE, 0, "%s is too old (need %s, have %s)\n"), "libgcrypt", NEED_LIBGCRYPT_VERSION, gcry_check_version (NULL) ); rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE, "foo/random-seed"); if (rc) error (0, 0, "Warning: Error reading seed file: %s", gpg_strerror (rc)); #ifdef WE_NEED_SECMEM gcry_control (GCRYCTL_INIT_SECMEM, 32768, 0); #endif gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); DoIT(); /* initialize gnutls, runs the MTA.. */ rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE); if (rc) error (0, 0, "Warning: Updating seed file failed: %s", gpg_strerror (rc)); return 0; } If you don't want to track libgcrypt dependencies just use if (!gcry_check_version (NULL) ) error (EXIT_FAILURE, 0, "problem intializing Libgcrypt version %s"), gcry_check_version (NULL) ); This is a sufficient initialization. GNUTLS may later still check the version. GNUTLS or any other library may use if (!gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P)) missing_libgcrypt_initialization (); to check whether libgcrypt has already been initialized. Nikos and me came up with that scheme some years ago. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Jan 8 10:53:50 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 10:53:50 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080105131725.GK3717@sliepen.org> (Guus Sliepen's message of "Sat, 5 Jan 2008 14:17:25 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> Message-ID: <87sl184p8x.fsf@wheatstone.g10code.de> On Sat, 5 Jan 2008 14:17, guus at debian.org said: > "gnutls-serv" reads 3000 times 120 bytes from /dev/urandom, yes, 360 kilobytes! Run gcry_control (GCRYCTL_DUMP_RANDOM_STATS); to get statistics about libgcrypt's RNG. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Tue Jan 8 11:03:21 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jan 2008 11:03:21 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87sl184p8x.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 08 Jan 2008 10:53:50 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> Message-ID: <878x30ab2u.fsf@mocca.josefsson.org> Werner Koch writes: > On Sat, 5 Jan 2008 14:17, guus at debian.org said: > >> "gnutls-serv" reads 3000 times 120 bytes from /dev/urandom, yes, 360 kilobytes! > > Run > > gcry_control (GCRYCTL_DUMP_RANDOM_STATS); > > to get statistics about libgcrypt's RNG. How should I interpret the following output? random usage: poolsize=600 mixed=621 polls=3000/117 added=3588/370308 outmix=3 getlvl1=3/136 getlvl2=0/0 This is from a typical usage of gnutls-cli against a SMTP server negotiating STARTTLS and then shutting down the connection. /Simon From simon at josefsson.org Tue Jan 8 11:12:24 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jan 2008 11:12:24 +0100 Subject: GnuTLS 2.3.0 In-Reply-To: <87sl18ejep.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 08 Jan 2008 10:49:50 +0100") References: <87sl18ejep.fsf@mocca.josefsson.org> Message-ID: <87abngpqwn.fsf@mocca.josefsson.org> Simon Josefsson writes: > * Version 2.3.0 (released 2008-01-08) I just noticed the ABI version on this was lower than the 2.2.0 release (27/0/1 compared to 27/1/1), so make sure your applications picks up the 2.3.0 release if that is what you want. Tomorrow's daily snapshot should fix this: http://daily.josefsson.org/gnutls/ /Simon From wk at gnupg.org Tue Jan 8 11:59:29 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 11:59:29 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <878x30ab2u.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 08 Jan 2008 11:03:21 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> Message-ID: <87bq7w4m7i.fsf@wheatstone.g10code.de> On Tue, 8 Jan 2008 11:03, simon at josefsson.org said: > random usage: poolsize=600 mixed=621 polls=3000/117 added=3588/370308 > outmix=3 getlvl1=3/136 getlvl2=0/0 - The random pool has been mixed 621 times. - The slow random poll function has been called 3000 times to fill and update the random poll. Under Linux each call reads 120 bytes from /dev/urandom. - The fast random poll function has been called 117 times. Under Linux this adds just a few bytes from timer ticks and resource statistics. - There have been 3588 calls to the function adding random to the pool with a total of 370308 bytes added. - The intermediate pool to extrac random has been moxed 3 times. - The RNG has been asked 3 times to return a total of 136 bytes of random. Lets try with gpg using libgcrypt 1.4.1-svn1277: $ gpg2 --gen-random -a --debug 128 1 136 random usage: poolsize=600 mixed=4 polls=0/2 added=17/812 outmix=3 getlvl1=2/136 getlvl2=0/0 $ rm ~/.gnupg/random_seed $ gpg2 --gen-random -a --debug 128 1 136 random usage: poolsize=600 mixed=603 polls=3000/2 added=3012/360184 outmix=3 getlvl1=2/136 getlvl2=0/0 This clearly shows that the missing random_seed is the culprit. (The 117 fast polls in gnutls-cli are due to the use of other crypto functions which issue calls to the fast polls.) Anyway there 3000 calls to /dev/urandom are far too many for an initial pool filling. I need to check this. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Tue Jan 8 12:39:02 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 12:39:02 +0100 Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87bq7w4m7i.fsf@wheatstone.g10code.de> (Werner Koch's message of "Tue, 08 Jan 2008 11:59:29 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> <87bq7w4m7i.fsf@wheatstone.g10code.de> Message-ID: <87zlvg35t5.fsf_-_@wheatstone.g10code.de> On Tue, 8 Jan 2008 11:59, wk at gnupg.org said: > Anyway there 3000 calls to /dev/urandom are far too many for an initial > pool filling. I need to check this. Found it. The bug was introduced with libgcrypt 1.3.1. Here is a patch: 2008-01-08 Werner Koch * random.c (add_randomness): Do not just increment POOL_FILLED_COUNTER but update it by the actual amount of data. Index: cipher/random.c =================================================================== --- cipher/random.c (revision 1277) +++ cipher/random.c (working copy) @@ -1115,6 +1115,7 @@ add_randomness (const void *buffer, size_t length, enum random_origins origin) { const unsigned char *p = buffer; + size_t count = 0; assert (pool_is_locked); @@ -1123,6 +1124,7 @@ while (length-- ) { rndpool[pool_writepos++] ^= *p++; + count++; if (pool_writepos >= POOLSIZE ) { /* It is possible that we are invoked before the pool is @@ -1132,7 +1134,9 @@ separately. See also the remarks about the seed file. */ if (origin >= RANDOM_ORIGIN_SLOWPOLL && !pool_filled) { - if (++pool_filled_counter >= POOLSIZE) + pool_filled_counter += count; + count = 0; + if (pool_filled_counter >= POOLSIZE) pool_filled = 1; } pool_writepos = 0; Also commited to SVN. Old and new stats: $ LD_PRELOAD=/usr/local/lib/libgcrypt.so ./benchmark --verbose random random 130ms 30ms random usage: poolsize=600 mixed=972 polls=3000/200 added=4200/378400 outmix=200 getlvl1=200/13600 getlvl2=0/0 $ ./benchmark --verbose random random 40ms 30ms random usage: poolsize=600 mixed=377 polls=25/200 added=1225/21400 outmix=200 getlvl1=200/13600 getlvl2=0/0 Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Tue Jan 8 13:00:05 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jan 2008 13:00:05 +0100 Subject: GnuTLS 2.3.0 In-Reply-To: <87sl18ejep.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 08 Jan 2008 10:49:50 +0100") References: <87sl18ejep.fsf@mocca.josefsson.org> Message-ID: <87zlvgo7cq.fsf@mocca.josefsson.org> Simon Josefsson writes: > Here are the compressed sources: > ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.3.0.tar.bz2 > http://josefsson.org/gnutls/releases/gnutls-2.3.0.tar.bz2 In case you are wondering where the *.sig file is on the HTTP server, it is missing pending resolution of: https://savannah.gnu.org/support/index.php?106141 Get it from the FTP server meanwhile. /Simon From simon at josefsson.org Tue Jan 8 17:16:02 2008 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 08 Jan 2008 17:16:02 +0100 Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87zlvg35t5.fsf_-_@wheatstone.g10code.de> (Werner Koch's message of "Tue, 08 Jan 2008 12:39:02 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> <87bq7w4m7i.fsf@wheatstone.g10code.de> <87zlvg35t5.fsf_-_@wheatstone.g10code.de> Message-ID: <87myrgnvi5.fsf@mocca.josefsson.org> Werner Koch writes: > On Tue, 8 Jan 2008 11:59, wk at gnupg.org said: > >> Anyway there 3000 calls to /dev/urandom are far too many for an initial >> pool filling. I need to check this. > > Found it. The bug was introduced with libgcrypt 1.3.1. Here is a patch: Thanks. Running gnutls-cli using libgcrypt SVN leads to: random usage: poolsize=600 mixed=25 polls=25/113 added=593/12956 outmix=3 getlvl1=3/136 getlvl2=0/0 Compared to the old situation: random usage: poolsize=600 mixed=621 polls=3000/117 added=3588/370308 outmix=3 getlvl1=3/136 getlvl2=0/0 So we have reduced /dev/urandom consumption from 3000*120=360kb to 25*120=3kb, right? Strace also confirms the latter amount. That's good. Still, 3kb per TLS connection is excessive, so I still recommend exim to set a libgcrypt seeds file to solve the problem. Thanks, /Simon From wk at gnupg.org Tue Jan 8 19:13:52 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2008 19:13:52 +0100 Subject: [patch] Re: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87myrgnvi5.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 08 Jan 2008 17:16:02 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> <87bq7w4m7i.fsf@wheatstone.g10code.de> <87zlvg35t5.fsf_-_@wheatstone.g10code.de> <87myrgnvi5.fsf@mocca.josefsson.org> Message-ID: <87bq7wyylb.fsf@wheatstone.g10code.de> On Tue, 8 Jan 2008 17:16, simon at josefsson.org said: > Still, 3kb per TLS connection is excessive, so I still recommend exim to > set a libgcrypt seeds file to solve the problem. Yes, definitely. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From nmav at gnutls.org Tue Jan 8 20:19:15 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Jan 2008 21:19:15 +0200 Subject: Interoperability issue with The Bat (Debian Bug #316522) In-Reply-To: <871w8xpey2.fsf@mocca.josefsson.org> References: <20080103002458.GA14155@torres.zugschlus.de> <87abnlpknv.fsf@mocca.josefsson.org> <871w8xpey2.fsf@mocca.josefsson.org> Message-ID: <200801082119.15795.nmav@gnutls.org> On Friday 04 January 2008, Simon Josefsson wrote: > Simon Josefsson writes: > >> It might be possible (judging from > >> https://www.ritlabs.com/bt/view.php?id=5785) that The Bat by default > >> refuses to talk TLS to a server presenting a self-signed certificate. > > > > I also note that it is possible to download trial versions of TheBat. > > If we can get a recipe to reproduce the problem using it, that would > > help a lot. > TheBat works under Wine, so I downloaded it and debugged this... FWIW, I > can reproduce the problem: > 2008-01-04 19:03:02 TLS error on connection from xxx.bredband.comhem.se > (mocca.local) [x.y.z.q] (gnutls_handshake): An error was encountered at the > TLS Finished packet calculation. > Using gnutls-serv, I get the connection debug log [1] below. TheBat > complains that the CA is untrusted, and I have to click continue. Then > it fails with the TLS Finished packet calculation error. Could you try with different protocol/algorithm combinations? I think the output of connection with gnutls using SSL 3.0 and arcfour might be useful too. > However, if I start gnutls-serv with --disable-client-cert I get the > debug log [2] which is a successful TLS handshake! An idea might be that it doesn't insert the certificate request message to the handshake hash. Openssl has several compatibility options enabled by default and this might be one, but I am not sure, I only speculate! regards, Nikos From nmav at gnutls.org Tue Jan 8 20:22:44 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 8 Jan 2008 21:22:44 +0200 Subject: opencdk under LGPL In-Reply-To: <878x3oiilx.fsf@mocca.josefsson.org> References: <200712202119.08436.nmav@gnutls.org> <878x3oiilx.fsf@mocca.josefsson.org> Message-ID: <200801082122.44940.nmav@gnutls.org> On Friday 21 December 2007, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > Thanks to Timo Schulz and Free Software Foundation some parts of the > > opencdk library are now available under LGPL. I used those parts to > > create a gnutls library with openpgp support (in the main LGPL library). > > You can check the gnutls_2_2_x_with_opencdk branch if you want to test > > it. > > > > In this version only the included LGPL opencdk library is used. > > Interesting! How will this interact with upstream opencdk releases? > Will upstream opencdk be re-licensed to LGPL? I have splitted the files in the opencdk distribution in a way that we can copy directly the LGPL ones only. This is what I've done in the lgpl branch. I don't know how good idea would be to drop the dependency on opencdk completely and use the included LGPL files only. regards, Nikos From marcus.brinkmann at ruhr-uni-bochum.de Wed Jan 9 12:22:32 2008 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: Wed, 09 Jan 2008 12:22:32 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <871w8s65ch.fsf@wheatstone.g10code.de> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <20080104153343.GF31039@thunk.cs.uwaterloo.ca> <871w8s65ch.fsf@wheatstone.g10code.de> Message-ID: <87fxx79rbb.wl%marcus.brinkmann@ruhr-uni-bochum.de> At Tue, 08 Jan 2008 10:20:46 +0100, 'Werner Koch' wrote: > > On Fri, 4 Jan 2008 16:33, linux at paip.net said: > > > plugin for pidgin: if another plugin (say, Jabber) uses gnutls, which > > initializes libgcrypt, and OTR also initializes libgcrypt (perhaps with > > custom allocation functions), you can easily cause a crash. > > At least we have a way to test whether libgcrypt is intialized (modulo > threading issues). I think I also implemented it so that thread initialization can happen multiple times, without conflicts, if the same thread package is used everytime (otherwise you get an error). It's a long time ago, though, I may misremember something or it may have changed. But there are other initialization issues which may not be so forgiving (random pool, etc). I don't know. Thanks, Marcus From simon at josefsson.org Mon Jan 14 15:57:12 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Jan 2008 15:57:12 +0100 Subject: opencdk under LGPL In-Reply-To: <200801082122.44940.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Tue, 8 Jan 2008 21:22:44 +0200") References: <200712202119.08436.nmav@gnutls.org> <878x3oiilx.fsf@mocca.josefsson.org> <200801082122.44940.nmav@gnutls.org> Message-ID: <87zlv8xxo7.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Friday 21 December 2007, Simon Josefsson wrote: >> Nikos Mavrogiannopoulos writes: >> > Thanks to Timo Schulz and Free Software Foundation some parts of the >> > opencdk library are now available under LGPL. I used those parts to >> > create a gnutls library with openpgp support (in the main LGPL library). >> > You can check the gnutls_2_2_x_with_opencdk branch if you want to test >> > it. >> > >> > In this version only the included LGPL opencdk library is used. >> >> Interesting! How will this interact with upstream opencdk releases? >> Will upstream opencdk be re-licensed to LGPL? > > I have splitted the files in the opencdk distribution in a way that we can > copy directly the LGPL ones only. This is what I've done in the lgpl branch. > I don't know how good idea would be to drop the dependency on opencdk > completely and use the included LGPL files only. I think it would be better to have a libgnutls-openpgp (under LGPL) for the OpenPGP stuff, for at least two reasons: size and API compatibility. This would make it easier to do further work on the OpenPGP stuff without breaking API/ABI for the core library. What do you think? As for opencdk, I'm not sure... as far as I know, very few (if any) applications except gnutls uses opencdk. But having it available as a separate library is good in case someone wants to use it. It also helps to make sure gnutls and the lgpl-opencdk library are well separated, and that we only use public APIs etc. /Simon From nmav at gnutls.org Mon Jan 14 17:23:03 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Jan 2008 18:23:03 +0200 Subject: opencdk under LGPL In-Reply-To: <87zlv8xxo7.fsf@mocca.josefsson.org> References: <200712202119.08436.nmav@gnutls.org> <878x3oiilx.fsf@mocca.josefsson.org> <200801082122.44940.nmav@gnutls.org> <87zlv8xxo7.fsf@mocca.josefsson.org> Message-ID: On Jan 14, 2008 4:57 PM, Simon Josefsson wrote: > > I have splitted the files in the opencdk distribution in a way that we can > > copy directly the LGPL ones only. This is what I've done in the lgpl branch. > > I don't know how good idea would be to drop the dependency on opencdk > > completely and use the included LGPL files only. > > I think it would be better to have a libgnutls-openpgp (under LGPL) for > the OpenPGP stuff, for at least two reasons: size and API compatibility. > This would make it easier to do further work on the OpenPGP stuff > without breaking API/ABI for the core library. What do you think? No I don't think the idea into splitting into sublibraries is a good idea. It causes more problems than it solves. All features can be compiled out if necessary, thus it should cause a space problem. About compatibility, it doesn't cause any except for the changes I did to the functions. All applications linked to gnutls-extra will continue to work with openpgp in the main library! > As for opencdk, I'm not sure... as far as I know, very few (if any) > applications except gnutls uses opencdk. But having it available as a > separate library is good in case someone wants to use it. It also helps > to make sure gnutls and the lgpl-opencdk library are well separated, and > that we only use public APIs etc. Currently, there is no LGPL only version of opencdk, that's why it is included in the main gnutls library (no symbols exported). Once an lgpl version is available we can link on it! regards, Nikos From simon at josefsson.org Mon Jan 14 17:33:47 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Jan 2008 17:33:47 +0100 Subject: opencdk under LGPL In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 14 Jan 2008 18:23:03 +0200") References: <200712202119.08436.nmav@gnutls.org> <878x3oiilx.fsf@mocca.josefsson.org> <200801082122.44940.nmav@gnutls.org> <87zlv8xxo7.fsf@mocca.josefsson.org> Message-ID: <87hchgxt78.fsf@mocca.josefsson.org> "Nikos Mavrogiannopoulos" writes: > On Jan 14, 2008 4:57 PM, Simon Josefsson wrote: > >> > I have splitted the files in the opencdk distribution in a way that we can >> > copy directly the LGPL ones only. This is what I've done in the lgpl branch. >> > I don't know how good idea would be to drop the dependency on opencdk >> > completely and use the included LGPL files only. >> >> I think it would be better to have a libgnutls-openpgp (under LGPL) for >> the OpenPGP stuff, for at least two reasons: size and API compatibility. >> This would make it easier to do further work on the OpenPGP stuff >> without breaking API/ABI for the core library. What do you think? > > No I don't think the idea into splitting into sublibraries is a good > idea. It causes more > problems than it solves. All features can be compiled out if > necessary, thus it should > cause a space problem. About compatibility, it doesn't cause any except for the > changes I did to the functions. All applications linked to > gnutls-extra will continue > to work with openpgp in the main library! Ok. But any future API changes in the openpgp code will cause a libgnutls.so version bump, and every one of those causes a lot of work for packagers. The new modification to gnutls_openpgp_privkey_sign_hash will cause another API/ABI break for the core library, which is really bad. Putting the openpgp stuff in a libgnutls-openpgp can make it possible to only cause these problems for the people who are using the openpgp stuff. Right now all gnutls users suffer from ABI breaks even though they don't use those features. Or do you think the openpgp API is now stable enough, so that we should never break it again in a reasonable time (e.g., 5 years)? Can't we revert the gnutls_openpgp_privkey_sign_hash change, and introduce a new gnutls_openpgp_privkey_sign_hash2 instead? That will avoid breaking the ABI again for the 2.4 release, which I think would be a good thing. >> As for opencdk, I'm not sure... as far as I know, very few (if any) >> applications except gnutls uses opencdk. But having it available as a >> separate library is good in case someone wants to use it. It also helps >> to make sure gnutls and the lgpl-opencdk library are well separated, and >> that we only use public APIs etc. > > Currently, there is no LGPL only version of opencdk, that's why it is > included in the > main gnutls library (no symbols exported). Once an lgpl version is > available we can link > on it! Yes, let's do it that way. If a LGPL opencdk ever materialize, we can use it, otherwise we use our internal mini-opencdk version. /Simon From simon at josefsson.org Mon Jan 14 17:43:46 2008 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 14 Jan 2008 17:43:46 +0100 Subject: opencdk under LGPL In-Reply-To: <87hchgxt78.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 14 Jan 2008 17:33:47 +0100") References: <200712202119.08436.nmav@gnutls.org> <878x3oiilx.fsf@mocca.josefsson.org> <200801082122.44940.nmav@gnutls.org> <87zlv8xxo7.fsf@mocca.josefsson.org> <87hchgxt78.fsf@mocca.josefsson.org> Message-ID: <87abn8xsql.fsf@mocca.josefsson.org> Simon Josefsson writes: > Can't we revert the gnutls_openpgp_privkey_sign_hash change, and > introduce a new gnutls_openpgp_privkey_sign_hash2 instead? That will > avoid breaking the ABI again for the 2.4 release, which I think would be > a good thing. There seems to be another ABI diff between 2.2 and 2.3.x: int gnutls_openpgp_keyring_check_id (gnutls_openpgp_keyring_t ring, - const unsigned char keyid[8], + gnutls_openpgp_keyid_t keyid, unsigned int flags); Maybe there are more, it seems the gnutls_openpgp_keyid_t change isn't backwards compatible: make[4]: Entering directory `/home/jas/src/gnutls/guile/src' /bin/sh ../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../includes -I../../includes -I../.. -I. -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -Wno-strict-prototypes -I../../lgl -I../../lgl -g -O2 -Wno-pointer-sign -MT libguile_gnutls_extra_v_1_la-extra.lo -MD -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c -o libguile_gnutls_extra_v_1_la-extra.lo `test -f 'extra.c' || echo './'`extra.c gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../includes -I../../includes -I../.. -I. -g -Wall -Wcast-align -W -Wpointer-arith -Wchar-subscripts -Wformat-security -Wno-format-y2k -Wmissing-braces -Winline -Wstrict-prototypes -Wno-unused-parameter -pipe -Wno-strict-prototypes -I../../lgl -I../../lgl -g -O2 -Wno-pointer-sign -MT libguile_gnutls_extra_v_1_la-extra.lo -MD -MP -MF .deps/libguile_gnutls_extra_v_1_la-extra.Tpo -c extra.c -fPIC -DPIC -o .libs/libguile_gnutls_extra_v_1_la-extra.o In file included from extra.c:27: ../../includes/gnutls/openpgp.h:62: error: expected declaration specifiers or '...' before 'gnutls_certificate_print_formats_t' extra.c: In function 'scm_gnutls_openpgp_certificate_id': extra.c:169: warning: passing argument 2 of 'gnutls_openpgp_crt_get_key_id' from incompatible pointer type extra.c: In function 'scm_gnutls_openpgp_certificate_id_x': extra.c:201: warning: passing argument 2 of 'gnutls_openpgp_crt_get_key_id' from incompatible pointer type extra.c: In function 'scm_gnutls_openpgp_keyring_contains_key_id_p': extra.c:494: error: incompatible type for argument 2 of 'gnutls_openpgp_keyring_check_id' make[4]: *** [libguile_gnutls_extra_v_1_la-extra.lo] Error 1 /Simon From nmav at gnutls.org Mon Jan 14 20:23:43 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 14 Jan 2008 21:23:43 +0200 Subject: opencdk under LGPL In-Reply-To: <87abn8xsql.fsf@mocca.josefsson.org> References: <200712202119.08436.nmav@gnutls.org> <87hchgxt78.fsf@mocca.josefsson.org> <87abn8xsql.fsf@mocca.josefsson.org> Message-ID: <200801142123.43972.nmav@gnutls.org> On Monday 14 January 2008, Simon Josefsson wrote: > Simon Josefsson writes: > > Can't we revert the gnutls_openpgp_privkey_sign_hash change, and > > introduce a new gnutls_openpgp_privkey_sign_hash2 instead? That will > > avoid breaking the ABI again for the 2.4 release, which I think would be > > a good thing. Of course. However since this is in the development branch there is no problem yet. Let's wait until the openpgp changes are stabilized and then I'll check whether it is possible to maintain compatibility via compat.c. regards. Nikos From nmav at gnutls.org Wed Jan 16 18:06:15 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 16 Jan 2008 19:06:15 +0200 Subject: openpgp + subkeys Message-ID: <200801161906.15588.nmav@gnutls.org> I've been working a bit lately on the openpgp support of gnutls. The planned changes are: 1. To handle subkeys 2. To list/generate keyrings using certtool 3. To list openpgp certificates/keys using certtool The first is partially completed. However I've come across a limitation of the current protocol for openpgp keys (rfc5081). It seems currently there is no way to indicate to the peer which subkey to use, thus always the primary key has to be used. Moreover it states that the key has to be marked for authentication, but it seems there is no way to arbitrarily mark a public key with gpg (or I couldn't find it). For this reason now on the stable release we always use the primary key and ignore the flags of the public keys. On the development release I plan to implement a subkey negotiation -by sending a keyid at the initial hello messages to indicate the (sub)key that will be used during this handshake. I was also investigating to using the first subkey with authentication flag set, but it seems this approach is not that optimal. Other subkeys might be present and the selection of the first seems arbitrary. Thus I'm most in favour of the first solution. What do you think? Any other ideas or comments? regards, Nikos From simon at josefsson.org Thu Jan 17 11:21:20 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 17 Jan 2008 11:21:20 +0100 Subject: gnutls-2.2.0 - self link issue In-Reply-To: <9e0cf0bf0712211439qbd5811eq6b0f60a3b58c9453@mail.gmail.com> (Alon Bar-Lev's message of "Sat, 22 Dec 2007 00:39:29 +0200") References: <9e0cf0bf0712140949v6aaa23behea116d6d6b6c8dc0@mail.gmail.com> <87lk7t60ph.fsf@mocca.josefsson.org> <877ijcjqx8.fsf@mocca.josefsson.org> <9e0cf0bf0712211410j2fc0af44udfc294d94c1eb81b@mail.gmail.com> <87ejdfsmr9.fsf@mocca.josefsson.org> <9e0cf0bf0712211439qbd5811eq6b0f60a3b58c9453@mail.gmail.com> Message-ID: <877ii8eorj.fsf@mocca.josefsson.org> "Alon Bar-Lev" writes: > On 12/22/07, Simon Josefsson wrote: >> That's exactly what I needed, I can now reproduce the problem. It is >> late today and I'm leaving for the holidays early tomorrow, but I may be >> able to debug it on my laptop offline. > > Great! > >> Btw, is only libgnutls-extra.so affected for you? The programs appear >> to be linked properly here, even those that are linked with >> libgnutls-extra.so. I suspect the bug is in libextra/Makefile.am in how >> it interacts with libtool. > > No... openssl is also: > xxx/usr/local/lib/libgnutls-openssl.so: > linux-gate.so.1 => (0xb7fd8000) > libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7fa0000) > libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7f26000) > libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7f21000) > libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7ea8000) > libc.so.6 => /lib/libc.so.6 (0xb7d77000) > libz.so.1 => /lib/libz.so.1 (0xb7d63000) > /lib/ld-linux.so.2 (0x80000000) For 2.2.1, we have applied your patch. I'm trying to sort out this issue with libtool upstream, because I suspect your patch only hides some other problem. But meanwhile, I don't have any other solution, so decided to use your patch. Thanks, Simon From simon at josefsson.org Fri Jan 18 16:25:07 2008 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 18 Jan 2008 16:25:07 +0100 Subject: GnuTLS 2.2.1 Message-ID: <87wsq7xijw.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.2.1. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== * Version 2.2.1 (released 2008-01-17) ** Prevent linking libextra against previously installed libgnutls. Tiny patch from "Alon Bar-Lev" , see . ** Fixes the post_client_hello_function(). The extensions are now parsed in a callback friendly way. ** Fix for certificate selection in servers with certificate callbacks. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.8MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.1.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.2.1.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.2.1.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.2.1.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.2.1.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2008-06-30] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2008-06-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: cfc219dad028fd823be766d939dfcec73a408844 gnutls-2.2.1.tar.bz2 6a70a48e88ce47fe56abbae720da86fcfe4039c67fb6d826f42fb8f9 gnutls-2.2.1.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-devel mailing list, see: . Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer consists of libgpg-error 1.6, libgcrypt 1.4.0, libtasn1 1.2, opencdk 0.6.6, and GnuTLS 2.2.1. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.2.1.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.2.1.exe.sig The checksum values for SHA-1 and SHA-224 are: e0c4662c45cca62150f22cd3ce9ee13e0cb8671b gnutls-2.2.1.exe d91d151da3bf2564851bd28c9bcf6c37ec6f806345a6d3727525caa7 gnutls-2.2.1.exe Internationalization ==================== GnuTLS messages have been translated into Dutch, German, Malay, Polish and Swedish. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Sat Jan 19 14:18:43 2008 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 19 Jan 2008 14:18:43 +0100 Subject: opencdk under LGPL In-Reply-To: <200801142123.43972.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 14 Jan 2008 21:23:43 +0200") References: <200712202119.08436.nmav@gnutls.org> <87hchgxt78.fsf@mocca.josefsson.org> <87abn8xsql.fsf@mocca.josefsson.org> <200801142123.43972.nmav@gnutls.org> Message-ID: <87k5m6vtqk.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Monday 14 January 2008, Simon Josefsson wrote: >> Simon Josefsson writes: >> > Can't we revert the gnutls_openpgp_privkey_sign_hash change, and >> > introduce a new gnutls_openpgp_privkey_sign_hash2 instead? That will >> > avoid breaking the ABI again for the 2.4 release, which I think would be >> > a good thing. > > Of course. However since this is in the development branch there is no > problem yet. Let's wait until the openpgp changes are stabilized and > then I'll check whether it is possible to maintain compatibility via > compat.c. I think we should revert these changes in the trunk: gnutls_openpgp_privkey_sign_hash: MODIFIED to account for keyid gnutls_openpgp_keyring_check_id: MODIFIED to account for new keyid type gnutls_openpgp_crt_get_key_id: MODIFIED to account for new keyid type gnutls_openpgp_privkey_get_id: RENAMED to gnutls_openpgp_privkey_get_key_id gnutls_openpgp_keyid_t type difference If we do this, we can release a 2.3.1 with the new openpgp support libgnutls soon, which would be a good step forward. I think breaking backwards ABI compatibility within the development series is fine, so if we need to modify an API that was introduced in 2.3.x we can and should do so before 2.4.0 is released. I hope 2.4.0 will be ABI backwards compatible with 2.2.x. /Simon From ametzler at downhill.at.eu.org Sun Jan 20 18:10:51 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 20 Jan 2008 18:10:51 +0100 Subject: [patch] Uses too much entropy (Debian Bug #343085) In-Reply-To: <87bq7wyylb.fsf@wheatstone.g10code.de> References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> <87bq7w4m7i.fsf@wheatstone.g10code.de> <87zlvg35t5.fsf_-_@wheatstone.g10code.de> <87myrgnvi5.fsf@mocca.josefsson.org> <87bq7wyylb.fsf@wheatstone.g10code.de> Message-ID: <20080120171051.GC4576@downhill.g.la> On 2008-01-08 Werner Koch wrote: > On Tue, 8 Jan 2008 17:16, simon at josefsson.org said: > > Still, 3kb per TLS connection is excessive, so I still recommend exim to > > set a libgcrypt seeds file to solve the problem. > Yes, definitely. I gues it is not a god idea to share this seed file between multiple hosts accessing a central mailq queue. Is this this assumption correct? 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 wk at gnupg.org Mon Jan 21 13:07:01 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jan 2008 13:07:01 +0100 Subject: [patch] Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080120171051.GC4576@downhill.g.la> (Andreas Metzler's message of "Sun, 20 Jan 2008 18:10:51 +0100") References: <20080103003214.GB14155@torres.zugschlus.de> <20080104094848.GB4528@downhill.g.la> <20080105131725.GK3717@sliepen.org> <87sl184p8x.fsf@wheatstone.g10code.de> <878x30ab2u.fsf@mocca.josefsson.org> <87bq7w4m7i.fsf@wheatstone.g10code.de> <87zlvg35t5.fsf_-_@wheatstone.g10code.de> <87myrgnvi5.fsf@mocca.josefsson.org> <87bq7wyylb.fsf@wheatstone.g10code.de> <20080120171051.GC4576@downhill.g.la> Message-ID: <878x2j9yca.fsf@wheatstone.g10code.de> On Sun, 20 Jan 2008 18:10, ametzler at downhill.at.eu.org said: > I gues it is not a god idea to share this seed file between multiple > hosts accessing a central mailq queue. Is this this assumption correct? Yes. You better avoid that if possible. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From nmav at gnutls.org Thu Jan 24 08:06:26 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 24 Jan 2008 09:06:26 +0200 Subject: mod_gnutls 0.5.0-alpha Message-ID: <200801240906.26799.nmav@gnutls.org> Hello, I've released today mod_gnutls 0.5.0-alpha. This release adds initial support for OpenPGP certificate authentication (RFC 5081) and is available for testing. You can find more information on this release at: http://www.outoforder.cc/projects/apache/mod_gnutls/ regards, Nikos From simon at josefsson.org Thu Jan 24 21:46:28 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Jan 2008 21:46:28 +0100 Subject: GnuTLS and RFC2712? In-Reply-To: <1201194473.9688.4.camel@ket.lat> (Jack Bates's message of "Thu, 24 Jan 2008 09:07:53 -0800") References: <1201116315.6639.19.camel@ket.lat> <87myqvlb84.fsf@mocca.josefsson.org> <1201194473.9688.4.camel@ket.lat> Message-ID: <87r6g7dk9n.fsf@mocca.josefsson.org> All, Jack and I discussed adding Kerberos ciphers to GnuTLS, using Shishi. Most likely the implementation would be in libgnutls-extra, since Shishi is GPLv3. I think starting with RFC 2712 may be useful, to see that we understand it, and then proceed implementing some experimental protocol. Are others interested in this? Btw, Nikos, do you know if there is any license problem to use GPLv3 code with mod_gnutls? As far as I understand, GPLv3 is compatible with the Apache license, even though GPLv2 was not compatible. But I may have missed some point. /Simon Jack Bates writes: > Awesome, thanks for your response Simon! I sympathize with your struggle > to find time, and share your enthusiasm for Kerberos in TLS. I'm excited > to help however I can. Best wishes, Jack > > On Thu, 2008-01-24 at 12:22 +0100, Simon Josefsson wrote: >> Jack Bates writes: >> >> > Hello Simon, I use your awesome Shishi Kerberos implementation and we >> > have previously corresponded a bit. >> > >> > Please excuse this novice question, but I'm quite interested in using >> > Shishi with GnuTLS to negotiate TLS connections with Kerberos tickets, >> > instead of X.509 certificates, OpenPGP keys or SRP passwords. For >> > instance, I'd like to establish a secure connection with Apache >> > mod_gnutls and Shishi Kerberos tickets. >> > >> > I gather this is the subject of RFC2712? Can you comment on support for >> > RFC2712 in GnuTLS? >> >> Hi Jack! Thanks for your interest. Unfortunately, RFC 2712 is rather >> broken, firstly it does not offer mutual authentication via Kerberos (no >> AP-REP), and secondly it does not support modern ciphers (like AES). >> >> I do have plans to implement Kerberos over TLS, either using RFC 2712 or >> using a new idea based on the PSK ciphersuites -- I would add a new TLS >> extension to send the Kerberos AP-REQ and AP-REP, and then the PSK >> ciphersuite would use the derived encryption key as the pre-shared key. >> >> Once GnuTLS supports it, adding support for it in mod_gnutls shouldn't >> be too hard. >> >> However, to start this, I need help from someone like you who actually >> have a need to do this, to test early versions of the software and to >> provide feedback on what works good and what works less good. I recall >> someone asking for Kerberos support in GnuTLS earlier, it was on the >> Debian BTS, but I cannot find it now, and they never responded when I >> got back to them later on. I also need to allocate some spare time for >> the project, which may be tricky, so I can't promise to finish this very >> soon. But I very much like to do this, since it ties together two of my >> projects in a neat way. >> >> Btw, there are efforts in the IETF to replace RFC 2712 with something >> better, and Microsoft currently has a proposal do add support for >> GSS-API inside TLS. However, it hasn't been adopted, and some people >> seems to dislike the proposal for various reasons. I think supporting >> GSS-API in TLS will be complex, so a simpler update of RFC 2712 that >> uses Kerberos directly, without GSS-API, may have some merit. >> >> /Simon >> >> From nmav at gnutls.org Thu Jan 24 22:05:47 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 24 Jan 2008 23:05:47 +0200 Subject: GnuTLS and RFC2712? In-Reply-To: <87r6g7dk9n.fsf@mocca.josefsson.org> References: <1201116315.6639.19.camel@ket.lat> <1201194473.9688.4.camel@ket.lat> <87r6g7dk9n.fsf@mocca.josefsson.org> Message-ID: <200801242305.47938.nmav@gnutls.org> On Thursday 24 January 2008, Simon Josefsson wrote: > Btw, Nikos, do you know if there is any license problem to use GPLv3 > code with mod_gnutls? As far as I understand, GPLv3 is compatible with > the Apache license, even though GPLv2 was not compatible. But I may > have missed some point. No, I already make use of gnutls-extra in mod_gnutls (in 0.5.0-alpha). regards, Nikos From simon at josefsson.org Thu Jan 24 22:10:14 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 24 Jan 2008 22:10:14 +0100 Subject: GnuTLS and RFC2712? In-Reply-To: <200801242305.47938.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 24 Jan 2008 23:05:47 +0200") References: <1201116315.6639.19.camel@ket.lat> <1201194473.9688.4.camel@ket.lat> <87r6g7dk9n.fsf@mocca.josefsson.org> <200801242305.47938.nmav@gnutls.org> Message-ID: <87ir1jdj61.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Thursday 24 January 2008, Simon Josefsson wrote: > >> Btw, Nikos, do you know if there is any license problem to use GPLv3 >> code with mod_gnutls? As far as I understand, GPLv3 is compatible with >> the Apache license, even though GPLv2 was not compatible. But I may >> have missed some point. > > No, I already make use of gnutls-extra in mod_gnutls (in 0.5.0-alpha). Ok, great. I considered to put this in a libgnutls-shishi, to avoid pulling in Shishi into applications that use libgnutls-extra. But that would slow down building GnuTLS even more, so I'm not sure it is worth it. /Simon From nmav at gnutls.org Thu Jan 24 22:27:15 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 24 Jan 2008 23:27:15 +0200 Subject: GnuTLS and RFC2712? In-Reply-To: <87ir1jdj61.fsf@mocca.josefsson.org> References: <1201116315.6639.19.camel@ket.lat> <200801242305.47938.nmav@gnutls.org> <87ir1jdj61.fsf@mocca.josefsson.org> Message-ID: <200801242327.15374.nmav@gnutls.org> On Thursday 24 January 2008, Simon Josefsson wrote: > Nikos Mavrogiannopoulos writes: > > On Thursday 24 January 2008, Simon Josefsson wrote: > >> Btw, Nikos, do you know if there is any license problem to use GPLv3 > >> code with mod_gnutls? As far as I understand, GPLv3 is compatible with > >> the Apache license, even though GPLv2 was not compatible. But I may > >> have missed some point. > > No, I already make use of gnutls-extra in mod_gnutls (in 0.5.0-alpha). > Ok, great. I considered to put this in a libgnutls-shishi, to avoid > pulling in Shishi into applications that use libgnutls-extra. But that > would slow down building GnuTLS even more, so I'm not sure it is worth > it. I think the extra lib is a perfect place for it. regards, Nikos From mrsam at courier-mta.com Fri Jan 25 00:30:10 2008 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 24 Jan 2008 18:30:10 -0500 Subject: GnuTLS and RFC2712? References: <1201116315.6639.19.camel@ket.lat> <1201194473.9688.4.camel@ket.lat> <87r6g7dk9n.fsf@mocca.josefsson.org> <200801242305.47938.nmav@gnutls.org> <87ir1jdj61.fsf@mocca.josefsson.org> Message-ID: Simon Josefsson writes: > Nikos Mavrogiannopoulos writes: > >> On Thursday 24 January 2008, Simon Josefsson wrote: >> >>> Btw, Nikos, do you know if there is any license problem to use GPLv3 >>> code with mod_gnutls? As far as I understand, GPLv3 is compatible with >>> the Apache license, even though GPLv2 was not compatible. But I may >>> have missed some point. >> >> No, I already make use of gnutls-extra in mod_gnutls (in 0.5.0-alpha). > > Ok, great. I considered to put this in a libgnutls-shishi, to avoid > pulling in Shishi into applications that use libgnutls-extra. But that > would slow down building GnuTLS even more, so I'm not sure it is worth > it. I can tell you that putting this into a separate libgnutls-shishi will make it much easier for distributions to package GnuTLS. Requiring shishi as a mandatory prerequisite for libgnutls-extra will have one of three results: 1) Distributions will avoid updating to the newer version of GnuTLS, for some period of time. 2) Distributions will patch it out themselves, and factor out the shishi-dependent bits into a separate module, and a separate subpackage. 3) Distributions will always package GnuTLS with shishi support turned off via configure, (or a configure patch). Option #3 will be the likely option for distributions that do not include shishi at all, making it harder for people who want it, to actually use it (forcing them to rebuild GnuTLS for their distribution). Option #2 will actually encourage distributions that do not presently include shishi to add it, and build GnuTLS with shishi support that users get by selecting the appropriate subpackage. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nmav at gnutls.org Fri Jan 25 08:44:45 2008 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 25 Jan 2008 09:44:45 +0200 Subject: GnuTLS and RFC2712? In-Reply-To: References: <1201116315.6639.19.camel@ket.lat> <1201194473.9688.4.camel@ket.lat> <87r6g7dk9n.fsf@mocca.josefsson.org> <200801242305.47938.nmav@gnutls.org> <87ir1jdj61.fsf@mocca.josefsson.org> Message-ID: > I can tell you that putting this into a separate libgnutls-shishi will make > it much easier for distributions to package GnuTLS. Requiring shishi as a > mandatory prerequisite for libgnutls-extra will have one of three results: > 3) Distributions will always package GnuTLS with shishi support turned off > via configure, (or a configure patch). Why someone wouldn't want to include the shishi support? I can understand these arguments for SRP which is turned off by some distributions due to previous patent threats, but I don't think there is something like it around shishi. If a module system is implemented it should not be only for shishi, but it should affect all gnutls auth methods and algorithms. For the moment, since this support doesn't exist formally, using the gnutls-extra is the appropriate way to add kerberos. (actually implementing a module system is not hard given how code is organized, but it requires time I don't have). regards, Nikos From rra at stanford.edu Fri Jan 25 02:21:51 2008 From: rra at stanford.edu (Russ Allbery) Date: Thu, 24 Jan 2008 17:21:51 -0800 Subject: GnuTLS and RFC2712? In-Reply-To: <87r6g7dk9n.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu\, 24 Jan 2008 21\:46\:28 +0100") References: <1201116315.6639.19.camel@ket.lat> <87myqvlb84.fsf@mocca.josefsson.org> <1201194473.9688.4.camel@ket.lat> <87r6g7dk9n.fsf@mocca.josefsson.org> Message-ID: <87bq7aitsg.fsf@windlord.stanford.edu> Simon Josefsson writes: > Btw, Nikos, do you know if there is any license problem to use GPLv3 > code with mod_gnutls? As far as I understand, GPLv3 is compatible with > the Apache license, even though GPLv2 was not compatible. But I may > have missed some point. I believe GPLv3 is compatible with the Apache 2.0 license. The resulting combined work must be distributed under the GPLv3 with the additional restriction clause exercised, as permitted by the GPLv3. The relevant additional restriction added to the license of the combined work is the Apache 2.0 patent provision. This response is based on an answer by RMS to a similar question on another mailing list. -- Russ Allbery (rra at stanford.edu) From thresh at altlinux.ru Mon Jan 28 18:20:03 2008 From: thresh at altlinux.ru (Pavlov Konstantin) Date: Mon, 28 Jan 2008 20:20:03 +0300 Subject: gnutls with pkcs Message-ID: <20080128172003.GG27218@cryo.net.ru> Hello, what's the current status of PKCS support in GnuTLS? 1.7 branch (http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=shortlog;h=gnutls_1_7_14_with_pkcs11) seems being abandoned. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From alon.barlev at gmail.com Mon Jan 28 19:27:07 2008 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Mon, 28 Jan 2008 20:27:07 +0200 Subject: gnutls with pkcs In-Reply-To: <20080128172003.GG27218@cryo.net.ru> References: <20080128172003.GG27218@cryo.net.ru> Message-ID: <9e0cf0bf0801281027i5e53f551ucc4e828401304c79@mail.gmail.com> Hello, You can use: http://alon.barlev.googlepages.com/gnutls-pkcs11 Alon On Jan 28, 2008 7:20 PM, Pavlov Konstantin wrote: > Hello, what's the current status of PKCS support in GnuTLS? > > 1.7 branch > (http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=shortlog;h=gnutls_1_7_14_with_pkcs11) > seems being abandoned. > > -- > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFHng7DR0cP4/qrkIQRAodnAJsG0jlVUAGSJ9S+ODufVCb3GgkmxQCeKfaI > E37GXvXmTDQeNvpwEgfLekI= > =koCC > -----END PGP SIGNATURE----- > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From ametzler at downhill.at.eu.org Wed Jan 30 19:20:10 2008 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Wed, 30 Jan 2008 19:20:10 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <87wsqk4pf6.fsf@wheatstone.g10code.de> References: <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <87k5mp385s.fsf@wheatstone.g10code.de> <8763y9r35b.fsf@mocca.josefsson.org> <87wsqk4pf6.fsf@wheatstone.g10code.de> Message-ID: <20080130182010.GA5173@downhill.g.la> On 2008-01-08 Werner Koch wrote: > On Fri, 4 Jan 2008 17:01, simon at josefsson.org said: > > Right. So what should applications like exim do exactly? Is there > My suggestion is: [...] Hello, which yields this stripped down version for exim: ------------------------------ diff -urNad exim4-4.68~/build-tree/src/tls-gnu.c exim4-4.68/build-tree/src/tls-gnu.c --- exim4-4.68~/build-tree/src/tls-gnu.c 2007-08-30 14:31:06.000000000 +0000 +++ exim4-4.68/build-tree/src/tls-gnu.c 2008-01-27 18:42:00.000000000 +0000 @@ -20,6 +20,7 @@ #include #include +#include #define UNKNOWN_NAME "unknown" #define DH_BITS 1024 @@ -440,10 +441,32 @@ uschar *crl) { int rc; +uschar filename[200]; uschar *cert_expanded, *key_expanded, *cas_expanded, *crl_expanded; +gcry_error_t gcr_rc; initialized = (host == NULL)? INITIALIZED_SERVER : INITIALIZED_CLIENT; +/* Use a random_seed file for gcrypt's RNG */ +if (host_number_string != NULL) + { + if (!string_format(filename, sizeof(filename), "%s/random.seed%s", + spool_directory, host_number_string)) + return tls_error(US"overlong filename spool_directory/random.seedlocalhost_number", host, 0); + } +else + { + if (!string_format(filename, sizeof(filename), "%s/random.seed", + spool_directory)) + return tls_error(US"overlong filename spool_directory/random.seed", host, 0); + } + +gcr_rc = gcry_control (GCRYCTL_SET_RANDOM_SEED_FILE,filename); +if (gcr_rc) + return tls_error(US"Failure to set random_seed file", host, gcr_rc); + +gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); + rc = gnutls_global_init(); if (rc < 0) return tls_error(US"tls-init", host, rc); @@ -1303,8 +1326,19 @@ void tls_close(BOOL shutdown) { +gcry_error_t gcr_rc; + if (tls_active < 0) return; /* TLS was not active */ +gcr_rc = gcry_control (GCRYCTL_UPDATE_RANDOM_SEED_FILE); + +if (gcr_rc) + { + DEBUG(D_tls) debug_printf( + "GCRYCTL_UPDATE_RANDOM_SEED_FILE failed: (%d): (%s)\n", + gcr_rc,gcry_strerror(gcr_rc)); + } + if (shutdown) { DEBUG(D_tls) debug_printf("tls_close(): shutting down TLS\n"); ------------------------------ Any obvious breakage? Exim does not use any threading. I have not included an gcry_check_version(NULL) since I thought gcry_control() would fail as reliably as gcry_check_version() would, if gcrypt was not available. thanks, 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 wk at gnupg.org Thu Jan 31 09:26:07 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Jan 2008 09:26:07 +0100 Subject: Bug#448775: Uses too much entropy (Debian Bug #343085) In-Reply-To: <20080130182010.GA5173@downhill.g.la> (Andreas Metzler's message of "Wed, 30 Jan 2008 19:20:10 +0100") References: <20080104094848.GB4528@downhill.g.la> <87tzlt6ddp.fsf@wheatstone.g10code.de> <82wsqpg492.fsf@mid.bfk.de> <87fxxdbw59.fsf@mocca.josefsson.org> <87r6gx4sdf.fsf@wheatstone.g10code.de> <87tzltr7za.fsf@mocca.josefsson.org> <87k5mp385s.fsf@wheatstone.g10code.de> <8763y9r35b.fsf@mocca.josefsson.org> <87wsqk4pf6.fsf@wheatstone.g10code.de> <20080130182010.GA5173@downhill.g.la> Message-ID: <87fxwe4d0g.fsf@wheatstone.g10code.de> On Wed, 30 Jan 2008 19:20, ametzler at downhill.at.eu.org said: > Any obvious breakage? Exim does not use any threading. I have not > included an gcry_check_version(NULL) since I thought gcry_control() > would fail as reliably as gcry_check_version() would, if gcrypt was Better insert a gcry_check_version because this is the safe way to initialize gcrypt. The initialization is also done with most other gcry_control calls but that is a failsafe feature. Explicitly initialization is better (you don't need to check the return code, just call it.) Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Thu Jan 31 22:29:42 2008 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 31 Jan 2008 22:29:42 +0100 Subject: gnutls & TLS1.1 In-Reply-To: <8dba3c070801311316v6122e233h744f7edf1b0a1835@mail.gmail.com> References: <8dba3c070801311316v6122e233h744f7edf1b0a1835@mail.gmail.com> Message-ID: On 31 jan 2008, at 22.16, Matt Smith wrote: > Hello Mr. Josefsson, > I was wondering if you could assist me. > > I am looking for a packet capture of a TLS1.1 session being > established. > I attempted to use tcpdump on my local system while connecting with > your test server here: > https://test.gnutls.org:5556/ > > As the test page states, this connection was made using TLS1.0, so > that's not exactly what I need. You must use a client that supports TLS 1.1. The test server will negotiate TLS 1.1 if your client supports it. If you used a browser to access that page, chances are that your browser doesn't implement TLS 1.1. Try gnutls-cli from GnuTLS itself. > I also attempted to download and install gnutls-2.3.0.tar.bz2 , > however, the README for that file says that it only supports SSLv3 > and TLSv1.0 (although I suppose that the README has not yet been > updated if this is the newest version of mod_gnutls). Oops! I'll fix the README tomorrow, it is probably better if it doesn't say anything about version numbers at all. > You wouldn't happen to have a pcap of a TLSv1.1 session being > established, would you? > or, Am I correct in thinking that gnutls2.3.0 should indeed support > TLS1.1? > or, would it be possible to reconfigure the test server to only > accept TLS1.1 (drastic, and the least desirable option). The test server and gnutls2.3.0 supports TLSv1.1, so I don't think getting a pcap will be difficult for you. But if you can't get it to work, I'll see if I can produce a pcap file for you. Thanks, /Simon