From nhrdls at gmail.com Mon Mar 2 20:30:29 2015 From: nhrdls at gmail.com (Niranjan Rao) Date: Mon, 02 Mar 2015 11:30:29 -0800 Subject: [gnutls-help] Connection failing to a site In-Reply-To: <1425108662.2087.0.camel@gnutls.org> References: <54F0D6E2.5040005@gmail.com> <1425108662.2087.0.camel@gnutls.org> Message-ID: <54F4BA55.3040802@gmail.com> Thank you Nikos, I did upgrade to latest stable and problem is now resolved. Regards, Niranjan On 02/27/2015 11:31 PM, Nikos Mavrogiannopoulos wrote: > On Fri, 2015-02-27 at 12:43 -0800, Niranjan Rao wrote: >> Greetings, >> >> On Ubuntu 12.04. >> >> When trying to connect to site www.uasecho.com using webkit, I get error >> SSL handshake failed. I tried running gnutls-cli and get following output. >> >> gnutls-cli -V www.uasecho.com >> Resolving 'www.uasecho.com'... >> Connecting to '198.27.57.107:443'... >> *** Fatal error: A TLS packet with unexpected length was received. >> *** Handshake has failed >> GnuTLS error: A TLS packet with unexpected length was received. > There is something with the server. It works if you disable TLS 1.2. > However, the best it to use a supported version of gnutls: > http://www.gnutls.org/download.html > > regards, > Nikos > > From attilamolnar at hush.com Tue Mar 3 23:48:14 2015 From: attilamolnar at hush.com (Attila Molnar) Date: Tue, 03 Mar 2015 23:48:14 +0100 Subject: [gnutls-help] gnutls_record_send() behavior while corked Message-ID: <20150303224814.529DAC043B@smtp.hushmail.com> Hello everyone, I'd like to use the corking functionality introduced in 3.1, but there is something I don't fully understand. The docs for gnutls_record_send() say that when corked "All queued records will be sent when gnutls_uncork() is called or when the maximum record size is reached.". While testing I found that even if I give it more data than the record size via multiple gnutls_record_send() calls, it accepts all of it and does no output until gnutls_record_uncork() is called which then sends multiple records. gnutls_record_send() always returned a number equal to the number of bytes given to it as data_size. The latter half of the quote from the manual implies that gnutls_record_send() can send records and thus call the push function while corked. Which one is it? Is it correct to assume that while corked, gnutls_record_send() simply copies the data into an internal buffer and the gnutls_record_uncork() function does something equivalent to what gnutls_record_send() does when not corked, but operates on all of the data given to it earlier? Regards, Attila From nmav at gnutls.org Wed Mar 4 07:55:05 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Mar 2015 07:55:05 +0100 Subject: [gnutls-help] gnutls_record_send() behavior while corked In-Reply-To: <20150303224814.529DAC043B@smtp.hushmail.com> References: <20150303224814.529DAC043B@smtp.hushmail.com> Message-ID: On Tue, Mar 3, 2015 at 11:48 PM, Attila Molnar wrote: > Hello everyone, > I'd like to use the corking functionality introduced in 3.1, > but there is something I don't fully understand. > The docs for gnutls_record_send() say that when corked > "All queued records will be sent when gnutls_uncork() is called > or when the maximum record size is reached.". Thanks for bringing that up. The behavior is the one that you noticed, but the docs were wrong. They were corrected in: https://gitorious.org/gnutls/gnutls/commit/f38fe7744d6ff7560c3ee67e3bd35b301734385a but for some reasons that wasn't propagated to the documentation generated for the web site. I'll have to check why is that. > Which one is it? Is it correct to assume that while corked, > gnutls_record_send() simply copies the data into an internal > buffer and the gnutls_record_uncork() function does something > equivalent to what gnutls_record_send() does when not corked, > but operates on all of the data given to it earlier? Correct. regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Mar 4 09:23:47 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 4 Mar 2015 09:23:47 +0100 Subject: [gnutls-help] moving to gitlab Message-ID: It seems that gitorious is bought by gitlab, and is closing down soon. For that I've started migrating the project to: https://gitlab.com/gnutls/gnutls That's an actual improvement as I was unhappy with the features in gitorious. Moreover, we can now integrate the issue tracker to that interface, and possibly the web site as well. If you're pulling from git please update your config to point to: git at gitlab.com:gnutls/gnutls.git or https://gitlab.com/gnutls/gnutls.git regards, Nikos From priyaranjan4169 at gmail.com Wed Mar 4 11:58:26 2015 From: priyaranjan4169 at gmail.com (Priyaranjan Nayak) Date: Wed, 4 Mar 2015 16:28:26 +0530 Subject: [gnutls-help] Handshake failing by using gnutls library Message-ID: Hi, I am using gnutls-3.3.13 version for tls communication. I have created three files by using below commands 1. certtool --generate-privkey --outfile key.pem 2. certtool --generate-self-signed --load-privkey key.pem --outfile cert.pem 3. certtool --generate-crl --load-ca-privkey key.pem --load-ca-certificate cert.pem --outfile crl.pem Now handshake is failing with "*** Handshake has failed (The request is invalid.)" message . Please suggest me how to do handshake properly and if anything wrong in the .pem file generation . Thanks Priyaranjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Wed Mar 4 16:53:24 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 04 Mar 2015 10:53:24 -0500 Subject: [gnutls-help] Alternative to GNUTLS_FORCE_FIPS_MODE ? Message-ID: Hello, As an alternative to having GNUTLS_FORCE_FIPS_MODE=1, would it be possible to observe: /proc/sys/crypto/fips_enabled Which is set when the kernel runs in FIPS mode. Regards. From nmav at gnutls.org Wed Mar 4 18:11:30 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 04 Mar 2015 18:11:30 +0100 Subject: [gnutls-help] Alternative to GNUTLS_FORCE_FIPS_MODE ? In-Reply-To: References: Message-ID: <1425489090.9601.3.camel@gnutls.org> On Wed, 2015-03-04 at 10:53 -0500, jonetsu wrote: > Hello, > > As an alternative to having GNUTLS_FORCE_FIPS_MODE=1, would it be possible to observe: > /proc/sys/crypto/fips_enabled > Which is set when the kernel runs in FIPS mode. Currently the support for FIPS is tied to RHEL because this is the system it was developed and tested on. For that it checks "/proc/sys/crypto/fips_enabled" and "/etc/system-fips" being present. If on other systems support for FIPS it is different, or things can be made more generic I'd appreciate a patch. regards, Nikos From attilamolnar at hush.com Wed Mar 4 19:09:29 2015 From: attilamolnar at hush.com (Attila Molnar) Date: Wed, 04 Mar 2015 19:09:29 +0100 Subject: [gnutls-help] gnutls_record_send() behavior while corked In-Reply-To: References: <20150303224814.529DAC043B@smtp.hushmail.com> Message-ID: <20150304180929.CD8D9C043C@smtp.hushmail.com> On 2015. 03. 04. at 7:55 AM, "Nikos Mavrogiannopoulos" wrote: > >On Tue, Mar 3, 2015 at 11:48 PM, Attila Molnar > wrote: >> Hello everyone, >> I'd like to use the corking functionality introduced in 3.1, >> but there is something I don't fully understand. >> The docs for gnutls_record_send() say that when corked >> "All queued records will be sent when gnutls_uncork() is called >> or when the maximum record size is reached.". > >Thanks for bringing that up. The behavior is the one that you >noticed, >but the docs were wrong. They were corrected in: >https://gitorious.org/gnutls/gnutls/commit/f38fe7744d6ff7560c3ee67e >3bd35b301734385a >but for some reasons that wasn't propagated to the documentation >generated for the web site. I'll have to check why is that. > >> Which one is it? Is it correct to assume that while corked, >> gnutls_record_send() simply copies the data into an internal >> buffer and the gnutls_record_uncork() function does something >> equivalent to what gnutls_record_send() does when not corked, >> but operates on all of the data given to it earlier? > >Correct. Thanks for the clarification. I assume when corked the return value of gnutls_record_send() can still be an error, for example out of memory. A situation can occur when gnutls_record_uncork() cannot send some of the data, returns with GNUTLS_E_AGAIN, and next time when the socket becomes writable the application has no new data to send, but wants to flush the buffers. To do this my first idea is to cork and then uncork without calling gnutls_record_send(). Is this the best way? Regards, Attila From n.mavrogiannopoulos at gmail.com Fri Mar 6 11:29:24 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 6 Mar 2015 11:29:24 +0100 Subject: [gnutls-help] GnuTLS + FREAK Message-ID: There was a new attack against few SSL/TLS implementations called FREAK [0]. This attack relies on being able to modify the client's state machine and switch it from RSA to RSA-EXPORT. Such an attack is not possible in the way the GnuTLS' state machine operates, and moreover modern versions of GnuTLS don't support RSA-EXPORT. Support for EXPORT ciphersuites was removed back in 2013 [1]. So as it is now, this attack doesn't affect GnuTLS clients or servers. regards, Nikos [0]. https://freakattack.com/ [1]. https://gitlab.com/gnutls/gnutls/blob/master/NEWS#L768 From priyaranjan4169 at gmail.com Sat Mar 7 10:56:15 2015 From: priyaranjan4169 at gmail.com (Priyaranjan Nayak) Date: Sat, 7 Mar 2015 15:26:15 +0530 Subject: [gnutls-help] Handshake failure for X509 authentication for gnutls Message-ID: Hi I am using X509 authentication for server and client which is available in public domain for gnutls document. In server I am getting handshake failure with "*** Handshake has failed (The request is invalid.)" and client is failing to do handshake too.Please suggest me what could be the reason for handshake failure . Thanks in advance. Thanks Priyaranjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sat Mar 7 20:08:09 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 07 Mar 2015 11:08:09 -0800 Subject: [gnutls-help] Handshake failing by using gnutls library In-Reply-To: References: Message-ID: <87egp0k4me.fsf@alice.fifthhorseman.net> On Wed 2015-03-04 02:58:26 -0800, Priyaranjan Nayak wrote: > I am using gnutls-3.3.13 version for tls communication. I have created > three files by using below commands > 1. certtool --generate-privkey --outfile key.pem > 2. certtool --generate-self-signed --load-privkey key.pem --outfile cert.pem > 3. certtool --generate-crl --load-ca-privkey key.pem --load-ca-certificate cert.pem --outfile crl.pem The above commands have to do with key generation. Without more information about the choices made during step 2, it's hard to tell if it even makes sense to generate a CRL, though. CRLs are only sensible if the certificate is intended to certify other certificates. Is that the case? > Now handshake is failing with "*** Handshake has failed (The request is > invalid.)" message . Please suggest me how to do handshake properly and if > anything wrong in the .pem file generation . There isn't enough information here to help you, i think. how are you trying to connect? are you using GnuTLS for both sides of the connection (client and server)? if not, what is providing TLS support on the side that gnutls isn't handling? The more specific you can be about how GnuTLS is being used, the better we'll be able to help you figure out what's going wrong. It seems unlikely to be related just to the certtool steps you laid out above. --dkg From priyaranjan4169 at gmail.com Mon Mar 9 05:49:01 2015 From: priyaranjan4169 at gmail.com (Priyaranjan Nayak) Date: Mon, 9 Mar 2015 10:19:01 +0530 Subject: [gnutls-help] Handshake failing by using gnutls library In-Reply-To: <87egp0k4me.fsf@alice.fifthhorseman.net> References: <87egp0k4me.fsf@alice.fifthhorseman.net> Message-ID: Hi Daniel, I have installed gnutls-3.3.13 version and using in both server and client side program. Now I wanted to check which API needs to be call to complete the handshake for TLS connection.So I am using two sample program given by gnutls library to verify the handshake procedure .i.e 1. Server sample code: http://gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication 2. Client sample code: http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support Thanks Daniel for your great support. On Sun, Mar 8, 2015 at 12:38 AM, Daniel Kahn Gillmor wrote: > On Wed 2015-03-04 02:58:26 -0800, Priyaranjan Nayak wrote: > > > I am using gnutls-3.3.13 version for tls communication. I have created > > three files by using below commands > > 1. certtool --generate-privkey --outfile key.pem > > 2. certtool --generate-self-signed --load-privkey key.pem --outfile > cert.pem > > 3. certtool --generate-crl --load-ca-privkey key.pem > --load-ca-certificate cert.pem --outfile crl.pem > > The above commands have to do with key generation. Without more > information about the choices made during step 2, it's hard to tell if > it even makes sense to generate a CRL, though. CRLs are only sensible > if the certificate is intended to certify other certificates. Is that > the case? > > > Now handshake is failing with "*** Handshake has failed (The request is > > invalid.)" message . Please suggest me how to do handshake properly and > if > > anything wrong in the .pem file generation . > > There isn't enough information here to help you, i think. how are you > trying to connect? are you using GnuTLS for both sides of the > connection (client and server)? if not, what is providing TLS support > on the side that gnutls isn't handling? The more specific you can be > about how GnuTLS is being used, the better we'll be able to help you > figure out what's going wrong. It seems unlikely to be related just to > the certtool steps you laid out above. > > --dkg > -- Thanks Priyaranjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tquemerais at awox.com Mon Mar 9 12:22:55 2015 From: tquemerais at awox.com (Thierry Quemerais) Date: Mon, 9 Mar 2015 12:22:55 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data Message-ID: Hi all, I'm working on GNUTLS library in order to had some customs/proprietary extension/supplemental data. My goal is to not modify GNUTLS at all and to instead handle my specific extensions/supplemental data out of GNUTLS. According to my understanding, GNUTLS support it BUT it need to change code inside GNUTLS. I found all what I need: 1) To add my supplemental data callback : gnutls_supplemental_entry _gnutls_supplemental[] = { {0, 0, 0, 0} }; 2) To add my extensions -------------- next part -------------- An HTML attachment was scrubbed... URL: From tquemerais at awox.com Mon Mar 9 12:30:59 2015 From: tquemerais at awox.com (Thierry Quemerais) Date: Mon, 9 Mar 2015 12:30:59 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data Message-ID: Hi all, I'm working on GNUTLS library in order to add some customs/proprietary extensions/supplemental data. My goal is to not modify GNUTLS source code and to handle my specifics extensions/supplemental data out of GNUTLS instead. According to my understanding, GNUTLS support it BUT it need to change code inside GNUTLS. I found all what I need: 1) To add my supplemental data callback : gnutls_supplemental_entry _gnutls_supplemental[] = { {0, 0, 0, 0} }; 2) To add my extensions extension_entry_st ext_mod_dtcp_server = { .name = "NAME", .type = 7, .parse_type = GNUTLS_EXT_TLS, .recv_func = callback, .send_func = callback, .pack_func = NULL, .unpack_func = NULL, .deinit_func = NULL, }; _gnutls_ext_register(&ext_mod_dtcp_client); My questions are: 1) Is there any way to register extensions and supplemental data callback out of GNUTLS (With public API). I found no way to do it without changing GNUTLS source code, does I missed something ? 2) If no, I plan to make this work and to re-distribute it and I would like to know why (if there is any reason like security) this work have not been done ? Why no public API is available to add and handle customs extensions/supplemental data ? Thank you, Regards, Thierry. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Mar 9 19:05:06 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 09 Mar 2015 19:05:06 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data In-Reply-To: References: Message-ID: <1425924306.2022.20.camel@gnutls.org> On Mon, 2015-03-09 at 12:30 +0100, Thierry Quemerais wrote: > Hi all, > 1) Is there any way to register extensions and supplemental data > callback out of GNUTLS (With public API). I found no way to do it > without changing GNUTLS source code, does I missed something ? > 2) If no, I plan to make this work and to re-distribute it and I > would like to know why (if there is any reason like security) this > work have not been done ? > Why no public API is available to add and handle customs > extensions/supplemental data ? Hi, In a re-organization of the code the exported functions were removed because they would have to depend on an internal API. The reason was that I had no time to implement an API which would allow to register extensions in a way that it would not depend on internal functionality. Said that, if you sent a patch with a clean API which doesn't depend on internals (*), to register extensions and supplemental data, I'll include it. regards, Nikos (*) or export the minimum necessary so we can rewrite the code without changing the API From jonetsu at teksavvy.com Tue Mar 10 12:54:41 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 10 Mar 2015 07:54:41 -0400 Subject: [gnutls-help] Listing all usable algos. Message-ID: <0a9fe6836c6bf8b0a72ae68c7847c67c@teksavvy.com> Hello, ? Is there a way to list at runtime all algorithms and ciphers that GnuTLS can be using ?? The gnutls-cli help does not seem to show such functionality.? Is there ?? Regards. From rich at kde.org Tue Mar 10 13:12:26 2015 From: rich at kde.org (Richard Moore) Date: Tue, 10 Mar 2015 12:12:26 +0000 Subject: [gnutls-help] Listing all usable algos. In-Reply-To: <0a9fe6836c6bf8b0a72ae68c7847c67c@teksavvy.com> References: <0a9fe6836c6bf8b0a72ae68c7847c67c@teksavvy.com> Message-ID: On 10 March 2015 at 11:54, jonetsu wrote: > Is there a way to list at runtime all algorithms and ciphers that GnuTLS > can be using ? The gnutls-cli help does not seem to show such > functionality. Is there ? > gnutls-cli -l Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Tue Mar 10 14:13:32 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 10 Mar 2015 09:13:32 -0400 Subject: [gnutls-help] Listing all usable algos. In-Reply-To: References: <0a9fe6836c6bf8b0a72ae68c7847c67c@teksavvy.com> Message-ID: <60012d4b21a96a22350b8d0954b8f21a@teksavvy.com> > gnutls-cli -i Darn !? It was there in the help text.? One of those mornings :) Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Tue Mar 10 19:09:47 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 10 Mar 2015 14:09:47 -0400 Subject: [gnutls-help] FIPS ciphers list is wrong Message-ID: Hello, ? The list of ciphers provided by 'gnutls-cli -l' is the same in FIPS mode or not.? The test: /usr/local/bin/gnutls-cli -v??????????? gnutls-cli 3.3.13 1) /usr/local/bin/gnutls-cli --fips140-mode library is NOT in FIPS140-2 mode /usr/local/bin/gnutls-cli -l?????????? (nonfips list generated) 2) export GNUTLS_FORCE_FIPS_MODE=1 /usr/local/bin/gnutls-cli --fips140-mode library is in FIPS140-2 mode /usr/local/bin/gnutls-cli -l?????????? (fips list generated) Many ciphers listed in FIPS mode should not be there. Regards. From nmav at gnutls.org Wed Mar 11 16:27:55 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 11 Mar 2015 16:27:55 +0100 Subject: [gnutls-help] FIPS ciphers list is wrong In-Reply-To: References: Message-ID: On Tue, Mar 10, 2015 at 7:09 PM, jonetsu wrote: > Hello, > The list of ciphers provided by 'gnutls-cli -l' is the same in FIPS mode or not. The test: > /usr/local/bin/gnutls-cli -v > gnutls-cli 3.3.13 gnutls-cli -l prints all the algorithms compiled in the library. To see the algorithms supported in FIPS mode you should use -l with the priority string you are interested in: e.g.: GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL ./gnutls-cli -l --priority NORMAL regards, Nikos From jonetsu at teksavvy.com Wed Mar 11 18:27:46 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 11 Mar 2015 13:27:46 -0400 Subject: [gnutls-help] FIPS ciphers list is wrong In-Reply-To: References: Message-ID: <4a2e0e59fd3f0c76f7cae41457415620@teksavvy.com> > From: "Nikos Mavrogiannopoulos" > Date: 03/11/15 11:27 > GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL > ./gnutls-cli -l --priority NORMAL Thanks.? In the resulting list many TLS1.0 are found: (abridged list) ?TLS_ECDHE_ECDSA_AES_128_CBC_SHA256?????? TLS1.0 ?TLS_ECDHE_ECDSA_AES_256_CBC_SHA384?????? TLS1.0 ?TLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256? TLS1.0 ?TLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384? TLS1.0 ?TLS_ECDHE_RSA_AES_128_CBC_SHA256???????? TLS1.0 ?[...] However, NIST Special Publication 800-52 Revision 1 specifies that no TLS1.0 should be used. Please see '3.1 Protocol Version Support' in: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf Regards. From mattroisang at gmail.com Thu Mar 12 00:09:11 2015 From: mattroisang at gmail.com (Mat Troi) Date: Wed, 11 Mar 2015 16:09:11 -0700 Subject: [gnutls-help] GnuTLS selftest pem2 error: Message-ID: I am trying to run the selftest, and it fails at pem2. Test output: Testing pem2... Hostname correctly does not match (0) subject `CN=#130f7777772e6578616d706c652e6f7267', issuer `CN=#130f7777772e6578616d706c652e6f7267', RSA key 1024 bits, signed using RSA-SHA, activated `2007-02-16 13:30:30 UTC', expires `2007-03-30 13:30:32 UTC', SHA-1 fingerprint `39e3f8fec6a8d842390b6536998a957c1a6b7322' return is 0 Hostname incorrectly does not match (0) The code is: "X.509 Certificate Information:\n" " Version: 3\n" " Serial Number (hex): 00\n" " Issuer: CN=www.example.org\n" " Validity:\n" " Not Before: Fri Feb 16 13:30:30 UTC 2007\n" " Not After: Fri Mar 30 13:30:32 UTC 2007\n" " Subject: CN=www.example.org\n" ... ... ret = gnutls_x509_crt_check_hostname (cert, "www.example.org\n"); printf ("return is %d\n", ret); if (ret) success ("Hostname correctly matches (%d)\n", ret); else fail ("Hostname incorrectly does not match (%d)\n", ret); I don't understand why is the hostname not matching. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Mar 12 07:19:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 12 Mar 2015 07:19:47 +0100 Subject: [gnutls-help] FIPS ciphers list is wrong In-Reply-To: <4a2e0e59fd3f0c76f7cae41457415620@teksavvy.com> References: <4a2e0e59fd3f0c76f7cae41457415620@teksavvy.com> Message-ID: <1426141187.1678.2.camel@gnutls.org> On Wed, 2015-03-11 at 13:27 -0400, jonetsu wrote: > > From: "Nikos Mavrogiannopoulos" > > Date: 03/11/15 11:27 > > GNUTLS_FORCE_FIPS_MODE=1 ./gnutls-cli -l --priority NORMAL > > ./gnutls-cli -l --priority NORMAL > Thanks. In the resulting list many TLS1.0 are found: > > (abridged list) > > TLS_ECDHE_ECDSA_AES_128_CBC_SHA256 TLS1.0 > TLS_ECDHE_ECDSA_AES_256_CBC_SHA384 TLS1.0 > TLS_ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 TLS1.0 > TLS_ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 TLS1.0 > TLS_ECDHE_RSA_AES_128_CBC_SHA256 TLS1.0 > [...] > However, NIST Special Publication 800-52 Revision 1 specifies > that no TLS1.0 should be used. > Please see '3.1 Protocol Version Support' in: > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf That's correct, but I don't think that SP800-52 is a requirement in FIPS140-2. Do you have such a reference? regards, Nikos From jonetsu at teksavvy.com Thu Mar 12 14:29:23 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Thu, 12 Mar 2015 09:29:23 -0400 Subject: [gnutls-help] FIPS ciphers list is wrong In-Reply-To: <1426141187.1678.2.camel@gnutls.org> References: <4a2e0e59fd3f0c76f7cae41457415620@teksavvy.com> <1426141187.1678.2.camel@gnutls.org> Message-ID: > From: "Nikos Mavrogiannopoulos" > Date: 03/12/15 02:19 > That's correct, but I don't think that SP800-52 is a requirement in > FIPS140-2. Do you have such a reference? Yes, that's right.? Everything points to not having TLS1.0 in the (near) future btu at the moment it is allowed in 140-2. Regards. From dkg at fifthhorseman.net Thu Mar 12 19:34:55 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 12 Mar 2015 14:34:55 -0400 Subject: [gnutls-help] Handshake failing by using gnutls library In-Reply-To: References: <87egp0k4me.fsf@alice.fifthhorseman.net> Message-ID: <8761a66p4g.fsf@alice.fifthhorseman.net> On Mon 2015-03-09 00:49:01 -0400, Priyaranjan Nayak wrote: > I have installed gnutls-3.3.13 version and using in both server and client > side program. Now I wanted to check which API needs to be call to complete > the handshake for TLS connection.So I am using two sample program given by > gnutls library to verify the handshake procedure .i.e > > 1. Server sample code: > http://gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication > 2. Client sample code: > http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support And in which of these programs is the failure happening in? at which line of the program? --dkg From priyaranjan4169 at gmail.com Fri Mar 13 04:40:18 2015 From: priyaranjan4169 at gmail.com (Priyaranjan Nayak) Date: Fri, 13 Mar 2015 09:10:18 +0530 Subject: [gnutls-help] Handshake failing by using gnutls library In-Reply-To: <8761a66p4g.fsf@alice.fifthhorseman.net> References: <87egp0k4me.fsf@alice.fifthhorseman.net> <8761a66p4g.fsf@alice.fifthhorseman.net> Message-ID: Hi Daniel, It is failing in the below line of the sample code . ret = gnutls_handshake(session); I am getting "*** Handshake has failed (The request is invalid.)" message from server side sample code. and "*** Fatal error: The TLS connection was non-properly terminated" error message from client side sample code. On Fri, Mar 13, 2015 at 12:04 AM, Daniel Kahn Gillmor wrote: > On Mon 2015-03-09 00:49:01 -0400, Priyaranjan Nayak wrote: > > I have installed gnutls-3.3.13 version and using in both server and > client > > side program. Now I wanted to check which API needs to be call to > complete > > the handshake for TLS connection.So I am using two sample program given > by > > gnutls library to verify the handshake procedure .i.e > > > > 1. Server sample code: > > > http://gnutls.org/manual/html_node/Echo-server-with-X_002e509-authentication.html#Echo-server-with-X_002e509-authentication > > 2. Client sample code: > > > http://www.gnutls.org/manual/html_node/Simple-client-example-with-X_002e509-certificate-support.html#Simple-client-example-with-X_002e509-certificate-support > > And in which of these programs is the failure happening in? at which > line of the program? > > --dkg > -- Thanks Priyaranjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tquemerais at awox.com Fri Mar 13 14:53:03 2015 From: tquemerais at awox.com (Thierry Quemerais) Date: Fri, 13 Mar 2015 14:53:03 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data In-Reply-To: <1425924306.2022.20.camel@gnutls.org> References: <1425924306.2022.20.camel@gnutls.org> Message-ID: Hi Nikos, Thank you for your reply. Please find attached to this Email, the patch I made to achieve my goal. For your information, I also found an issue in GNUTLS which does not handle supplemental data type > 255. This fix is included in this patch: - buf->data[sizepos] = 0; - buf->data[sizepos + 1] = p->type; + buf->data[sizepos] = (p->type >> 8) & 0xFF; + buf->data[sizepos + 1] = (p->type) & 0xFF; This patch do different things: 1) It allow to add extensions support from public API: gnutls_ext_register 2) It allow to add supplemental data support from public API: gnutls_supplemental_register To achieve my goal : I changed the way supplemental callback are stored. (gnutls_supplemental.c) I moved extension en supplemental structure to gnutls.h header. (gnutls_supplemental_entry, extension_entry_st) I created an opaque struct for strings (typedef struct gnutls_buffer gnutls_buffer_st;) and I added a function to append data in this buffer (Used by extension/supplemental callbacks). Feel free to contact me if you have any question or if something doesn't look like your expectations. Regards, Thierry. -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Monday, March 09, 2015 7:05 PM To: Thierry Quemerais Cc: gnutls-help at lists.gnutls.org Subject: Re: [gnutls-help] GNU TLS and extensions/supplemental data On Mon, 2015-03-09 at 12:30 +0100, Thierry Quemerais wrote: > Hi all, > 1) Is there any way to register extensions and supplemental data > callback out of GNUTLS (With public API). I found no way to do it > without changing GNUTLS source code, does I missed something ? > 2) If no, I plan to make this work and to re-distribute it and I > would like to know why (if there is any reason like security) this > work have not been done ? > Why no public API is available to add and handle customs > extensions/supplemental data ? Hi, In a re-organization of the code the exported functions were removed because they would have to depend on an internal API. The reason was that I had no time to implement an API which would allow to register extensions in a way that it would not depend on internal functionality. Said that, if you sent a patch with a clean API which doesn't depend on internals (*), to register extensions and supplemental data, I'll include it. regards, Nikos (*) or export the minimum necessary so we can rewrite the code without changing the API -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_ext_supp_public.diff Type: application/octet-stream Size: 15588 bytes Desc: gnutls_ext_supp_public.diff URL: From nmav at gnutls.org Fri Mar 13 16:44:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 13 Mar 2015 16:44:39 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data In-Reply-To: References: <1425924306.2022.20.camel@gnutls.org> Message-ID: On Fri, Mar 13, 2015 at 2:53 PM, Thierry Quemerais wrote: > Hi Nikos, > > Thank you for your reply. > > Please find attached to this Email, the patch I made to achieve my goal. > For your information, I also found an issue in GNUTLS which does not handle supplemental data type > 255. > This fix is included in this patch: > - buf->data[sizepos] = 0; > - buf->data[sizepos + 1] = p->type; > + buf->data[sizepos] = (p->type >> 8) & 0xFF; > + buf->data[sizepos + 1] = (p->type) & 0xFF; Applied separately. > To achieve my goal : > I changed the way supplemental callback are stored. (gnutls_supplemental.c) > I moved extension en supplemental structure to gnutls.h header. (gnutls_supplemental_entry, extension_entry_st) > I created an opaque struct for strings (typedef struct gnutls_buffer gnutls_buffer_st;) and I added a function to append data in this buffer (Used by extension/supplemental callbacks). Thank you. I like the patch, it is pretty simple and straightforward. My main objection is the export of gnutls_ext_register structure, which will require ABI break in case we add anything there. Why not keep _gnutls_ext_register() as is, and then export a gnutls_ext_register() which receives everything needed in the current structure as parameters? The same for gnutls_supplemental_entry... The risk of this structure changing is lower, but better safe than sorry. Some more, but minor comments. * Would it be possible to submit the a patch from git, and use the --signoff flag (as well as send the DCO - see http://www.gnutls.org/devel.html) * It would be convenient for debugging to split the patch into two, one for the extensions and on for the supplemental * In extension_entry_st you use "short type". I think simply using an int or unsigned int would be better. * Do you have some small test programs to use in our test suite for this API? That would ensure that the API you add now remains unbroken over releases. regards, Nikos From alanp at snowmoose.com Sun Mar 15 03:19:59 2015 From: alanp at snowmoose.com (Alan Perry) Date: Sat, 14 Mar 2015 19:19:59 -0700 Subject: [gnutls-help] GnuTLS and Nettle In-Reply-To: <1424296017.3853.3.camel@gnutls.org> References: <54E4DA6C.50701@snowmoose.com> <1424296017.3853.3.camel@gnutls.org> Message-ID: <5504EC4F.6070707@snowmoose.com> On 2/18/15 1:46 PM, Nikos Mavrogiannopoulos wrote: > On Wed, 2015-02-18 at 10:31 -0800, Alan Perry wrote: >> Hi, >> >> I have heard that GnuTLS will be using Nettle 3.x in the future. Any >> idea when might this happen? > My plan is to release gnutls 3.4.0 once nettle 3.1 is out, and it will > depend on it. As far as I understand nettle 3.1 should be out soon. > > regards, > Nikos > > Are there any updates on this? Not trying to rush you guys; just trying to make plans. alan From nmav at gnutls.org Sun Mar 15 09:14:26 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Mar 2015 09:14:26 +0100 Subject: [gnutls-help] GnuTLS and Nettle In-Reply-To: <5504EC4F.6070707@snowmoose.com> References: <54E4DA6C.50701@snowmoose.com> <1424296017.3853.3.camel@gnutls.org> <5504EC4F.6070707@snowmoose.com> Message-ID: <1426407266.1594.0.camel@gnutls.org> On Sat, 2015-03-14 at 19:19 -0700, Alan Perry wrote: > Are there any updates on this? Not trying to rush you guys; just trying > to make plans. The rough plan is listed on the wiki pages: https://gitlab.com/gnutls/gnutls/wikis/Plan3_4 From tquemerais at awox.com Mon Mar 16 09:39:33 2015 From: tquemerais at awox.com (Thierry Quemerais) Date: Mon, 16 Mar 2015 09:39:33 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data In-Reply-To: References: <1425924306.2022.20.camel@gnutls.org>

Message-ID: Hi Nikos, I got your point. I will change that and I will do what you suggested: Create an API gnutls_ext_register that receive in parameters all what is needed. I will also include a test file for your test suite and I will try to separate this patch as 3 different patches. Regards, Thierry -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, March 13, 2015 4:45 PM To: Thierry Quemerais Cc: gnutls-help at lists.gnutls.org Subject: Re: [gnutls-help] GNU TLS and extensions/supplemental data On Fri, Mar 13, 2015 at 2:53 PM, Thierry Quemerais wrote: > Hi Nikos, > > Thank you for your reply. > > Please find attached to this Email, the patch I made to achieve my goal. > For your information, I also found an issue in GNUTLS which does not handle supplemental data type > 255. > This fix is included in this patch: > - buf->data[sizepos] = 0; > - buf->data[sizepos + 1] = p->type; > + buf->data[sizepos] = (p->type >> 8) & 0xFF; > + buf->data[sizepos + 1] = (p->type) & 0xFF; Applied separately. > To achieve my goal : > I changed the way supplemental callback are stored. (gnutls_supplemental.c) > I moved extension en supplemental structure to gnutls.h header. (gnutls_supplemental_entry, extension_entry_st) > I created an opaque struct for strings (typedef struct gnutls_buffer gnutls_buffer_st;) and I added a function to append data in this buffer (Used by extension/supplemental callbacks). Thank you. I like the patch, it is pretty simple and straightforward. My main objection is the export of gnutls_ext_register structure, which will require ABI break in case we add anything there. Why not keep _gnutls_ext_register() as is, and then export a gnutls_ext_register() which receives everything needed in the current structure as parameters? The same for gnutls_supplemental_entry... The risk of this structure changing is lower, but better safe than sorry. Some more, but minor comments. * Would it be possible to submit the a patch from git, and use the --signoff flag (as well as send the DCO - see http://www.gnutls.org/devel.html) * It would be convenient for debugging to split the patch into two, one for the extensions and on for the supplemental * In extension_entry_st you use "short type". I think simply using an int or unsigned int would be better. * Do you have some small test programs to use in our test suite for this API? That would ensure that the API you add now remains unbroken over releases. regards, Nikos From mattroisang at gmail.com Tue Mar 17 18:46:25 2015 From: mattroisang at gmail.com (Mat Troi) Date: Tue, 17 Mar 2015 10:46:25 -0700 Subject: [gnutls-help] GnuTLS Self-Test Question In-Reply-To: References: Message-ID: Hi just an update on this question, it appears these 6 tests that failed in version 2.8.6 passed in version 3.3.9. I compared the test codes and they looked identical (the different is in nits like printf etc...). Just wondering if other people see the same results as me when running 2.8.6, thanks. On Fri, Feb 20, 2015 at 12:56 PM, Mat Troi wrote: > Hi, > > I am trying to run GnuTLS and I have 6 errors: > Hostname correctly matches (1) > Hostname correctly matches (1) > Hostname correctly matches (1) > Hostname correctly does not match (0) > Self test `./hostname-check' finished with 1 errors > FAIL: hostname-check > .... > .... > Adding CA certificate...done > CA Certificate: subject > `O=#130b43416365727420496e632e,OU=#1315687474703a2f2f7777772e4341636572742e6f7267,CN=#131343416365727420436c617373203320526f6f74', > issuer > `O=#1307526f6f74204341,OU=#1315687474703a2f2f7777772e6361636572742e6f7267,CN=#131943412043657274205369676e696e6720417574686f72697479,EMAIL=#1612737570706f7274406361636572742e6f7267', > RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 > 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint > `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d' > Verifying...(null): verify_status: 1026 expected: 0 > Cleanup...done > Exit status.. > FAIL: chainverify > .... > .... > crq_key_id |<2>| ASSERT: > /builds/adlai/userland-gnutls/components/gnutls/gnutls-2.8.6/lib/x509/crq.c:2343 > Key[RSA] generation ok: 0 > Key ids are identical. OK. > Key[DSA] generation ok: 0 > Key ids are identical. OK. > Self test `./crq_key_id' finished with 4 errors > FAIL: crq_key_id > gnutls_x509_privkey_sign_hash > gnutls_x509_crt_get_verify_algorithm > loop 0 > loop 1 > Self test `./x509sign-verify' finished with 2 errors > FAIL: x509sign-verify > ... > ... > client: Handshake failed > GNUTLS ERROR: A TLS packet with unexpected length was received. > server: ready. Listening to port '5556'. > Self test `./x509self' finished with 1 errors > server: ready. Listening to port '5556'. > Launched, generating DH parameters... > server: connection from 127.0.0.1, port 37430 > Self test `./x509self' finished with 1 errors > FAIL: x509self > .... > .... > client: Handshake failed > GNUTLS ERROR: A TLS packet with unexpected length was received. > server: ready. Listening to port '5556'. > Self test `./x509dn' finished with 1 errors > server: client failed with exit status 1 > server: ready. Listening to port '5556'. > Launched, generating DH parameters... > server: connection from 127.0.0.1, port 46399 > Self test `./x509dn' finished with 2 errors > FAIL: x509dn > > This is for running self test 2.8.6 gnuTLS. Has anyone seen this problem > or know how to solve? > > Thanks, > Mat Troi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tquemerais at awox.com Thu Mar 19 16:56:34 2015 From: tquemerais at awox.com (Thierry Quemerais) Date: Thu, 19 Mar 2015 16:56:34 +0100 Subject: [gnutls-help] GNU TLS and extensions/supplemental data References: <1425924306.2022.20.camel@gnutls.org>

Message-ID: Hi Nikos, Please find attached to this Email a clean patch for adding custom extension and custom supplemental data from public GNUTLS API. I take care of all your comments in order to give you a patch as you expected it. 0001: Fix data type > 255 in supplemental data 0002 0003: Add a way to set customs extensions from public API 0004: Add a way to add custom supplemental data from public API. For each ones, I added a test application mini-extension.c and mini-supplementaldata.c for your unit tests I'm hoping this patch includes all what you expected. Best regards, Thierry. -----Original Message----- From: Thierry Quemerais Sent: Monday, March 16, 2015 9:40 AM To: 'Nikos Mavrogiannopoulos' Cc: gnutls-help at lists.gnutls.org Subject: RE: [gnutls-help] GNU TLS and extensions/supplemental data Hi Nikos, I got your point. I will change that and I will do what you suggested: Create an API gnutls_ext_register that receive in parameters all what is needed. I will also include a test file for your test suite and I will try to separate this patch as 3 different patches. Regards, Thierry -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, March 13, 2015 4:45 PM To: Thierry Quemerais Cc: gnutls-help at lists.gnutls.org Subject: Re: [gnutls-help] GNU TLS and extensions/supplemental data On Fri, Mar 13, 2015 at 2:53 PM, Thierry Quemerais wrote: > Hi Nikos, > > Thank you for your reply. > > Please find attached to this Email, the patch I made to achieve my goal. > For your information, I also found an issue in GNUTLS which does not handle supplemental data type > 255. > This fix is included in this patch: > - buf->data[sizepos] = 0; > - buf->data[sizepos + 1] = p->type; > + buf->data[sizepos] = (p->type >> 8) & 0xFF; > + buf->data[sizepos + 1] = (p->type) & 0xFF; Applied separately. > To achieve my goal : > I changed the way supplemental callback are stored. (gnutls_supplemental.c) > I moved extension en supplemental structure to gnutls.h header. (gnutls_supplemental_entry, extension_entry_st) > I created an opaque struct for strings (typedef struct gnutls_buffer gnutls_buffer_st;) and I added a function to append data in this buffer (Used by extension/supplemental callbacks). Thank you. I like the patch, it is pretty simple and straightforward. My main objection is the export of gnutls_ext_register structure, which will require ABI break in case we add anything there. Why not keep _gnutls_ext_register() as is, and then export a gnutls_ext_register() which receives everything needed in the current structure as parameters? The same for gnutls_supplemental_entry... The risk of this structure changing is lower, but better safe than sorry. Some more, but minor comments. * Would it be possible to submit the a patch from git, and use the --signoff flag (as well as send the DCO - see http://www.gnutls.org/devel.html) * It would be convenient for debugging to split the patch into two, one for the extensions and on for the supplemental * In extension_entry_st you use "short type". I think simply using an int or unsigned int would be better. * Do you have some small test programs to use in our test suite for this API? That would ensure that the API you add now remains unbroken over releases. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Handle-supplemental-data-type-255.patch Type: application/octet-stream Size: 999 bytes Desc: 0001-Handle-supplemental-data-type-255.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Added-a-way-to-add-custom-extensions-from-public-API.patch Type: application/octet-stream Size: 18225 bytes Desc: 0002-Added-a-way-to-add-custom-extensions-from-public-API.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fixed-extension-test.patch Type: application/octet-stream Size: 1221 bytes Desc: 0003-Fixed-extension-test.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Added-a-way-to-add-custom-supplemental-data-from-pub.patch Type: application/octet-stream Size: 15999 bytes Desc: 0004-Added-a-way-to-add-custom-supplemental-data-from-pub.patch URL: From berillions at gmail.com Sat Mar 21 15:09:16 2015 From: berillions at gmail.com (LOMBARD Maxime) Date: Sat, 21 Mar 2015 15:09:16 +0100 Subject: [gnutls-help] Gnutls 3.3.X + Wine = problem Message-ID: Hi guys, I'm French so i will try to explain correctly the problem. Actually, there is a bug (?) in this version of Gnutls which disallow to run correctly a Windows application with Wine. This application is the Ubisoft software called "Uplay". In fact, when you launch Uplay with Wine and try to connect you to the application, Uplay hangs with the login screen. (See the reportbug in Wine bugzilla here : https://bugs.winehq.org/show_bug.cgi?id=38134 ) The only workaround which has been found is to compile Wine (and use it) with the old version of Gnutls (2.12.X). The big problem is that each Linux distribution (Fedora, Debian etc...) have delete this version from their repository to use the new version. It's easy to reproduce the bug : - Install the latest wine version (from Debian Jessie/Sid, Arch or others) - Download and install UPlay ( https://ubistatic3-a.akamaihd.net/orbit/launcher_installer/UplayInstaller.exe ) - Create an Uplay account and try to use it with Wine Thanks, Maxime -------------- next part -------------- An HTML attachment was scrubbed... URL: From lavr at ncbi.nlm.nih.gov Mon Mar 23 15:52:01 2015 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Mon, 23 Mar 2015 14:52:01 +0000 Subject: [gnutls-help] Gnutls 3.3.X + Wine = problem In-Reply-To: References: Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D13CB8C74@msgb06.nih.gov> Does that ring the bell? > > The only workaround which has been found is to compile Wine (and use it) > with the old version of Gnutls (2.12.X). > -----Original Message----- From: Lavrentiev, Anton (NIH/NLM/NCBI) [C] Sent: Monday, June 16, 2014 10:54 AM To: Nikos Mavrogiannopoulos Cc: gnutls-help at gnutls.org Subject: Re: [gnutls-help] Regression bug between 2.x and 3.2? > From that description I think that this is pretty much expected. A call > to gnutls_record_send() can be interrupted, and had to be called again > (I believe that was the case in all gnutls versions). If that's not > clear from the documentation please let me know what could be improved. Here's the problem: there was no interruption, there was a short write. Previous version of GNUTLS tolerated that by calling the push callback once again, and again, and again, giving up only when nothing _at all_ was written (-1 returned). Current version bails out immediately. This is a change in behavior, which is not backward compatible. The code in gnutls_buffers.c has changed significantly: it was presumably necessary to accommodate a vector write operation (writev), and could have resulted in the inadvertent change for the plain push. Anyhow, the push callback is documented to be a send()-like thing. Which means it is allowed to write fewer bytes than it was requested to, and that does not constitute an error. Previous GNUTLS version treated that exactly so, by re-trying the write until unsuccessful (and advancing with writes, most of the time). Current implementation considers the short write as a fault and returns EAGAIN. Thus, the callback is longer compatible with send(): if the callback wants GNUTLS to keep writing it must ensure to push as many bytes as it was told to, which means, it must be doing send()/wait()/send() sequences internally. P.S. I'm preparing a test case which should demonstrate the changed behavior. Anton Lavrentiev Contractor NIH/NLM/NCBI From vladimir.levijev at gmail.com Mon Mar 23 17:52:32 2015 From: vladimir.levijev at gmail.com (Vladimir Levijev) Date: Mon, 23 Mar 2015 18:52:32 +0200 Subject: [gnutls-help] Using gnutls_malloc() Message-ID: Hi, I can't figure out why gnutls_malloc() is never resolved on Windows (2008, 32-bit) here. I'm using this code sample: #include int main() { void *p = gnutls_malloc(10); return 0; } It compiles perfectly on GNU/Linux (gcc /tmp/hellognutls.c -o /tmp/hellognutls -Wall -lgnutls, I'm using version 2.12.20 though) but on Windows (I'm using latest pre-compiled library from gnu.org, 3.3.13) I get linking error: >cl hellognutls.c -I \gnutls\include /c /Fo"hellognutls.o" Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. hellognutls.c >link hellognutls.o \gnutls\lib\libgnutls.dll.a Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. hellognutls.o : error LNK2019: unresolved external symbol _gnutls_malloc referenced in function _main hellognutls.exe : fatal error LNK1120: 1 unresolved externals It won't help even if I add extern gnutls_alloc_function gnutls_malloc; which means gnutls.h is included properly. It only helps if I manually define gnutls_alloc_function gnutls_malloc = malloc; So it seems to me on Windows the line gnutls_alloc_function gnutls_malloc = malloc; from gnutls_mem.c has disappeared or something. Looking at 3.3.13 sources it is in place. Is Windows library compiled in some special way where *malloc functions are not available? Or what am I doing wrong? Thanks beforehand, VL From nmav at gnutls.org Mon Mar 23 22:27:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Mar 2015 22:27:39 +0100 Subject: [gnutls-help] Gnutls 3.3.X + Wine = problem In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D13CB8C74@msgb06.nih.gov> References: <5F8AAC04F9616747BC4CC0E803D5907D13CB8C74@msgb06.nih.gov> Message-ID: <1427146059.1693.1.camel@gnutls.org> On Mon, 2015-03-23 at 14:52 +0000, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote: > Does that ring the bell? Is that the case with wine? I did a quick hack to simulate the old behavior and the result is the same. regards, Nikos From nmav at gnutls.org Tue Mar 24 09:17:23 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 Mar 2015 09:17:23 +0100 Subject: [gnutls-help] Using gnutls_malloc() In-Reply-To: References: Message-ID: On Mon, Mar 23, 2015 at 5:52 PM, Vladimir Levijev wrote: > Hi, > I can't figure out why gnutls_malloc() is never resolved on Windows > (2008, 32-bit) here. I'm using this code sample: > #include > int main() > { > void *p = gnutls_malloc(10); > return 0; > } > It compiles perfectly on GNU/Linux (gcc /tmp/hellognutls.c -o > /tmp/hellognutls -Wall -lgnutls, I'm using version 2.12.20 though) but > on Windows (I'm using latest pre-compiled library from gnu.org, > 3.3.13) I get linking error: >>cl hellognutls.c -I \gnutls\include /c /Fo"hellognutls.o" > Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 > Copyright (C) Microsoft Corporation. All rights reserved. > hellognutls.c I have no such issue when using mingw to compile with the library. > which means gnutls.h is included properly. It only helps if I manually define > gnutls_alloc_function gnutls_malloc = malloc; That's pretty strange. A work around could be to simply use malloc() as in the latest versions there is no way to override the gnutls memory functions. That may not be very future proof though. regards, Nikos From vladimir.levijev at gmail.com Wed Mar 25 11:10:12 2015 From: vladimir.levijev at gmail.com (Vladimir Levijev) Date: Wed, 25 Mar 2015 12:10:12 +0200 Subject: [gnutls-help] Using gnutls_malloc() In-Reply-To: References: Message-ID: On 24 March 2015 at 10:17, Nikos Mavrogiannopoulos wrote: > On Mon, Mar 23, 2015 at 5:52 PM, Vladimir Levijev > wrote: >> Hi, >> I can't figure out why gnutls_malloc() is never resolved on Windows >> (2008, 32-bit) here. I'm using this code sample: >> #include >> int main() >> { >> void *p = gnutls_malloc(10); >> return 0; >> } >> It compiles perfectly on GNU/Linux (gcc /tmp/hellognutls.c -o >> /tmp/hellognutls -Wall -lgnutls, I'm using version 2.12.20 though) but >> on Windows (I'm using latest pre-compiled library from gnu.org, >> 3.3.13) I get linking error: >>>cl hellognutls.c -I \gnutls\include /c /Fo"hellognutls.o" >> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86 >> Copyright (C) Microsoft Corporation. All rights reserved. >> hellognutls.c > > I have no such issue when using mingw to compile with the library. I have installed mingw and indeed had no issues there. However, I wasn't able to link my program with GnuTLS statically (see attached picture). Is it not possible or am I doing something wrong? I really need a way to link with GnuTLS statically. Cheers, VL -------------- next part -------------- A non-text attachment was scrubbed... Name: hellognutls.jpg Type: image/jpeg Size: 30884 bytes Desc: not available URL: From nmav at gnutls.org Wed Mar 25 13:07:46 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Mar 2015 13:07:46 +0100 Subject: [gnutls-help] Using gnutls_malloc() In-Reply-To: References: Message-ID: On Wed, Mar 25, 2015 at 11:10 AM, Vladimir Levijev wrote: >> I have no such issue when using mingw to compile with the library. > I have installed mingw and indeed had no issues there. However, I > wasn't able to link my program with GnuTLS statically (see attached > picture). Is it not possible or am I doing something wrong? I really > need a way to link with GnuTLS statically. To link statically you cannot link against the .dll.a. You need to link against the .a. I don't think that this is shipped in the windows binaries. regards, Nikos From vladimir.levijev at gmail.com Thu Mar 26 14:55:36 2015 From: vladimir.levijev at gmail.com (Vladimir Levijev) Date: Thu, 26 Mar 2015 15:55:36 +0200 Subject: [gnutls-help] Using gnutls_malloc() In-Reply-To: References: Message-ID: On 25 March 2015 at 14:07, Nikos Mavrogiannopoulos wrote: > On Wed, Mar 25, 2015 at 11:10 AM, Vladimir Levijev > wrote: >>> I have no such issue when using mingw to compile with the library. >> I have installed mingw and indeed had no issues there. However, I >> wasn't able to link my program with GnuTLS statically (see attached >> picture). Is it not possible or am I doing something wrong? I really >> need a way to link with GnuTLS statically. > > To link statically you cannot link against the .dll.a. You need to > link against the .a. I don't think that this is shipped in the windows > binaries. That's probably the reason why there was a link error in the first place. This function is probably available in another DLL (I was linking against libgnutls.dll.a, but the code is probably available in libgnutls-28.dll). Thanks, VL From jonetsu at teksavvy.com Fri Mar 27 01:16:07 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Thu, 26 Mar 2015 20:16:07 -0400 Subject: [gnutls-help] FIPS mode: letting the OS know Message-ID: <20150326201607.1a4b69fa@mevla> Hello, What would be the most practical way to add some code to a FIPS-mode GnuTLS in order to notify the OS of any FIPS error ? That notification could simply be creating a file at a location that is watched over by an application using inotify. The idea is to be able to take any action when such errors happen and, not to modify applications that are using GnuTLS since this would require more code maintenance. I don't think this code would be in upstream GnuTLS since it is local to the domain of the runtime OS. Is there a method that is always called when FIPS errors are encountered ? Or is there a callback that can be set in the library to catch error codes ? Regards. From nmav at gnutls.org Fri Mar 27 10:29:37 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 27 Mar 2015 10:29:37 +0100 Subject: [gnutls-help] FIPS mode: letting the OS know In-Reply-To: <20150326201607.1a4b69fa@mevla> References: <20150326201607.1a4b69fa@mevla> Message-ID: On Fri, Mar 27, 2015 at 1:16 AM, jonetsu at teksavvy.com wrote: > Hello, > What would be the most practical way to add some code to a > FIPS-mode GnuTLS in order to notify the OS of any FIPS error ? That > notification could simply be creating a file at a location that is > watched over by an application using inotify. The idea is to be able > to take any action when such errors happen and, not to modify > applications that are using GnuTLS since this would require more code > maintenance. Check fips.h and _gnutls_switch_lib_state(). This is the function called when the library enters an error state. regards, Nikos From nmav at gnutls.org Mon Mar 30 07:34:01 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 30 Mar 2015 07:34:01 +0200 Subject: [gnutls-help] gnutls 3.3.14 Message-ID: <1427693641.9157.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.14. This is a bug-fix release on the current stable branch. * Version 3.3.14 (released 2015-03-30) ** libgnutls: When retrieving OCTET STRINGS from PKCS #12 ContentInfo structures use BER to decode them (requires libtasn1 4.3). That allows to decode some more complex structures. ** libgnutls: When an end-certificate with no name is present and there are CA name constraints, don't reject the certificate. This follows RFC5280 advice closely. Reported by Fotis Loukos. ** libgnutls: Fixed handling of supplemental data with types > 255. Patch by Thierry Quemerais. ** libgnutls: Fixed double free in the parsing of CRL distribution points certificate extension. Reported by Robert ?wi?cki. ** libgnutls: Fixed a two-byte stack overflow in DTLS 0.9 protocol. That protocol is not enabled by default (used by openconnect VPN). ** libgnutls: The maximum user data send size is set to be the same for block and non-block ciphersuites. This addresses a regression with wine: https://bugs.winehq.org/show_bug.cgi?id=37500 ** libgnutls: When generating PKCS #11 keys, set CKA_ID, CKA_SIGN, and CKA_DECRYPT when needed. ** libgnutls: Allow names with zero size to be set using gnutls_server_name_set(). That will disable the Server Name Indication. Resolves issue with wine: https://gitlab.com/gnutls/gnutls/issues/2 ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.14.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.14.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.14.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.14.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos