From mann.patidar at gmail.com Mon Mar 8 18:03:47 2010 From: mann.patidar at gmail.com (Manish Patidar) Date: Mon, 8 Mar 2010 22:33:47 +0530 Subject: GNU TLS 2.9.9 , sign/hash extension support Message-ID: <8062bfc61003080903q7958059ei6c96d0c0f9227137@mail.gmail.com> Hi , I was going through the GNU TLS 2.9.9 source code that support TLS 1.2. I have following doubts in gnutls that support of TLS 1.2 rfc 1. While selecting server cert and chain, GNUTLS just compare server certificate with client requested sign/hash extension, not the whole chain. if it matched one of the server certificate , it will select the chain. but according to TLS 1.2 , whole chain must matched with one of the sign/hash algo supported by client. Is my understanding is correct ..? If not , how and which part of code GNU TLS compare the sign/hash algo with the whole chain. 2. While selecting client cert list in response of client cert request, GNU TLS doesn't use parsed sign/hash algo supported server. it just use the cert type and dns name for selecting cert chain ,not sign/hash algo but according to TLS 1.2 , client must compare and select cert chain that matches with one of the sign/hash supported by server. Please let me know if am correct or not. Please provide some of your valuable inputs which clarify above point Regards Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From brentontaylor5 at yahoo.com.au Sat Mar 13 20:11:24 2010 From: brentontaylor5 at yahoo.com.au (Brenton Taylor) Date: Sun, 14 Mar 2010 05:11:24 +1000 Subject: GnuTLS VirtualHost with properly signed certificates Message-ID: <4B9BE35C.2060003@yahoo.com.au> An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun Mar 14 01:14:51 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 13 Mar 2010 19:14:51 -0500 Subject: GnuTLS VirtualHost with properly signed certificates In-Reply-To: <4B9BE35C.2060003@yahoo.com.au> References: <4B9BE35C.2060003@yahoo.com.au> Message-ID: <4B9C2A7B.2010202@fifthhorseman.net> Hi Brenton-- On 03/13/2010 02:11 PM, Brenton Taylor wrote: > I can't seem to find any good documentation on the internet that can explain how > to use properly signed certificates with GnuTLS in my VirtualHost files. > > Distro: Debian lenny > Apache/2.2.9 > mod gnutls I think your question is more about configuration the mod_gnutls apache module than it has to do with the gnutls library. The list you mailed (help-gnutls at gnu.org) is specifically related to the gnutls library; mod_gnutls is a separate project which happens to use the gnutls library. So you might have better luck getting an answer to your question from someone on the mod_gnutls mailing list. Here is information about mod_gnutls: http://www.outoforder.cc/projects/apache/mod_gnutls/ And here is the mailing list for mod_gnutls: http://lists.outoforder.cc/mailman/listinfo/modules hope this helps! --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Mon Mar 15 14:23:00 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 14:23:00 +0100 Subject: GnuTLS 2.8.6 Message-ID: <87fx411zyj.fsf@mocca.josefsson.org> We are proud to announce a new stable GnuTLS release: Version 2.8.6. GnuTLS is a modern C library that implements 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 GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnu.org/software/gnutls/ What's New ========== ** libgnutls: For CSRs, don't null pad integers for RSA/DSA value. VeriSign rejected CSRs with this padding. Reported by Wilankar Trupti and Boyan Kasarov . Note: As a side effect of this change, the "public key identifier" value computed for a certificate using this version of GnuTLS will be different from values computed using earlier versions of GnuTLS. ** libgnutls: For CSRs on DSA keys, don't add DSA parameters to the ** optional SignatureAlgorithm parameter field. VeriSign rejected these CSRs. They are stricly speaking not needed since you need the signer's certificate to verify the certificate signature anyway. Reported by Wilankar Trupti and Boyan Kasarov . ** libgnutls: When checking openpgp self signature also check the signatures ** of all subkeys. Ilari Liusvaara noticed and reported the issue and provided test vectors as well. ** libgnutls: Cleanups and several bug fixes. Found by Steve Grubb and Tomas Mraz. ** Link libgcrypt explicitly to certtool, gnutls-cli, gnutls-serv. ** Fix --disable-valgrind-tests. Reported by Ingmar Vanhassel in . ** examples: Use the new APIs for printing X.509 certificate information. ** Fix build failures on Solaris. Thanks to Dagobert Michelsen . ** i18n: Updated Czech, Dutch, French, Polish, Swedish and Vietnamese ** translations. Added Simplified Chinese translation. ** 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 . Here are the BZIP2 compressed sources (6.2MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.8.6.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.8.6.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: 2011-03-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: 2011-03-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: bff911d4fd7389aa6698a644b3748eb2d23715bc gnutls-2.8.6.tar.bz2 a6b36fa1926a7fd3cb68746446c29dc1cbef0cc6bcfd25877fde64ad gnutls-2.8.6.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 For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel 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 includes libgpg-error v1.7, libgcrypt v1.4.5, libtasn1 v2.4, and GnuTLS v2.8.6. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.8.6.exe (16MB) http://josefsson.org/gnutls4win/gnutls-2.8.6.exe.sig The checksum values for SHA-1 and SHA-224 are: cbfc717d33edbc1f6eb891e14e5d6935bcfb7dc6 gnutls-2.8.6.exe 42e5bc23dd110de93f36d1e4e13447083d4127e1da18b190f02b4031 gnutls-2.8.6.exe A ZIP archive containing the Windows binaries: http://josefsson.org/gnutls4win/gnutls-2.8.6.zip (5.3MB) http://josefsson.org/gnutls4win/gnutls-2.8.6.zip.sig The checksum values for SHA-1 and SHA-224 are: 5009ea643cad906e86ec85d3d3814ac78a73e66a gnutls-2.8.6.zip 965b5c535956ea8f8b0d93b3badd1ce23d21624a6fa35a05fa20919f gnutls-2.8.6.zip A Debian mingw32 package is also available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.8.6-1_all.deb (4.8MB) The checksum values for SHA-1 and SHA-224 are: 8719083d715ad5f244265bfeebedf491112f6a8a mingw32-gnutls_2.8.6-1_all.deb ef6b6b927968ea393ee3571a649d325232c33ee92335eaf2dc090c55 mingw32-gnutls_2.8.6-1_all.deb Internationalization ==================== The GnuTLS library messages have been translated into Czech, Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. 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 AB, 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: 420 bytes Desc: not available URL: From simon at josefsson.org Mon Mar 15 14:44:25 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 14:44:25 +0100 Subject: GNU Libtasn1 2.5 Message-ID: <87bpep1yyu.fsf@mocca.josefsson.org> GNU Libtasn1 is a standalone library written in C for manipulating ASN.1 objects including DER/BER encoding/decoding. GNU Libtasn1 is used by GnuTLS to handle X.509 structures and by GNU Shishi to handle Kerberos V5 structures. * Noteworthy changes in release 2.5 (2010-03-15) [stable] - doc: Improve GTK-DOC comments. - misc: Updated gnulib files. Homepage: http://www.gnu.org/software/libtasn1/ Here are the compressed sources (1.7MB): ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz Here are GPG detached signatures using key 0xB565716F: ftp://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig http://ftp.gnu.org/gnu/libtasn1/libtasn1-2.5.tar.gz.sig A ZIP archive containing the Windows binaries (264KB): http://josefsson.org/gnutls4win/libtasn1-2.5.zip http://josefsson.org/gnutls4win/libtasn1-2.5.zip.sig A Debian mingw32 package is also available (240KB): http://josefsson.org/gnutls4win/mingw32-libtasn1_2.5-1_all.deb Commercial support contracts for Libtasn1 are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding Libtasn1 maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. If you need help to use Libtasn1, or want to help others, you are invited to join the help-gnutls mailing list, see: . All manuals are available from: http://www.gnu.org/software/gsasl/manual/ Specifically, the following formats are available. The main manual: HTML: http://www.gnu.org/software/gsasl/manual/gsasl.html PDF: http://www.gnu.org/software/gsasl/manual/gsasl.pdf API Reference manual: http://www.gnu.org/software/gsasl/reference/ - GTK-DOC HTML For developers interested in improving code quality, we publish Cyclomatic code complexity charts that help you find code that may need review and improvements: http://www.gnu.org/software/gnutls/cyclo/ Also useful are code coverage charts which indicate parts of the source code that needs to be tested better by the included self-tests: http://www.gnu.org/software/gnutls/coverage/ The software is cryptographically signed by the author using an OpenPGP key identified by the following information: pub 1280R/B565716F 2002-05-05 [expires: 2011-03-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: 2011-03-30] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the SHA-1 and SHA-224 checksums: e317282a86702fb57133b50199df47a7fcf681ca libtasn1-2.5.tar.gz 69e53bb61f3512aa8d1eb72640778b4adebf6818a4493548cc7faf2d libtasn1-2.5.tar.gz 784faa0f4aff35aee1ac420013a9e47aa4892d12 libtasn1-2.5.zip 98177b4e5cbc3bae34dd7813940bec99c802275c9dd0cb77f06a1d3d libtasn1-2.5.zip a5427f26d051a3ab30a8f5bea0abcdf6d3d83f0f mingw32-libtasn1_2.5-1_all.deb 6e781ec4652f8d3fd58e3742dd19f69804665356c11c50e179ed1756 mingw32-libtasn1_2.5-1_all.deb Happy hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From nmav at gnutls.org Mon Mar 15 21:46:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Mar 2010 21:46:33 +0100 Subject: safe renegotiation in client side Message-ID: <4B9E9CA9.4070901@gnutls.org> As you may have noticed there was a big fuss lately about a bug in the TLS protocol that could cause a client to connect to the wrong server via a renegotiation. There is a fix to the protocol that is unfortunately incompatible with previous versions (if security is required). Thus a gnutls client implementing the fix cannot connect to any non-patched server[0]. To achieve compatibility one has to to explicitly allow unsafe renegotiation with a priority string. This is not always possible since gnutls might be used unintentionally by a program via another library. With some trials in my system I noticed that the current behavior causes denial of service and a simple user might not even have control over the priority string for gnutls. Given your experiences (as system packager, user, implementor or so), what do you think is the adoption of priority strings in programs? Given a program that uses gnutls is it easy to set a string with the algorithms etc. needed for the negotiation? I have been in favor of enabling safe renegotiation for the client before, but seeing how gnutls is being used today, I might have not been correct and enabling it might cause more trouble than the issue it solves. Please let me know of what you think. regards, Nikos [0]. so far the fix adoption wasn't that great. From simon at josefsson.org Mon Mar 15 22:00:59 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 22:00:59 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9E9CA9.4070901@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 15 Mar 2010 21:46:33 +0100") References: <4B9E9CA9.4070901@gnutls.org> Message-ID: <873a01wb90.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Given your experiences (as system packager, user, implementor or so), > what do you think is the adoption of priority strings in programs? I find it quite rare still, sadly. I don't recall _any_ application that allows users to configure priority strings per-IP address, which would be the optimal approach. I believe it would be painful to release a GnuTLS client that refused to talk to non-patched servers. If I understand correctly, it doesn't improve anything for the client to behave like that, it is only the server that is protected by such a client. Thus, I think we should let servers require patched clients when it makes sense, and otherwise be more lenient on the client side. I wish there was an easy way to warn the user somehow though. Syslog a message with the server hostname? Should we add a function so that applications can find out if a session is potentially insecure due to this threat? Any way to make it less specific to renegotiation issues? We have other areas that users may want to be aware of too -- e.g., if the connection is using a weak cipher, if the connection is not using DHE, etc... OTOH maybe this is overkill. Power-users can use gnutls-cli to find out manually, and other users are probably fine with a lenient default anyway. /Simon From dkg at fifthhorseman.net Mon Mar 15 22:30:29 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Mar 2010 17:30:29 -0400 Subject: safe renegotiation in client side In-Reply-To: <873a01wb90.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> Message-ID: <4B9EA6F5.4000805@fifthhorseman.net> On 03/15/2010 05:00 PM, Simon Josefsson wrote: > I believe it would be painful to release a GnuTLS client that refused to > talk to non-patched servers. I agree that it would be painful. > If I understand correctly, it doesn't > improve anything for the client to behave like that, it is only the > server that is protected by such a client. I don't think this is the case. A client connecting to an unpatched server is vulnerable to their connection being used to authenticate another request that they are unaware of. The attack in question is a plaintext prefix injection attack: the attacker starts a session with the server, and then prompts a re-negotiation. It hands off the re-negotiation to the actual client, which might then negotiate to the server thinking that it is the initial connection (not a re-negotiation). If the server then uses the new connections credentials to act on the original (spoofed) part of the session, it is the *client's* credentials which have been mis-applied, not the server's. clients which "fail closed" by rejecting connections to unpatched servers cannot have their credentials mis-applied in this way. (they also won't be able to talk to the majority of the TLS-capable hosts on the 'net today, unfortunately). > Thus, I think we should let > servers require patched clients when it makes sense, and otherwise be > more lenient on the client side. libnss (the mozilla tls implementation) has an interesting phased approach planned to deal with this situation: https://wiki.mozilla.org/Security:Renegotiation i know gnutls doesn't expose as much in the way of a UI as NSS clients like firefox or thunderbird; but if there's some way to adopt a similar approach, i'd like to examine it. Every libgnutls-aware program can see the environment, for example. is using a clearly-scoped environment variable to provide a priority string if none other are supplied out of the question? Or what about ~/.libgnutls/config or something similar? I'm just brainstorming here, feel free to explain why these are horrible proposals. > I wish there was an easy way to warn the user somehow though. Syslog a > message with the server hostname? Should we add a function so that > applications can find out if a session is potentially insecure due to > this threat? Any way to make it less specific to renegotiation issues? > We have other areas that users may want to be aware of too -- e.g., if > the connection is using a weak cipher, if the connection is not using > DHE, etc... OTOH maybe this is overkill. Power-users can use > gnutls-cli to find out manually, and other users are probably fine with > a lenient default anyway. gnutls-cli can find out manually for a different connection -- it won't let you inspect an active connection, will it? i agree that configurable reporting would be useful, though (and i like your assessment of the other concerns we might want to permit but warn about). Seems like a generic interface would be a way for library users register a callback that reports "warnings about your connection", along with an enumerated list (and maybe localized strings describing the problems). I like that idea, but if we can't convince application developers to let end users pass in a priority string, it seems unlikely that we'd get them to register such a callback, let alone report the warnings to their users in a sane way :/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Mon Mar 15 23:33:20 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 23:33:20 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9EA6F5.4000805@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Mar 2010 17:30:29 -0400") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> Message-ID: <87fx41tdu7.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: >> If I understand correctly, it doesn't >> improve anything for the client to behave like that, it is only the >> server that is protected by such a client. > > I don't think this is the case. A client connecting to an unpatched > server is vulnerable to their connection being used to authenticate > another request that they are unaware of. > > The attack in question is a plaintext prefix injection attack: the > attacker starts a session with the server, and then prompts a > re-negotiation. It hands off the re-negotiation to the actual client, > which might then negotiate to the server thinking that it is the initial > connection (not a re-negotiation). If the server then uses the new > connections credentials to act on the original (spoofed) part of the > session, it is the *client's* credentials which have been mis-applied, > not the server's. Right. But it is the server that makes the mistake of assuming that the newly negotiated client credentials has anything to do with the earlier request, isn't it? To me, the renegotiation protocol flaw means that any server that uses renegotiation MUST require support for safe-renegotiation in the client. This is a critical security issue with the server that needs to be addressed as quickly as possible. I don't see any critical security issue on the client side at all. The only reason clients needs to be upgraded is that without clients, servers will be unable to use renegotiation. > clients which "fail closed" by rejecting connections to unpatched > servers cannot have their credentials mis-applied in this way. (they > also won't be able to talk to the majority of the TLS-capable hosts on > the 'net today, unfortunately). Right, if a client has a policy of not talking to any potentially buggy server, this makes sense. But I'm not sure that is useful -- servers are potentially buggy all the time (many still only supports SSL 3.0), but clients still wants to talk to them. >> Thus, I think we should let >> servers require patched clients when it makes sense, and otherwise be >> more lenient on the client side. > > libnss (the mozilla tls implementation) has an interesting phased > approach planned to deal with this situation: > > https://wiki.mozilla.org/Security:Renegotiation > > i know gnutls doesn't expose as much in the way of a UI as NSS clients > like firefox or thunderbird; but if there's some way to adopt a similar > approach, i'd like to examine it. > > Every libgnutls-aware program can see the environment, for example. is > using a clearly-scoped environment variable to provide a priority string > if none other are supplied out of the question? Or what about > ~/.libgnutls/config or something similar? I'm just brainstorming here, > feel free to explain why these are horrible proposals. Couldn't we be lenient today, and in 2-3 years time start to reject buggy servers by default? >> I wish there was an easy way to warn the user somehow though. Syslog a >> message with the server hostname? Should we add a function so that >> applications can find out if a session is potentially insecure due to >> this threat? Any way to make it less specific to renegotiation issues? >> We have other areas that users may want to be aware of too -- e.g., if >> the connection is using a weak cipher, if the connection is not using >> DHE, etc... OTOH maybe this is overkill. Power-users can use >> gnutls-cli to find out manually, and other users are probably fine with >> a lenient default anyway. > > gnutls-cli can find out manually for a different connection -- it won't > let you inspect an active connection, will it? Right, I'm just thinking of how to identify buggy/working servers. > i agree that configurable reporting would be useful, though (and i like > your assessment of the other concerns we might want to permit but warn > about). Seems like a generic interface would be a way for library users > register a callback that reports "warnings about your connection", along > with an enumerated list (and maybe localized strings describing the > problems). > > I like that idea, but if we can't convince application developers to let > end users pass in a priority string, it seems unlikely that we'd get > them to register such a callback, let alone report the warnings to their > users in a sane way :/ I agree, so it seems like a waste of time right now. :-( /Simon From simon at josefsson.org Mon Mar 15 23:38:05 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Mar 2010 23:38:05 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9E9CA9.4070901@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 15 Mar 2010 21:46:33 +0100") References: <4B9E9CA9.4070901@gnutls.org> Message-ID: <87bpeptdma.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > I have been in favor of enabling safe renegotiation for the client > before, but seeing how gnutls is being used today, I might have not been > correct and enabling it might cause more trouble than the issue it solves. I just had a thought, it may be wrong due to late at night... Using safe renegotiation is only important if the client provides credentials, right? It sounds as if in your testing, GnuTLS clients were unable to talk to any server, even if the clients didn't provide a client certificate. Is that right? If that is the case, can't we make GnuTLS accept talking to "old" servers by default, but if client certificate authentication is requested by the application, it will tear down the connection if the server doesn't support safe-renegotiation? My impression is that client certificate authentication is still not that widely used by applications. This way, we'll be 100% secure but still work in the majority of cases. People using client certificate authentication will not be able to talk with old servers, but that is what they should get. /Simon From dkg at fifthhorseman.net Tue Mar 16 00:15:35 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 15 Mar 2010 19:15:35 -0400 Subject: safe renegotiation in client side In-Reply-To: <87fx41tdu7.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> Message-ID: <4B9EBF97.5090805@fifthhorseman.net> On 03/15/2010 06:33 PM, Simon Josefsson wrote: > Right. But it is the server that makes the mistake of assuming that the > newly negotiated client credentials has anything to do with the earlier > request, isn't it? yes, that's true, but it's true at the application layer which the TLS implementation (and any client) can't actually know anything about. basically, TLS without safe renegotiation has the property that any single ongoing connection stream may in fact consist of a series of communications with unrelated remote parties. This property was apparently surprising to most application developers, who were relying on the presumed semantics that the remote endpoint in a TLS connection would always be the same entity. "safe renegotiation" enforces this presumed semantics. If you're communicating with an endpoint that does not support safe-reneg, it is unsafe to assume those semantics hold (and so your current connection might be part of a larger aggregated series of connections of which you are unaware, with whatever consequences that might have on the remote peer). > To me, the renegotiation protocol flaw means that any server that uses > renegotiation MUST require support for safe-renegotiation in the client. > This is a critical security issue with the server that needs to be > addressed as quickly as possible. I don't see any critical security > issue on the client side at all. The only reason clients needs to be > upgraded is that without clients, servers will be unable to use > renegotiation. But clients have no way of knowing that their connections won't be seen as part of a larger aggregate connection unless they are confident that the server supports safe-reneg. A client who wants to protect their session from such a situation does need to "fail closed" when talking to an incompatible server. > Right, if a client has a policy of not talking to any potentially buggy > server, this makes sense. But I'm not sure that is useful -- servers > are potentially buggy all the time (many still only supports SSL 3.0), > but clients still wants to talk to them. yup. but if they want to talk to them with any particular security guarantees, they need to fail to connect to peers which cannot negotiate those security guarantees. If you're willing to sacrifice the security guarantees (confidentiality, authenticity, etc) for the same of just connecting, why use TLS in the first place? > Couldn't we be lenient today, and in 2-3 years time start to reject > buggy servers by default? yes, we could (though i hope that it won't be 3 years before that happens). I don't think that would be the worst policy to take. But any popular TLS client implementation also plays a role in spurring adoption of safe-reneg among servers by its choice of enforcement (and warning messages, etc). I'd like to see GnuTLS contribute to the "peer pressure" here in some positive way. i'm not saying that default-fail-closed is necessarily the best way to do that, but an entirely lenient policy is pretty weak on the peer pressure side and doesn't contribute to the overall security of network communications in general. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Tue Mar 16 13:02:48 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 13:02:48 +0100 Subject: safe renegotiation in client side In-Reply-To: <4B9EBF97.5090805@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 15 Mar 2010 19:15:35 -0400") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> Message-ID: <87r5nkpj87.fsf@mocca.josefsson.org> Daniel Kahn Gillmor writes: > But any popular TLS client implementation also plays a role in spurring > adoption of safe-reneg among servers by its choice of enforcement (and > warning messages, etc). I'd like to see GnuTLS contribute to the "peer > pressure" here in some positive way. i'm not saying that > default-fail-closed is necessarily the best way to do that, but an > entirely lenient policy is pretty weak on the peer pressure side and > doesn't contribute to the overall security of network communications in > general. I agree. So, we could release an experimental version where clients required safe renegotiation, get it into various distributions, and try applications that use GnuTLS to see if they work or not? The important part is likely how well applications support priority strings for easy user fall backs. How well error reporting works is also important. Maybe our energy is better spent helping application writers here... I'll do some experiments with 2.9.10 on my machine... maybe best to get a release out first though. /Simon From trapni at gentoo.org Tue Mar 16 15:19:33 2010 From: trapni at gentoo.org (Christian Parpart) Date: Tue, 16 Mar 2010 15:19:33 +0100 Subject: handshaking takes too long (although, session resuming *seems* to work) Message-ID: [first: sorry for cross-posting, I accidentally posted into gnutls-devel and wondered WTF my message doesn't arrive at help-gnutls :)] Hey, i've just implemented SSL in my little web server, however, the handshaking tooks quite long, so I added session resuming to it (based on the example code I found in the sources), and added some debug prints to see whether they're actually invoked. What I now see, is, that on first (client web browser) connect, a record gets stored my cache, and on the second call, I successively return this data back to gnutls, however, the session resuming still takes as much time as on the first request. I've tested it on my netbook (quite thin hardware, though), and there it takes about 2.5 seconds. still too long even without session resuming? Compared to Apache, even the first request responded quite instant. But what could the reasons be? Thanks in advance, Christian Parpart. From nmav at gnutls.org Tue Mar 16 15:35:24 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:35:24 +0100 Subject: handshaking takes too long (although, session resuming *seems* to work) In-Reply-To: References: Message-ID: On Tue, Mar 16, 2010 at 3:19 PM, Christian Parpart wrote: > What I now see, is, that on first (client web browser) connect, a record > gets stored my cache, and on the second call, I successively return this > data back to gnutls, however, the session resuming still takes as much > time as on the first request. Does your client support session resumption? It has to be supported by both to be effective. If you use gnutls-cli add the --resume option. > I've tested it on my netbook (quite thin hardware, though), and there it > takes about 2.5 seconds. still too long even without session resuming? > Compared to Apache, even the first request responded quite instant. Different algorithms in gnutls have different speeds. The defaults are sorted on a security margin and speed was not a concern. Check the priority functions documentation for more information. regards, Nikos From nmav at gnutls.org Tue Mar 16 15:48:06 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Mar 2010 15:48:06 +0100 Subject: safe renegotiation in client side In-Reply-To: <87r5nkpj87.fsf@mocca.josefsson.org> References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> <87r5nkpj87.fsf@mocca.josefsson.org> Message-ID: On Tue, Mar 16, 2010 at 1:02 PM, Simon Josefsson wrote: > I'll do some experiments with 2.9.10 on my machine... maybe best to get > a release out first though. At least in my system I couldn't do basic stuff (use svn over ssl) and couldn't find any fix for those (except changing gnutls). I no longer use openldap to login in my system, but I remember this also doesn't provide access to priority strings, which would also cause a denial of service. I'm also leaning towards having the first releases without enforced safe renegotiation and enforcing it at a later time that does not cause more trouble than it solves. Debug strings warning about that are now being printed via the gnutls logging, but are not visible in most applications (and even if it was might not offer any information to a typical user since it will be issued for almost every server today). What we can do is add a warning on the gnutls-cli if the server does not support safe renegotiation? (gnutls-cli-debug can also detect that). regards, Nikos From simon at josefsson.org Tue Mar 16 15:55:16 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 15:55:16 +0100 Subject: safe renegotiation in client side In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:48:06 +0100") References: <4B9E9CA9.4070901@gnutls.org> <873a01wb90.fsf@mocca.josefsson.org> <4B9EA6F5.4000805@fifthhorseman.net> <87fx41tdu7.fsf@mocca.josefsson.org> <4B9EBF97.5090805@fifthhorseman.net> <87r5nkpj87.fsf@mocca.josefsson.org> Message-ID: <87vdcwmi3v.fsf@mocca.josefsson.org> Could we syslog() a message with the address of the server that is buggy when a client invokes gnutls_handshake()? We need to extract the server IP address from a socket, though, and will need to be very careful about handling return values from every syscall. (It may not even be a socket, GnuTLS doesn't require that, but then it could just say that the server is buggy with no address..) Even if we don't have the syslog operation in upstream GnuTLS, we could recommend a patch so that RedHat/Debian/Ubuntu/etc can apply it in their builds. This may lead to people upgrading their important servers more quickly. /Simon From simon at josefsson.org Tue Mar 16 16:08:53 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 16 Mar 2010 16:08:53 +0100 Subject: handshaking takes too long (although, session resuming *seems* to work) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Tue, 16 Mar 2010 15:35:24 +0100") References: Message-ID: <87y6hsl2wq.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > On Tue, Mar 16, 2010 at 3:19 PM, Christian Parpart wrote: > >> What I now see, is, that on first (client web browser) connect, a record >> gets stored my cache, and on the second call, I successively return this >> data back to gnutls, however, the session resuming still takes as much >> time as on the first request. > > Does your client support session resumption? It has to be supported by both to > be effective. If you use gnutls-cli add the --resume option. > >> I've tested it on my netbook (quite thin hardware, though), and there it >> takes about 2.5 seconds. still too long even without session resuming? >> Compared to Apache, even the first request responded quite instant. > > Different algorithms in gnutls have different speeds. The defaults are sorted > on a security margin and speed was not a concern. Check the priority functions > documentation for more information. A 2.5 second delay strongly suggest something outside GnuTLS is causing the delays though. I'm using mod_gnutls under Apache on a few production systems and it is comparable in speed to mod_ssl. /Simon From mann.patidar at gmail.com Fri Mar 19 05:53:43 2010 From: mann.patidar at gmail.com (ManishPatidar) Date: Thu, 18 Mar 2010 21:53:43 -0700 (PDT) Subject: setting Cipher suites Message-ID: <27950891.post@talk.nabble.com> Hi, How we can set particular cipher suite using gnutls_priority_set_direct OR gnutls_priority_init API ..? for example if I want to set only TLS_RSA_AES_128_CBC_SHA1 cipher suite and dont want to set any other cipher,What are the parameter I have to pass..? Regards Manish -- View this message in context: http://old.nabble.com/setting-Cipher-suites-tp27950891p27950891.html Sent from the Gnu - TLS mailing list archive at Nabble.com. From nmav at gnutls.org Fri Mar 19 10:39:42 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Mar 2010 10:39:42 +0100 Subject: setting Cipher suites In-Reply-To: <27950891.post@talk.nabble.com> References: <27950891.post@talk.nabble.com> Message-ID: This example is actually copied from the manual: NONE:+VERS-TLS1.0:+AES-128-CBC:+RSA:+SHA1:+COMP-NULL You can add SSL3.0, TLS.1.1, TLS1.2 to the list as well. regards, Nikos On Fri, Mar 19, 2010 at 5:53 AM, ManishPatidar wrote: > > Hi, > > How we can set particular cipher suite using gnutls_priority_set_direct OR > gnutls_priority_init API ..? > for example if I want to set only TLS_RSA_AES_128_CBC_SHA1 cipher suite and > dont want to set any other cipher,What are the parameter I have to pass..? > > > > Regards > Manish > -- > View this message in context: http://old.nabble.com/setting-Cipher-suites-tp27950891p27950891.html > Sent from the Gnu - TLS mailing list archive at Nabble.com. > > > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From simon at josefsson.org Thu Mar 25 09:21:27 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 25 Mar 2010 09:21:27 +0100 Subject: Security problem in GnuTLS v1.2.0 and earlier [GNUTLS-SA-2010-1] Message-ID: <87hbo4hkvs.fsf@mocca.josefsson.org> GnuTLS version 1.2.0 and earlier (released on 2005-01-27) on 64-bit platforms are vulnerable to a bug described in: https://bugzilla.redhat.com/show_bug.cgi?id=573028 Please note that the problem was solved for GnuTLS 1.2.1, released on 2005-04-04. Also, 32-bit platforms are not affected. I have added information about this on http://www.gnu.org/software/gnutls/security.html so that it contains the complete list of known security flaws. I'm using the keyword GNUTLS-SA-2010-1 for this. Thanks to Tomas Hoger and the RedHat team for finding and tracking down this problem. I have given this bug a 'Remote Denial of Service' severity, but if anyone has time to look at this bug, justification for any other severity is welcome. /Simon Tomas Hoger 2010-03-12 11:16:28 EST During the testing of GnuTLS updates, a flaw was discovered affecting Red Hat Enterprise Linux 4 GnuTLS packages on s390x platform, causing gnutls-cli to crash while printing server certificate info. This crash was caused by a flaw in gnutls_x509_crt_get_serial(), which calls asn1_read_value() to extract serial number from the x509 certificate. (lib/x509/x509.c) 526 int gnutls_x509_crt_get_serial(gnutls_x509_crt cert, void* result, 527 size_t* result_size) 528 { ... 536 if ((ret = asn1_read_value(cert->cert, "tbsCertificate.serialNumber", result, result_size)) < 0) { asn1_read_value() expects pointer to int (32 bit) as its third argument, but gnutls_x509_crt_get_serial() passed pointer to size_t (64 bit on 64 bit platforms) instead. On 64bit big endian platforms asn1_read_value() got incorrect length value. (lib/minitasn1/element.c) 598 asn1_retCode 599 asn1_read_value(node_asn *root,const char *name,void* ivalue, int *len) On little endian 64 bit platforms, high 32 bits of the *result_size size_t value were lost, but they only contained zeros. On big endian 64 bit platforms, low 32 bits were lost / ignored, causing asn1_read_value() to see length value as 0. This caused asn1_read_value() to return an error, but the length of the value that should have been extracted was saved to *len. gnutls_x509_crt_get_serial() did not correctly check return value of asn1_read_value(), failing to detect an error. After returning, caller could see a high value stored in *result_size (when interpreted as 64 bit value again). print_x509_info() (used by gnutls-cli or gnutls-serv) and print_certificate_info() (used by certtool) relied on the returned size value. Unexpected value caused a stack buffer overflow in those functions. This bug could also cause gnutls_x509_crt_check_revocation() to incorrectly check supplied X509 certificate against the list of revoked certificates, resulting in a bypass or the CRL check. This issue was fixed upstream via following commit: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=112d537d This fix was first included in upstream version 1.2.1. Therefore, GnuTLS packages in Red Hat Enterprise Linux 5, Fedora, and current upstream GnuTLS versions are not affected by this flaw. Comment 2 Tomas Hoger 2010-03-25 03:57:43 EDT Making bug public. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 420 bytes Desc: not available URL: From mafeusek at gmail.com Tue Mar 30 17:33:25 2010 From: mafeusek at gmail.com (Pawel p) Date: Tue, 30 Mar 2010 17:33:25 +0200 Subject: subject: using starttls with ssh tunnel. Message-ID: Hallo Group Members. I configured ssh tunnel to smtp.gmail.com(74.125.77.109): nohup ssh -l user -NL 2587:74.125.77.109:587 internal.mail.proxy & , because I cannot get it directly, through default proxy. Is there a way to force TLS accept certificate? prompt$ gnutls-cli -s -p 2587 localhost Resolving 'localhost'... Connecting to '127.0.0.1:2587'... - Simple Client Mode: 220 mx.google.com ESMTP 16cm973753ewy.7 EHLO bar.com 250-mx.google.com at your service, [167.34.56.23] 250-SIZE 35651584 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 PIPELINING STARTTLS 220 2.0.0 Ready to start TLS *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Mountain View,O=Google Inc,CN= smtp.gmail.com', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server at thawte.com', RSA key 1024 bits, signed using RSA-SHA, activated `2007-07-30 00:00:00 UTC', expires `2010-07-29 23:59:59 UTC', SHA-1 fingerprint `4567cace1acd21c94f347455e5674464f5de19761' - The hostname in the certificate does NOT match 'localhost' -------------- next part -------------- An HTML attachment was scrubbed... URL: