From jas at extundo.com Fri Oct 7 15:27:10 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 07 Oct 2005 15:27:10 +0200 Subject: [Help-gnutls] GnuTLS 1.2.8 Message-ID: We are pleased to announce the availability of GnuTLS version 1.2.8. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. Noteworthy changes since version 1.2.7: - Libgcrypt 1.2.2 is required to fix a bug for forking GnuTLS servers. - Don't install the auxilliary libexamples library used by the examples in doc/examples/ on "make install", report and tiny patch from Thomas Klausner . - If you pass a X.509 CA or PGP trust database to the command line tool, it will now abort the connection if the server certificate validation fails. Use the parameter --insecure to continue even after certificate validation failures. Inspired from discussion with Alexander Kotelnikov . - The test for socklen_t has been moved to gnulib. - Link failures for duplicate or missing "program_name" symbol has been fixed, patch from Martin Lambers . - The command line tool and the examples no longer uses mmap or bzero, to make them more portable, patch from Martin Lambers . - Made the PKCS #12 API handle null passwords. Based on patch by Anton Altaparmakov . - The GTK-DOC manual should build with current released tools. (But a copy of the output is included, so the tools are not required.) - The inet_ntop function is now used through gnulib. - API and ABI modifications: No changes since last version. 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. If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: . The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ (updated fastest) Here are the compressed sources: http://josefsson.org/gnutls/releases/gnutls-1.2.8.tar.bz2 (2.5MB) ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.8.tar.bz2 (2.5MB) Here are GPG detached signatures signed using key 0xB565716F: http://josefsson.org/gnutls/releases/gnutls-1.2.8.tar.bz2.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-1.2.8.tar.bz2.sig The software is cryptographically signed by the author using an OpenPGP key identified by the following information: 1280R/B565716F 2002-05-05 [expires: 2006-02-28] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Here are the build reports for various platforms: http://josefsson.org/autobuild-logs/gnutls.html Here are the SHA-1 checksums: b49c86de7c10946bf440ea146f89a31474297872 gnutls-1.2.8.tar.bz2 baf44ff87e373005d3601fdde7d21f39c1269516 gnutls-1.2.8.tar.bz2.sig Enjoy, Nikos and Simon From e_agf at yahoo.es Tue Oct 25 23:39:57 2005 From: e_agf at yahoo.es (Fran) Date: Tue, 25 Oct 2005 23:39:57 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? Message-ID: <1130276398.5010.4.camel@localhost> If the computer spend 0,1 seconds making a key the first time. Making second an other keys, the computer can spend 10 or more seconds. I think that this can be a problem. ? Entropy ? From nmav at gnutls.org Wed Oct 26 11:09:36 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Oct 2005 11:09:36 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <1130276398.5010.4.camel@localhost> References: <1130276398.5010.4.camel@localhost> Message-ID: <200510261109.36886.nmav@gnutls.org> On Tuesday 25 October 2005 23:39, Fran wrote: > If the computer spend 0,1 seconds making a key the first time. Making > second an other keys, the computer can spend 10 or more seconds. > I think that this can be a problem. I suppose you talk about certtool. This is a good thing. The first key depletes entropy from /dev/random. The second key the same. The system needs some time to gather entropy. -- Nikos Mavrogiannopoulos From dima at ac93.org Wed Oct 26 22:31:53 2005 From: dima at ac93.org (Dima Barsky) Date: Wed, 26 Oct 2005 21:31:53 +0100 Subject: [Help-gnutls] Certificate verification failed Message-ID: <17247.59321.125197.576087@kappa.ac93.org> Hello, I have a small python application which uses pycurl to download my bank statements every week. I was using pycurl built with openssl until recently and the application worked fine. A few days ago I upgraded the pycurl and the libcurl packages (they are now built with GnuTLS 1.2.8) and the application stopped working, it does not accept the bank's certificate any more. This small script illustrates the problem: #!/usr/bin/python import pycurl c = pycurl.Curl() c.setopt(c.URL, 'https://www2.net.hsbc.com/') c.setopt(c.VERBOSE, 1) c.perform() Here is the script's output: * About to connect() to www2.net.hsbc.com port 443 * Trying 205.241.15.110... * connected * Connected to www2.net.hsbc.com (205.241.15.110) port 443 * found 99 certificates in /etc/ssl/certs/ca-certificates.crt * server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt * Closing connection #0 Traceback (most recent call last): File "test.py", line 6, in ? c.perform() pycurl.error: (60, 'server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt') Initially I thought the problem was either in pycurl or libcurl. However, when I tried to verify the site's certificate with gnutls-cli it also failed: $ gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt www2.net.hsbc.com Processed 99 CA certificate(s). Resolving 'www2.net.hsbc.com'... Connecting to '205.241.15.110:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: # The hostname in the certificate matches 'www2.net.hsbc.com'. # valid since: Wed May 4 01:00:00 BST 2005 # expires at: Fri May 5 00:59:59 BST 2006 # serial number: 0A:C6:FC:D0:29:5D:8F:82:A3:4F:70:00:21:43:88:B2 # fingerprint: 8C:42:11:CD:D1:AE:AB:9B:73:75:46:BB:C4:9C:D2:5E # version: #3 # public key algorithm: RSA (1024 bits) # e [24 bits]: 01:00:01 # m [1032 bits]: 00:BD:2A:31:5C:D6:59:F8:43:BC:A7:DB:B2:FB:06:9C:DA:30:91:F7:C2:CE:2C:86:94:14:FF:8E:C2:6F:88:E8:F5:A5:F8:11:40:CE:2D:F3:F2:12:BF:DB:A0:C8:06:85:1C:41:1F:EA:C0:7C:69:6A:A5:CD:37:74:74:4B:DE:19:CF:43:DA:96:E5:E3:5A:18:F1:4B:EA:CC:F7:42:93:82:8A:63:E8:8B:6C:7B:0B:08:6E:7D:EF:2C:E6:14:CB:02:C6:BE:3D:4C:EA:8D:AD:4E:EF:D4:D3:00:FA:2B:FD:0A:51:66:4B:AA:EE:7E:F1:D6:1E:A0:28:CF:60:CE:8E:83:8B # Subject's DN: C=US,ST=New Jersey,L=Jersey City,O=hsbc.com\, inc.,OU=ny02www2-2005,OU=Terms of use at www.verisign.com/rpa (c)00,CN=www2.net.hsbc.com # Issuer's DN: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign - Certificate[1] info: # valid since: Thu Apr 17 01:00:00 BST 1997 # expires at: Tue Oct 25 00:59:59 BST 2011 # serial number: 25:4B:8A:85:38:42:CC:E3:58:F8:C5:DD:AE:22:6E:A4 # fingerprint: BC:0A:51:FA:C0:F4:7F:DC:62:1C:D8:E1:15:43:4E:CC # version: #3 # public key algorithm: RSA (1024 bits) # e [24 bits]: 01:00:01 # m [1032 bits]: 00:D8:82:80:E8:D6:19:02:7D:1F:85:18:39:25:A2:65:2B:E1:BF:D4:05:D3:BC:E6:36:3B:AA:F0:4C:6C:5B:B6:E7:AA:3C:73:45:55:B2:F1:BD:EA:97:42:ED:9A:34:0A:15:D4:A9:5C:F5:40:25:DD:D9:07:C1:32:B2:75:6C:C4:CA:BB:A3:FE:56:27:71:43:AA:63:F5:30:3E:93:28:E5:FA:F1:09:3B:F3:B7:4D:4E:39:F7:5C:49:5A:B8:C1:1D:D3:B2:8A:FE:70:30:95:42:CB:FE:2B:51:8B:5A:3C:3A:F9:22:4F:90:B2:02:A7:53:9C:4F:34:E7:AB:04:B2:7B:6F # Subject's DN: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign # Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - Certificate[2] info: # valid since: Mon Jan 29 00:00:00 GMT 1996 # expires at: Wed Aug 2 00:59:59 BST 2028 # serial number: 70:BA:E4:1D:10:D9:29:34:B6:38:CA:7B:03:CC:BA:BF # fingerprint: 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67 # version: #1 # public key algorithm: RSA (1024 bits) # e [24 bits]: 01:00:01 # m [1032 bits]: 00:C9:5C:59:9E:F2:1B:8A:01:14:B4:10:DF:04:40:DB:E3:57:AF:6A:45:40:8F:84:0C:0B:D1:33:D9:D9:11:CF:EE:02:58:1F:25:F7:2A:A8:44:05:AA:EC:03:1F:78:7F:9E:93:B9:9A:00:AA:23:7D:D6:AC:85:A2:63:45:C7:72:27:CC:F4:4C:C6:75:71:D2:39:EF:4F:42:F0:75:DF:0A:90:C6:8E:20:6F:98:0F:F8:AC:23:5F:70:29:36:A4:C9:86:E7:B1:9A:20:CB:53:A5:85:E7:3D:BE:7D:9A:FE:24:45:33:DC:76:15:ED:0F:A2:71:64:4C:65:2E:81:68:45:A7 # Subject's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority # Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - Peer's certificate is NOT trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: ARCFOUR 128 - MAC: MD5 - Compression: NULL *** Verifying server certificate failed... I don't see anything wrong with this certificate. Both mozilla-firefox and openssl accept it without any problem. Is it a bug in gnutls, or am I doing something wrong? Regards, Dima. From e_agf at yahoo.es Wed Oct 26 22:51:27 2005 From: e_agf at yahoo.es (Fran) Date: Wed, 26 Oct 2005 22:51:27 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <200510261109.36886.nmav@gnutls.org> References: <1130276398.5010.4.camel@localhost> <200510261109.36886.nmav@gnutls.org> Message-ID: <1130359888.4565.17.camel@localhost> I. On M?r, 2005-10-26 at 11:09 +0200, Nikos Mavrogiannopoulos wrote: > On Tuesday 25 October 2005 23:39, Fran wrote: > > If the computer spend 0,1 seconds making a key the first time. Making > > second an other keys, the computer can spend 10 or more seconds. > > I think that this can be a problem. > > I suppose you talk about certtool. This is a good thing. The first key > depletes entropy from /dev/random. The second key the same. The system needs > some time to gather entropy. I see /dev/random code an seems that extract data from mouse, keyboard, interrupts, etc. If mouse and keyboard do not affect to the PC, the random number is gathered very slow (very slow). This is a problem of enclosure (deterministic system, low precision), and only should be solved with special device (hardware) with precision that see the caos of real world (more liberty degree). Nothing to be done. Another question: Libcrypt use exit() in functions. The function > gnutls_x509_privkey_generate (key, key_type, bits, 0) does not return any value because libcrypt function use exit(). For this reason a program that have this function can not known which is the problem. For example if > gnutls_global_init(); is not called before. > static void * > _gcry_secmem_malloc_internal (size_t size) > { > memblock_t *mb; > > if (!pool_okay) > { > log_info (_ > ("operation is not possible without initialized secure memory\n")); > exit (2); <<<<<<<------------------------------------------------------------------------------------------------------------------------------------ > } > if (show_warning && !suspend_warning) > { > show_warning = 0; > print_warn (); > } > > /* Blocks are always a multiple of 32. */ > size = ((size + 31) / 32) * 32; > > mb = mb_get_new ((memblock_t *) pool, size); > if (mb) > stats_update (size, 0); > > return mb ? &mb->aligned.c : NULL; > } From daniel at haxx.se Wed Oct 26 22:52:30 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Wed, 26 Oct 2005 22:52:30 +0200 (CEST) Subject: [Help-gnutls] Certificate verification failed In-Reply-To: <17247.59321.125197.576087@kappa.ac93.org> References: <17247.59321.125197.576087@kappa.ac93.org> Message-ID: On Wed, 26 Oct 2005, Dima Barsky wrote: > * found 99 certificates in /etc/ssl/certs/ca-certificates.crt > * server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt ... > $ gnutls-cli -V --x509cafile /etc/ssl/certs/ca-certificates.crt > www2.net.hsbc.com Allow me to just make a note that I believe Dima Barsky is using the latest libcurl and thus libcurl is using the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT option (as previously discussed on this list). So it shouldn't fail because of that at least. (For the record: that problem was fixed in libcurl 7.14.1) -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From dima at ac93.org Wed Oct 26 22:57:48 2005 From: dima at ac93.org (Dima Barsky) Date: Wed, 26 Oct 2005 21:57:48 +0100 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> Message-ID: <17247.60876.451144.98347@kappa.ac93.org> On Wed, 26 Oct 2005, Daniel Stenberg wrote: > Allow me to just make a note that I believe Dima Barsky is using the latest > libcurl and thus libcurl is using the GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT > option (as previously discussed on this list). That's correct, I'm using libcurl 7.15.0. Sorry, should've mentioned this. Anyway, it looks like it has nothing to do with libcurl, as gnutls-cli also fails to verify this certificate. Regards, Dima. From nmav at gnutls.org Wed Oct 26 23:15:32 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Oct 2005 23:15:32 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <1130359888.4565.17.camel@localhost> References: <1130276398.5010.4.camel@localhost> <200510261109.36886.nmav@gnutls.org> <1130359888.4565.17.camel@localhost> Message-ID: <200510262315.32909.nmav@gnutls.org> On Wednesday 26 October 2005 22:51, Fran wrote: > > I suppose you talk about certtool. This is a good thing. The first key > > depletes entropy from /dev/random. The second key the same. The system > > needs some time to gather entropy. > I see /dev/random code an seems that extract data from mouse, keyboard, > interrupts, etc. > If mouse and keyboard do not affect to the PC, the random number is > gathered very slow (very slow). > This is a problem of enclosure (deterministic system, low precision), > and only should be solved with special device (hardware) with precision > that see the caos of real world (more liberty degree). > Nothing to be done. If you generate the keys in one process then the libgcrypt random generator will optimize things a bit, since less reads from /dev/random will be required. > Another question: > Libcrypt use exit() in functions. This looks like a bug in libgcrypt. I will forward this to the libgcrypt list. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Wed Oct 26 23:30:54 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Oct 2005 23:30:54 +0200 Subject: [Help-gnutls] Certificate verification failed In-Reply-To: <17247.59321.125197.576087@kappa.ac93.org> References: <17247.59321.125197.576087@kappa.ac93.org> Message-ID: <200510262330.54617.nmav@gnutls.org> On Wednesday 26 October 2005 22:31, Dima Barsky wrote: > Hello, > I have a small python application which uses pycurl to > download my bank statements every week. I was using > pycurl built with openssl until recently and the > application worked fine. A few days ago I upgraded the > pycurl and the libcurl packages (they are now built with GnuTLS 1.2.8) > and the application stopped working, it does not accept the bank's > certificate any more. This small script illustrates the problem: Hi, I've run this server's certificates through certtool: $ certtool -e -d 2 | ASSERT: verify.c:129 |<2>| ASSERT: verify.c:252 Verification output: Not verified, Issuer is not a CA. ^^^^^^^^^^^^ This can be solved by upgrading your libcurl. Certificate[2]: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority Issued by: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority |<1>| verify.c: HASH OID: 1.2.840.113549.2.2 |<2>| ASSERT: verify.c:447 |<2>| ASSERT: verify.c:496 |<2>| ASSERT: verify.c:568 |<2>| ASSERT: verify.c:282 Verification output: Not verified. ^^^^^^^^^^^^ This cannot be solved. This certificate uses MD2 which is not included in libgcrypt as yet. I don't know if there are plans to include it in the future though. Anyway MD2 is an old and broken algorithm and should not be used for signing certificates. -- Nikos Mavrogiannopoulos From nmav at gnutls.org Thu Oct 27 11:29:44 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 27 Oct 2005 11:29:44 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: <200510271129.44813.nmav@gnutls.org> On Thursday 27 October 2005 10:56, Simon Josefsson wrote: > > This cannot be solved. This certificate uses MD2 which is not included in > > libgcrypt as yet. I don't know if there are plans to include it in the > > future though. > We could add a MD2 implementation to gnulib, to make GnuTLS support > this when MD2 is not available through libgcrypt. I'm working on this > now. That would be nice to have. > However, I am skeptical about supporting MD2, and even MD5, by > default. I know GnuTLS certtool print a warning about MD5, but the > library does not, and most GnuTLS library users probably doesn't > either. Hmmm... about MD5 we are going to get a bunch of complaints if it is not enabled by default. But that would be the right way to do given that is not that hard to generate colliding certificates: http://www.win.tue.nl/~bdeweger/CollidingCertificates/index.html > > I think we should disable both MD2 and MD5, and introduce an API to > modify gnutls_certificate_verify_peers2, a'la > gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2) This will not be necessary if we introduce the flags below. verify_peers2 will use the flags from gnutls_certificate_set_verify_flags(). > and a new gnutls_certificate_verify_flags enumeration type, for > gnutls_x509_crt_verify calls, e.g.: > GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 > GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 Yes it is indeed a very nice idea. Security must be an issue in the library. > Cheers, > Simon -- Nikos Mavrogiannopoulos From jas at extundo.com Thu Oct 27 10:56:05 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 27 Oct 2005 10:56:05 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: <200510262330.54617.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 26 Oct 2005 23:30:54 +0200") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > This cannot be solved. This certificate uses MD2 which is not included in > libgcrypt as yet. I don't know if there are plans to include it in the future > though. We could add a MD2 implementation to gnulib, to make GnuTLS support this when MD2 is not available through libgcrypt. I'm working on this now. However, I am skeptical about supporting MD2, and even MD5, by default. I know GnuTLS certtool print a warning about MD5, but the library does not, and most GnuTLS library users probably doesn't either. I think we should disable both MD2 and MD5, and introduce an API to modify gnutls_certificate_verify_peers2, a'la gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2) and a new gnutls_certificate_verify_flags enumeration type, for gnutls_x509_crt_verify calls, e.g.: GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 All this for applications/users that want to sacrifice security for interoperability. What do you think? Cheers, Simon From jas at extundo.com Thu Oct 27 12:08:35 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 27 Oct 2005 12:08:35 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: <200510271129.44813.nmav@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 27 Oct 2005 11:29:44 +0200") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> <200510271129.44813.nmav@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: >> I think we should disable both MD2 and MD5, and introduce an API to >> modify gnutls_certificate_verify_peers2, a'la >> gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2) > This will not be necessary if we introduce the flags below. verify_peers2 > will use the flags from gnutls_certificate_set_verify_flags(). Ah, right, I forgot about that interface. Nice. >> and a new gnutls_certificate_verify_flags enumeration type, for >> gnutls_x509_crt_verify calls, e.g.: >> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 >> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 > Yes it is indeed a very nice idea. Security must be an issue in the library. Right. I think the defaults should be slightly conservative. Given that MD2 is broken, and there is even information on how to produce certificates with colliding signatures for MD5, I think we are way passed the point of being slightly conservative in disabling them. But we should have a way to re-enable them, first, to allow for interoperability. I'll take a stab at fixing this later today... Thanks, Simon From daniel at haxx.se Thu Oct 27 12:46:23 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Thu, 27 Oct 2005 12:46:23 +0200 (CEST) Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: On Thu, 27 Oct 2005, Simon Josefsson wrote: > However, I am skeptical about supporting MD2, and even MD5, by default. I > know GnuTLS certtool print a warning about MD5, but the library does not, > and most GnuTLS library users probably doesn't either. Perhaps if we got some nice pointers in the docs or something us library users could also output a warning in similar style. > I think we should disable both MD2 and MD5, and introduce an API to > modify gnutls_certificate_verify_peers2, a'la > > gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2) I would be fine with that, but as you can assume I would have to more or less unconditionally enable them for libcurl, since as you just saw: official CA certs out of our control clearly are using such algorithms. And I would assume that one or two other GnuTLS using libs/apps will be using that very same cert bundle... -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From daniel at haxx.se Thu Oct 27 12:48:04 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Thu, 27 Oct 2005 12:48:04 +0200 (CEST) Subject: [Help-gnutls] Certificate verification failed In-Reply-To: <200510262330.54617.nmav@gnutls.org> References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: On Wed, 26 Oct 2005, Nikos Mavrogiannopoulos wrote: > This cannot be solved. This certificate uses MD2 which is not included in > libgcrypt as yet. I don't know if there are plans to include it in the > future though. > > Anyway MD2 is an old and broken algorithm and should not be used for signing > certificates. Let me ask for a little clarification here that I didn't spot: Is MD2 used for the particular CA cert that was about to be used for this particular server? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From nmav at gnutls.org Thu Oct 27 13:03:33 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 27 Oct 2005 13:03:33 +0200 Subject: [Help-gnutls] Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: <200510271303.33376.nmav@gnutls.org> On Thursday 27 October 2005 12:48, Daniel Stenberg wrote: > > Anyway MD2 is an old and broken algorithm and should not be used for > > signing certificates. > Let me ask for a little clarification here that I didn't spot: > Is MD2 used for the particular CA cert that was about to be used for this > particular server? Yes. The last certificate in the chain was self signed using MD2. -- Nikos Mavrogiannopoulos From jas at extundo.com Thu Oct 27 14:40:11 2005 From: jas at extundo.com (Simon Josefsson) Date: Thu, 27 Oct 2005 14:40:11 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: (Daniel Stenberg's message of "Thu, 27 Oct 2005 12:46:23 +0200 (CEST)") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: Daniel Stenberg writes: > On Thu, 27 Oct 2005, Simon Josefsson wrote: > >> However, I am skeptical about supporting MD2, and even MD5, by >> default. I know GnuTLS certtool print a warning about MD5, but the >> library does not, and most GnuTLS library users probably doesn't >> either. > > Perhaps if we got some nice pointers in the docs or something us > library users could also output a warning in similar style. Use gnutls_x509_crt_get_signature_algorithm() on the certificates in the chain, if any of them GNUTLS_SIGN_RSA_MD5 or GNUTLS_SIGN_RSA_MD2, I think you are in potential trouble and may issue a warning. However, you are right that this problem warrant a section in the manual. I'll try to add one, and post it here for review. > I would be fine with that, but as you can assume I would have to more > or less unconditionally enable them for libcurl, since as you just > saw: official CA certs out of our control clearly are using such > algorithms. How about only enabling use of MD2/MD5 when --insecure is used? Thanks, Simon From daniel at haxx.se Fri Oct 28 10:41:33 2005 From: daniel at haxx.se (Daniel Stenberg) Date: Fri, 28 Oct 2005 10:41:33 +0200 (CEST) Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: On Thu, 27 Oct 2005, Simon Josefsson wrote: >> as you can assume I would have to more or less unconditionally enable them >> for libcurl, since as you just saw: official CA certs out of our control >> clearly are using such algorithms. > > How about only enabling use of MD2/MD5 when --insecure is used? Now we're drifting off-topic for this list, but the meaning of the existing curl option --insecure is to completetly disable serve CA cert verifying, so I can't use that... Besides, there is no --insecure option to the library libcurl (the command line option modifies two options in the library) and even if I certainly could introduce an option for this purpose, I'd hesitate to do so. Mostly because: A) libcurl users will want to be able to use publicly available CA certs such as the Debian one and thus they will want to have MD2/MD5 enabled in a very large extent (my assumption) B) OpenSSL supports MD2/MD5 out of the box and when people switch libcurl-openssl to libcurl-gnutls they want them to provide the same feature set, as closely as possible. C) OpenSSL doesn't have an option to disable these algorithms, AFAIK. My (new) ambition in libcurl is to provide an SSL-layer agnostic API that should make apps able to use libcurl identically and with the same functionality independent of what SSL-layer it has been built to use. There are many (I don't know the exact number) packages in Debian that depend on libcurl-openssl and judging from public statements, Debian aims to move them all over to libcurl-gnutls. I know all this are headaches of the libcurl project and not really concerning the GnuTLS project. I'm mainly filling in some info here to give you guys a background on why I ask all these questions and stuff. I'll shutup about this now on this list. -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol From jas at extundo.com Fri Oct 28 11:21:58 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 28 Oct 2005 11:21:58 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: (Daniel Stenberg's message of "Thu, 27 Oct 2005 12:46:23 +0200 (CEST)") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: Daniel Stenberg writes: >> I think we should disable both MD2 and MD5, and introduce an API to >> modify gnutls_certificate_verify_peers2, a'la >> >> gnutls_enable_insecure_algorithm (&session, GNUTLS_SIGN_RSA_MD2) > > I would be fine with that, but as you can assume I would have to more > or less unconditionally enable them for libcurl, since as you just > saw: official CA certs out of our control clearly are using such > algorithms. > > And I would assume that one or two other GnuTLS using libs/apps will > be using that very same cert bundle... After some discussion and more thinking, we realize that if the CA bundle include a MD2 cert, whether the MD2 algorithm is broken or not doesn't matter -- if the user trust that particular cert for verifying other certificates, the verification algorithm should let it through. The code in CVS should now work correctly. The original example in this thread, with MD2 certs, now work, see below. Please test whether tomorrow's daily build solve all the problems discussed in this thread. Thanks, Simon jas at latte:~/src/gnutls$ gnutls-cli www2.net.hsbc.com --x509cafile /usr/share/curl/curl-ca-bundle.crt Processed 59 CA certificate(s). Resolving 'www2.net.hsbc.com'... Connecting to '205.241.15.110:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: # The hostname in the certificate matches 'www2.net.hsbc.com'. # valid since: Wed May 4 02:00:00 CEST 2005 # expires at: Fri May 5 01:59:59 CEST 2006 # fingerprint: 3C:13:7F:B0:E2:E1:1A:3E:4C:8E:D0:FA:2E:20:B4:60 # Subject's DN: C=US,ST=New Jersey,L=Jersey City,O=hsbc.com\, inc.,OU=ny03www2-2005,OU=Terms of use at www.verisign.com/rpa (c)00,CN=www2.net.hsbc.com # Issuer's DN: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign - Certificate[1] info: # valid since: Thu Apr 17 02:00:00 CEST 1997 # expires at: Tue Oct 25 01:59:59 CEST 2011 # fingerprint: BC:0A:51:FA:C0:F4:7F:DC:62:1C:D8:E1:15:43:4E:CC # Subject's DN: O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign # Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - Certificate[2] info: # valid since: Mon Jan 29 01:00:00 CET 1996 # expires at: Wed Aug 2 01:59:59 CEST 2028 # fingerprint: 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67 # Subject's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority # Issuer's DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority - Peer's certificate is trusted - Version: TLS 1.0 - Key Exchange: RSA - Cipher: ARCFOUR 128 - MAC: MD5 - Compression: NULL - Handshake was completed - Simple Client Mode: jas at latte:~/src/gnutls$ From jas at extundo.com Fri Oct 28 13:40:09 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 28 Oct 2005 13:40:09 +0200 Subject: [Help-gnutls] Re: Certificate verification failed In-Reply-To: (Daniel Stenberg's message of "Fri, 28 Oct 2005 10:41:33 +0200 (CEST)") References: <17247.59321.125197.576087@kappa.ac93.org> <200510262330.54617.nmav@gnutls.org> Message-ID: Daniel Stenberg writes: > Besides, there is no --insecure option to the library libcurl (the > command line option modifies two options in the library) and even if I > certainly could introduce an option for this purpose, I'd hesitate to > do so. Mostly because: > > A) libcurl users will want to be able to use publicly available CA certs such > as the Debian one and thus they will want to have MD2/MD5 enabled in a > very large extent (my assumption) > > B) OpenSSL supports MD2/MD5 out of the box and when people switch > libcurl-openssl to libcurl-gnutls they want them to provide the same > feature set, as closely as possible. > > C) OpenSSL doesn't have an option to disable these algorithms, AFAIK. > My (new) ambition in libcurl is to provide an SSL-layer agnostic API that > should make apps able to use libcurl identically and with the same > functionality independent of what SSL-layer it has been built to use. > > There are many (I don't know the exact number) packages in Debian that > depend on libcurl-openssl and judging from public statements, Debian > aims to move them all over to libcurl-gnutls. > > I know all this are headaches of the libcurl project and not really > concerning the GnuTLS project. I'm mainly filling in some info here to > give you guys a background on why I ask all these questions and > stuff. I'll shutup about this now on this list. I suspect all GnuTLS applications have similar concerns, so I believe it is useful to have the discussion here. Given the recent changes in CVS, I don't think there will be much problems. RSA-MD2 is supported, so the initial problem with www2.net.hsbc.com should be fixed. The only modification that may have negative interoperability impact is if there are intermediary CAs that use RSA-MD2/MD5. In the www2.net.hsbc.com example, the chain was RSA-MD2 -> RSA-SHA1 -> RSA-SHA1 so it would verify correctly. If the chain was ?->RSA-MD?->? there would be a problem, such a chain would not verify in the new version. In the old version, ?->RSA-MD5->? would verify correctly, but ?->RSA-MD2->? would not (because RSA-MD2 wasn't supported). I'm not sure how many real-world chains look like ?->RSA-MD5->?. Sampling that would be interesting. If I understand correctly, all the information needed to produce colliding RSA-MD5 X.509 certificates are publicly available. It supposedly only takes hours to do create these certificates. I don't think users should be tricked into feeling secure if RSA-MD5 is used within a chain. In any case, the hook to re-enable RSA-MD2 and RSA-MD5 are present, so I think GnuTLS can meet everybody's needs. Thanks, Simon From jas at extundo.com Fri Oct 28 16:04:32 2005 From: jas at extundo.com (Simon Josefsson) Date: Fri, 28 Oct 2005 16:04:32 +0200 Subject: [Help-gnutls] 1.2.9 release candidate Message-ID: Hi all. There has been larger changes than usual in CVS, so I thought I'd roll a release candidate before releasing 1.2.9. I'll release this during the next week if there are no problems. Please test: http://josefsson.org/daily/gnutls/gnutls-20051028.tar.gz In particular, I want to know how this works on minw32, and whether the MD2/MD5 stuff works. Note: Don't use --with-builtin-crypto, it doesn't implement HMAC yet, so it doesn't even pass the self tests. Hopefully, I'll fix this before the release. I have tested this successfully on alphaev67-unknown-linux-gnu, i686-pc-linux-gnu, sparc-sun-solaris2.9, i386-unknown-freebsd4.11, and i386-pc-solaris2.9. NEWS entries below. Suggestions on the text is also appreciated. Thanks, Simon - Documentation was updated and improved. - MD2 is now supported. - Due to cryptographic advances, verifying untrusted X.509 certificates signed with RSA-MD2 or RSA-MD5 will now fail with a GNUTLS_CERT_INSECURE_ALGORITHM verification output. For applications that must remain interoperable, you can use the GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 or GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 flags when verifying certificates. Naturally, this is not recommended to be the default behaviour. For example, call gnutls_certificate_set_verify_flags with these flags to change the verification mode used by gnutls_certificate_verify_peers2. - Make it possible to send empty data through gnutls_record_send, to align with the send(2) API. - The (experimental) low-level crypto alternative to libgcrypt used earlier (Nettle) has been replaced with crypto code from gnulib. This leads to easier re-use of these components in other projects, leading to more review and simpler maintenance. The new configure parameter --with-builtin-crypto replace the old --with-nettle, and must be used if you wish to enable this functionality. See README under "Experimental" for more information. Internally, GnuTLS has been updated to use the new "Generic Crypto" API in gl/gc.h. The API is similar to the old crypto/gc.h, because the gnulib code were based on GnuTLS's gc.h. - Fix compiler warning in the "anonself" self test. - API and ABI modifications: gnutls_x509_crt_list_verify: Added 'const' to prototype in . This doesn't reflect a change in behaviour, so we don't break backwards compatibility. GNUTLS_MAC_MD2: New gnutls_mac_algorithm_t value. GNUTLS_DIG_MD2: New gnutls_digest_algorithm_t value. GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2, GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values. Use when calling gnutls_x509_crt_list_verify, gnutls_x509_crt_verify, or gnutls_certificate_set_verify_flags. GNUTLS_CERT_INSECURE_ALGORITHM: New gnutls_certificate_status_t value, used when broken signature algorithms is used (currently RSA-MD2/MD5). From e_agf at yahoo.es Sat Oct 29 00:08:41 2005 From: e_agf at yahoo.es (Fran) Date: Sat, 29 Oct 2005 00:08:41 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <200510262315.32909.nmav@gnutls.org> References: <1130276398.5010.4.camel@localhost> <200510261109.36886.nmav@gnutls.org> <1130359888.4565.17.camel@localhost> <200510262315.32909.nmav@gnutls.org> Message-ID: <1130537322.4032.35.camel@localhost> On M?r, 2005-10-26 at 23:15 +0200, Nikos Mavrogiannopoulos wrote: > If you generate the keys in one process then the libgcrypt random generator > will optimize things a bit, since less reads from /dev/random will be > required. ...If this can help anyone: I find alternatives but seems do not work very well for me: Via*, AMD, Intel (i81x) and other processor have RNG . *Last Via processor have cryto device supported by linux. Using noise of devices that use DAC converter audio sound card, video card. Open the wallet and buy a hardware RNG :) Other that I do not known. The problem is that the device used is different that /dev/ramdom, and libcrypt seems to use /dev/ramdom (very bad thing). In some cases char device is in /dev/hw_random, /dev/? depend of kernel version and hardware. I think that RNG char device should be set as user wants. For example, for me at this moment should be a good choice set GLOBAL RNG to /dev/hw_random (intel i810) that work more that /dev/random. This can be solved in BRUTE MODE making this: rm /dev/ramdom ln -s /dev/hw_random /dev/random Set permissions read user, group and others. I do not know security problems making this. With default only root can read from /dev/hw_random. > > Another question: > > Libcrypt use exit() in functions. > This looks like a bug in libgcrypt. > I will forward this to the libgcrypt list. OK, But seems to be bad module design (not bug) on libcrypt that hits in GNUTLS functions. From nmav at gnutls.org Sat Oct 29 10:17:14 2005 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 29 Oct 2005 10:17:14 +0200 Subject: [Help-gnutls] Why delay generating second and other keys? In-Reply-To: <1130537322.4032.35.camel@localhost> References: <1130276398.5010.4.camel@localhost> <200510262315.32909.nmav@gnutls.org> <1130537322.4032.35.camel@localhost> Message-ID: <200510291017.14500.nmav@gnutls.org> On Saturday 29 October 2005 00:08, Fran wrote: > The problem is that the device used is different that /dev/ramdom, and > libcrypt seems to use /dev/ramdom (very bad thing). > In some cases char device is in /dev/hw_random, /dev/? depend of > kernel version and hardware. > I think that RNG char device should be set as user wants. For example, > for me at this moment should be a good choice set GLOBAL RNG > to /dev/hw_random (intel i810) that work more that /dev/random. Check the debian rng-tools. They feed the hardware random data to the kernel random pool. http://packages.debian.org/unstable/utils/rng-tools Otherwise I think you can specify the device that libgcrypt will use at compile time (of libgcrypt). -- Nikos Mavrogiannopoulos