From rick at openfortress.nl Thu Nov 5 20:46:27 2015 From: rick at openfortress.nl (Rick van Rein) Date: Thu, 05 Nov 2015 20:46:27 +0100 Subject: [gnutls-help] Many "Hello Request" messages Message-ID: <563BB213.50402@openfortress.nl> Hello, I'm trying to get handshake renegotiation working with GnuTLS 3.2.21, and I wonder if I may have run into a GnuTLS bug. Using tcpdump, I found an astounding number of Hello Request messages, even when I didn't trigger renogotiation. More seriously, I also see these messages from client to server, which is not explicitly permitted in Section 7.4.1.1 of RFC 5246, unlike the server-sent message. Here are the patterns I am seeing: c->s Client Hello (TLS 1.2) c<-s Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done c->s Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, HELLO REQUEST, HELLO REQUEST c<-s Change Cipher Spec, HELLO REQUEST, HELLO REQUEST ... c->s Application Data [me typing rubbish] ... Then I ask GnuTLS to renegotiate from the client: c->s HELLO REQUEST, HELLO REQUEST c<-s HELLO REQUEST, HELLO REQUEST, HELLO REQUEST, HELLO REQUEST, HELLO REQUEST, HELLO REQUEST c->s HELLO REQUEST, HELLO REQUEST, Change Cipher Spec, Encrypted Handshake Message c<-s Change Cipher Spec, Encrypted Handshake Message ... c->s Application Data [me typing rubbish again] ... Then I ask GnuTLS to renegotiate from the server. This is bound to fail, since I commented-out gnutls_rehandshake() After a while I start typing again on the client: c->s Application Data [rubbish] The server closes the connection when it sees that it gets data, not the expected Client Hello. What can be the explanation of the multitude of Hello Request messages? They seem to be grouped in pairs in one record level message, multiple of which may occur in one TCP-level message. Within a pair, the first seems to always be empty and the second I've seen with 0, 1 and 2 bytes of contents. I'm starting to believe that something is wrong with the handshake renegotiation code, or am I doing something funny? I'm using GnuTLS 3.2.21 at the moment, but didn't find remarks about handshaking in the news since that version, so I've assumed that there's no value in upgrading to the latest version. Any ideas? Thanks, -Rick From rick at openfortress.nl Fri Nov 6 08:59:40 2015 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 06 Nov 2015 08:59:40 +0100 Subject: [gnutls-help] Many "Hello Request" messages In-Reply-To: <563BB213.50402@openfortress.nl> References: <563BB213.50402@openfortress.nl> Message-ID: <563C5DEC.6000301@openfortress.nl> Hello again, An update to... > Using tcpdump, I found an astounding number of Hello Request messages, > even when I didn't trigger renogotiation. More seriously, I also see > these messages from client to server, which is not explicitly permitted > in Section 7.4.1.1 of RFC 5246, unlike the server-sent message. > There is more wrong -- the unexpected Hello Request messages are packed into a "Multiple Handshake Messages" but the last parts of these are not unpacked by WireShark. Clearly, something is wrongfully encoded. I've wondered if this could be my application, especially because the Hello Requests are a series of zero bytes; but since the trouble exists *inside* these Multiple Handshake Messages which do have non-zero codes and sizes to match the total frame size, I would be surprised to learn that. I'm attaching the .pcap file, in case anyone wants to see it. Thanks, -Rick -------------- next part -------------- A non-text attachment was scrubbed... Name: wireshark.pcap Type: application/octet-stream Size: 5694 bytes Desc: not available URL: From rick at openfortress.nl Fri Nov 6 10:18:56 2015 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 06 Nov 2015 10:18:56 +0100 Subject: [gnutls-help] Many "Hello Request" messages In-Reply-To: <563C5DEC.6000301@openfortress.nl> References: <563BB213.50402@openfortress.nl> <563C5DEC.6000301@openfortress.nl> Message-ID: <563C7080.7000207@openfortress.nl> And... I solved my own problem, sorry. It turns out that WireShark isn't as dependable as it normally is; it cannot see that the handshake messages are encrypted. Inspecting things at the binary level, this was clearer than the decoded output (...) Sorry about this. I didn't realise the Record level left no markers of having applied encryption -- and WireShark's deciphering as Encrypted Handshake Message sent me into a wrong line of thought. Case closed :) -Rick From nmav at gnutls.org Fri Nov 6 11:14:37 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Nov 2015 11:14:37 +0100 Subject: [gnutls-help] Many "Hello Request" messages In-Reply-To: <563C7080.7000207@openfortress.nl> References: <563BB213.50402@openfortress.nl> <563C5DEC.6000301@openfortress.nl> <563C7080.7000207@openfortress.nl> Message-ID: On Fri, Nov 6, 2015 at 10:18 AM, Rick van Rein wrote: > And... > I solved my own problem, sorry. > It turns out that WireShark isn't as dependable as it normally is; it > cannot see that the handshake messages are encrypted. Inspecting things > at the binary level, this was clearer than the decoded output (...) > Sorry about this. I didn't realise the Record level left no markers of > having applied encryption -- and WireShark's deciphering as Encrypted > Handshake Message sent me into a wrong line of thought. That reminded me of: https://bugzilla.redhat.com/show_bug.cgi?id=1105575 I remember I spent quite some time trying to understand what are these messages. Not sure if it was ever forwarded upstream. regards, Nikos From rick at openfortress.nl Fri Nov 6 11:23:36 2015 From: rick at openfortress.nl (Rick van Rein) Date: Fri, 06 Nov 2015 11:23:36 +0100 Subject: [gnutls-help] Many "Hello Request" messages In-Reply-To: <563C7F8B.4020806@openfortress.nl> References: <563BB213.50402@openfortress.nl> <563C5DEC.6000301@openfortress.nl> <563C7080.7000207@openfortress.nl> <563C7F8B.4020806@openfortress.nl> Message-ID: <563C7FA8.1000209@openfortress.nl> Hi Nikos, > That reminded me of: > https://bugzilla.redhat.com/show_bug.cgi?id=1105575 Exactly the same, yes. I downloaded your pcap and found the precise same pattern. > I remember I spent quite some time trying to understand what are these > messages. Not sure if it was ever forwarded upstream. I'm not the only one who got confused then ;-) You seem to have come to the same conclusion too: WireShark is outputting data in a confusing manner, by trying to decode what it can, which is always senseless after a Change CipherSpec. Alaz, WireShark isn't aware of the stream and TLS records don't hint at encryption, so I'm already surprised that it decides that the handshakes are encrypted later on. It's the inconsistency that hurts. My WireShark is 1.2.12 and it still does this. Thanks, -Rick From rick at openfortress.nl Mon Nov 9 23:29:11 2015 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 09 Nov 2015 23:29:11 +0100 Subject: [gnutls-help] Renegotiating from ANON to RSA -- Removing all ciphersuites? Message-ID: <56411E37.9010609@openfortress.nl> Hello, I'm trying to get optimal TLS privacy by first establishing an ANON-ECDH connection, and then renegotiate it into an authenticated connection, such as with an RSA certificate. This is only done when the application protocol allows it. Without the ANON-ECDH precursor, the authenticated connection succeeds. Its cli+srv priority string is NONE:+VERS-TLS-ALL:+VERS-DTLS-ALL:+COMP-NULL:+CIPHER-ALL:+CURVE-ALL:+SIGN-ALL:+MAC-ALL:-ANON-ECDH:+ECDHE-RSA:+DHE-RSA:+ECDHE-ECDSA:+DHE-DSS:+RSA:+CTYPE-X.509:+CTYPE-OPENPGP:+SRP:+SRP-RSA:+SRP-DSS The ANON-ECDH precursor also works (and moves straight on to renegotiation). Its cli+srv priority string is NONE:+VERS-TLS-ALL:+VERS-DTLS-ALL:+COMP-NULL:+CIPHER-ALL:+CURVE-ALL:+SIGN-ALL:+MAC-ALL:+ANON-ECDH:+ECDHE-RSA:+DHE-RSA:+ECDHE-ECDSA:+DHE-DSS:+RSA:+CTYPE-X.509:+CTYPE-OPENPGP:+SRP:+SRP-RSA:+SRP-DSS After the ANON-ECDH precursor, the renegotiated / authenticated connection (with the former priority string) fails. It lists "Removing ciphersuite" for all ciphersuites (note that ANON-ECDH is not provided for any longer). The GnuTLS code for sending the ClientHello suggests that this is based on the KX supported by the certificate, which I imagine must refer to the pre-renegotiation (so ANON-ECDH) precursor certificate. No KX would match with that (lack of a) certificate, of course. The result is GNUTLS_E_INSUFFICIENT_CRED and a breakdown of communication. IIRC. I wonder if there is a way to have this "anonymous precursor" with GnuTLS, or that I am overlooking something? I'm working with GnuTLS 3.2.21. Thanks, -Rick From nmav at gnutls.org Tue Nov 10 16:24:04 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 10 Nov 2015 16:24:04 +0100 Subject: [gnutls-help] Renegotiating from ANON to RSA -- Removing all ciphersuites? In-Reply-To: <56411E37.9010609@openfortress.nl> References: <56411E37.9010609@openfortress.nl> Message-ID: On Mon, Nov 9, 2015 at 11:29 PM, Rick van Rein wrote: > Hello, > > I'm trying to get optimal TLS privacy by first establishing an ANON-ECDH > connection, and then renegotiate it into an authenticated connection, > such as with an RSA certificate. This is only done when the application > protocol allows it. > > Without the ANON-ECDH precursor, the authenticated connection succeeds. > Its cli+srv priority string is > NONE:+VERS-TLS-ALL:+VERS-DTLS-ALL:+COMP-NULL:+CIPHER-ALL:+CURVE-ALL:+SIGN-ALL:+MAC-ALL:-ANON-ECDH:+ECDHE-RSA:+DHE-RSA:+ECDHE-ECDSA:+DHE-DSS:+RSA:+CTYPE-X.509:+CTYPE-OPENPGP:+SRP:+SRP-RSA:+SRP-DSS > > The ANON-ECDH precursor also works (and moves straight on to > renegotiation). Its cli+srv priority string is > NONE:+VERS-TLS-ALL:+VERS-DTLS-ALL:+COMP-NULL:+CIPHER-ALL:+CURVE-ALL:+SIGN-ALL:+MAC-ALL:+ANON-ECDH:+ECDHE-RSA:+DHE-RSA:+ECDHE-ECDSA:+DHE-DSS:+RSA:+CTYPE-X.509:+CTYPE-OPENPGP:+SRP:+SRP-RSA:+SRP-DSS > After the ANON-ECDH precursor, the renegotiated / authenticated > connection (with the former priority string) fails. It lists "Removing > ciphersuite" for all ciphersuites (note that ANON-ECDH is not provided > for any longer). The GnuTLS code for sending the ClientHello suggests > that this is based on the KX supported by the certificate, which I > imagine must refer to the pre-renegotiation (so ANON-ECDH) precursor > certificate. No KX would match with that (lack of a) certificate, of > course. The result is GNUTLS_E_INSUFFICIENT_CRED and a breakdown of > communication. IIRC. You need to set different "credentials" for anonymous and certificate authentication. Did you set both of them or only for anonymous? regards, Nikos From rick at openfortress.nl Tue Nov 10 16:30:31 2015 From: rick at openfortress.nl (Rick van Rein) Date: Tue, 10 Nov 2015 16:30:31 +0100 Subject: [gnutls-help] Renegotiating from ANON to RSA -- Removing all ciphersuites? In-Reply-To: <56420D7E.2090408@openfortress.nl> References: <56411E37.9010609@openfortress.nl> <56420D7E.2090408@openfortress.nl> Message-ID: <56420D97.7060809@openfortress.nl> Hello Nikos, > You need to set different "credentials" for anonymous and certificate > authentication. Did you set both of them or only for anonymous? I set both up initially, but didn't repeat them for renegotiation -- under the assumption that the credentials are kept. That also means I didn't remove the anonymous credentials for the reneg -- under the assumption that the priority string would help to ignore them. Are these assumptions correct? Thanks, -Rick From nmav at gnutls.org Wed Nov 11 11:18:12 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 11 Nov 2015 11:18:12 +0100 Subject: [gnutls-help] Renegotiating from ANON to RSA -- Removing all ciphersuites? In-Reply-To: <56430225.7000605@openfortress.nl> References: <56411E37.9010609@openfortress.nl> <56420D7E.2090408@openfortress.nl> <1447181686.1789.3.camel@gnutls.org> <56430225.7000605@openfortress.nl> Message-ID: On Wed, Nov 11, 2015 at 9:53 AM, Rick van Rein wrote: > Hi Nikos, > > Thanks so far. I see you've dropped the list Cc, to which I'm > impartial; the TLS Pool is open source code. You did on your reply. I'm adding the ML. >> If you could reproduce this with a minimal test >> program (e.g., mini-x509 or so), I could take a look. > I started making this, but the code is quite entangled with other > modules that handle PIN entry, database lookups for credentials and so > on. Instead, may I talk you through the publicly viewable code on > GitHub? You could ignore most of it, and go for the gnutls_XXX labels. I've added mini-x509-dual.c which does a dual handshake with ANON-ECDH, followed by RSA. That seems to work. However, switching to ECDHE or DHE failed. That was unfortunately a bug which I've fixed at: https://gitlab.com/gnutls/gnutls/commit/4639441dc6f4c45b0ba806bc708fb928bb8a64ae regards, Nikos From jw at ib-weinhardt.de Fri Nov 13 17:28:46 2015 From: jw at ib-weinhardt.de (=?UTF-8?Q?J=c3=b6rg_Weinhardt?=) Date: Fri, 13 Nov 2015 17:28:46 +0100 Subject: [gnutls-help] Error using certtool with config file on Win32 Message-ID: <56460FBE.8030209@ib-weinhardt.de> Hi, I tried to use certtool from GnuTLS 3.4.5-w32 and also GnuTLS 3.3.13-w32 using a template file as input. I always get the following error message: certtool -V --generate-self-signed --load-privkey test_key.key --template test_template.txt --outfile test_cert.cert libopts error 0 (No error) calling read for 'test_template.txt' configFileLoad: No error Error loading template: test_template.txt The content of test_template.txt: # X.509 Certificate options # # DN options # The organization of the subject. organization = "My company" Is this a known problem? Same call works with the linux version of certtool, but in that project would be helpful to have all tools on win32. regards, Joerg From n.mavrogiannopoulos at gmail.com Sun Nov 15 09:55:50 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 15 Nov 2015 09:55:50 +0100 Subject: [gnutls-help] Error using certtool with config file on Win32 In-Reply-To: <56460FBE.8030209@ib-weinhardt.de> References: <56460FBE.8030209@ib-weinhardt.de> Message-ID: <1447577750.18823.2.camel@gmail.com> On Fri, 2015-11-13 at 17:28 +0100, J?rg Weinhardt wrote: > Hi, > > I tried to use certtool from GnuTLS 3.4.5-w32 and also GnuTLS > 3.3.13-w32 using a template file as input. > > I always get the following error message: > > certtool -V --generate-self-signed --load-privkey test_key.key > --template test_template.txt --outfile test_cert.cert > libopts error 0 (No error) calling read for 'test_template.txt' > configFileLoad: No error > Error loading template: test_template.txt Hi, That is output by libopts used by certtool to read the template. It seems that libopts gets a premature end of file while reading it. However, I couldn't reproduce that with wine and your configuration file. Which version of windows is that? regards, Nikos From jw at ib-weinhardt.de Sun Nov 15 14:39:05 2015 From: jw at ib-weinhardt.de (=?UTF-8?Q?J=c3=b6rg_Weinhardt?=) Date: Sun, 15 Nov 2015 14:39:05 +0100 Subject: [gnutls-help] Error using certtool with config file on Win32 In-Reply-To: <1447577750.18823.2.camel@gmail.com> References: <56460FBE.8030209@ib-weinhardt.de> <1447577750.18823.2.camel@gmail.com> Message-ID: <56488AF9.7070406@ib-weinhardt.de> Am 15.11.2015 um 09:55 schrieb Nikos Mavrogiannopoulos: > On Fri, 2015-11-13 at 17:28 +0100, J?rg Weinhardt wrote: >> Hi, >> >> I tried to use certtool from GnuTLS 3.4.5-w32 and also GnuTLS >> 3.3.13-w32 using a template file as input. >> >> I always get the following error message: >> >> certtool -V --generate-self-signed --load-privkey test_key.key >> --template test_template.txt --outfile test_cert.cert >> libopts error 0 (No error) calling read for 'test_template.txt' >> configFileLoad: No error >> Error loading template: test_template.txt > > Hi, > That is output by libopts used by certtool to read the template. It > seems that libopts gets a premature end of file while reading it. > However, I couldn't reproduce that with wine and your configuration > file. Which version of windows is that? > > > regards, > Nikos > > Hi Nikos, that was a good hint! I replaced the Windows CR/LF by a Unix-style LF and it works. Is it possible to configure libopts to handle both? Thanks and regards, Joerg From seyeong.kim at canonical.com Mon Nov 16 09:10:34 2015 From: seyeong.kim at canonical.com (Seyeong Kim) Date: Mon, 16 Nov 2015 17:10:34 +0900 Subject: [gnutls-help] Question about POODLE tls1 Message-ID: Hello I'm using cups but it seems having poodle tls1 vulnerable on ssllabs test POODLE (TLS)*Vulnerable INSECURE* (more info ) and same issue reported to launchpad https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1510163 he is saying that gnutls26 | 2.12.23-12ubuntu2.2 | trusty-updates | source have problem gnutls28 | 3.2.11-2ubuntu1.1 | trusty-updates/universe | source have no problem Could you please give me any suggestion to fix this issue on 2.12.xx version of gnutls if possible? ( commit number or information.. ) Thanks a lot -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.mavrogiannopoulos at gmail.com Mon Nov 16 11:18:29 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 11:18:29 +0100 Subject: [gnutls-help] Error using certtool with config file on Win32 In-Reply-To: <56488AF9.7070406@ib-weinhardt.de> References: <56460FBE.8030209@ib-weinhardt.de> <1447577750.18823.2.camel@gmail.com> <56488AF9.7070406@ib-weinhardt.de> Message-ID: I'm adding Bruce into CC. Most likely using the O_BINARY flag should solve that. Jorg could you try if the attached patch address the issue? On Sun, Nov 15, 2015 at 2:39 PM, J?rg Weinhardt wrote: > Am 15.11.2015 um 09:55 schrieb Nikos Mavrogiannopoulos: >> On Fri, 2015-11-13 at 17:28 +0100, J?rg Weinhardt wrote: >>> Hi, >>> >>> I tried to use certtool from GnuTLS 3.4.5-w32 and also GnuTLS >>> 3.3.13-w32 using a template file as input. >>> >>> I always get the following error message: >>> >>> certtool -V --generate-self-signed --load-privkey test_key.key >>> --template test_template.txt --outfile test_cert.cert >>> libopts error 0 (No error) calling read for 'test_template.txt' >>> configFileLoad: No error >>> Error loading template: test_template.txt >> >> Hi, >> That is output by libopts used by certtool to read the template. It >> seems that libopts gets a premature end of file while reading it. >> However, I couldn't reproduce that with wine and your configuration >> file. Which version of windows is that? >> >> >> regards, >> Nikos >> >> > > > Hi Nikos, > > that was a good hint! I replaced the Windows CR/LF by a Unix-style LF > and it works. Is it possible to configure libopts to handle both? > > Thanks and regards, > Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: text.patch Type: text/x-diff Size: 533 bytes Desc: not available URL: From nmav at gnutls.org Mon Nov 16 11:26:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Nov 2015 11:26:47 +0100 Subject: [gnutls-help] Question about POODLE tls1 In-Reply-To: References: Message-ID: On Mon, Nov 16, 2015 at 9:10 AM, Seyeong Kim wrote: > Hello > > I'm using cups but it seems having poodle tls1 vulnerable on ssllabs test > > POODLE (TLS)*Vulnerable INSECURE* (more info > > ) > and same issue reported to launchpad > > https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1510163 > > he is saying that > > gnutls26 | 2.12.23-12ubuntu2.2 | trusty-updates | source > gnutls 2.12 is not maintained since long time. However, poodle is easily solvable by disabling SSL 3.0. There should be a configuration setting in the program that you use to achieve that. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jw at ib-weinhardt.de Tue Nov 17 15:05:53 2015 From: jw at ib-weinhardt.de (=?UTF-8?Q?J=c3=b6rg_Weinhardt?=) Date: Tue, 17 Nov 2015 15:05:53 +0100 Subject: [gnutls-help] Error using certtool with config file on Win32 In-Reply-To: References: <56460FBE.8030209@ib-weinhardt.de> <1447577750.18823.2.camel@gmail.com> <56488AF9.7070406@ib-weinhardt.de> Message-ID: <564B3441.8070109@ib-weinhardt.de> Hello Nikos, I working with prebuilt Win32 binaries at them moment and it seems to be a bit tricky to build GnutTLS on Windows. I will try it but it will take some days (busy at the moment). regards, Joerg Am 16.11.2015 um 11:18 schrieb Nikos Mavrogiannopoulos: > I'm adding Bruce into CC. Most likely using the O_BINARY flag should > solve that. Jorg could you try if the attached patch address the > issue? > From bryan.quigley at canonical.com Tue Nov 17 15:32:20 2015 From: bryan.quigley at canonical.com (Bryan Quigley) Date: Tue, 17 Nov 2015 09:32:20 -0500 Subject: [gnutls-help] Question about POODLE tls1 Message-ID: >gnutls 2.12 is not maintained since long time. However, poodle is easily >solvable by disabling SSL 3.0. There should be a configuration setting in >the program that you use to achieve that. That's what I assumed as well, but since Poodle was released it was found to also affect some implementations of TLS. This is a test server [1] (using cups TLS) that has SSLv3 disabled but ssllabs has determined TLS is affected by Poodle. The best description of this slightly different Poodle is available here[2]. Poodle affecting TLS has only been known for a few months, which means the fix was done long before this was known.. Kind regards, Bryan [1] https://www.ssllabs.com/ssltest/analyze.html?d=190.35.213.162.lcy-02.canonistack.canonical.com&hideResults=on [2] https://vivaldi.net/userblogs/entry/there-are-more-poodles-in-the-forest From nmav at gnutls.org Wed Nov 18 10:07:32 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Nov 2015 10:07:32 +0100 Subject: [gnutls-help] Question about POODLE tls1 In-Reply-To: References: Message-ID: On Tue, Nov 17, 2015 at 3:32 PM, Bryan Quigley wrote: >>gnutls 2.12 is not maintained since long time. However, poodle is easily >>solvable by disabling SSL 3.0. There should be a configuration setting in >>the program that you use to achieve that. > That's what I assumed as well, but since Poodle was released it was > found to also affect some implementations of TLS. This is a test > server [1] (using cups TLS) that has SSLv3 disabled but ssllabs has > determined TLS is affected by Poodle. The best description of this > slightly different Poodle is available here[2]. It may be that the test done by qualys does not reflect the description in [2]. GnuTLS 2.12.x does the padding correctly so either the tests only checks for CBC ciphersuites and tag the server as broken, or the test is broken. regards, Nikos From jonetsu at teksavvy.com Wed Nov 18 17:52:11 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 18 Nov 2015 11:52:11 -0500 Subject: [gnutls-help] FIPS checks in FIPS mode Message-ID: Hello, Are any FIPS self-checks done when executing?gnutls_global_init(); and?gnutls_init(); when GnuTLS runs in FIPS mode (as reported by the return value of '1' to?gnutls_fips140_mode_enabled()) ? ?If not, is it possible to have these tests made explicitly ? Thanks. From bryan.quigley at canonical.com Wed Nov 18 20:22:43 2015 From: bryan.quigley at canonical.com (Bryan Quigley) Date: Wed, 18 Nov 2015 14:22:43 -0500 Subject: [gnutls-help] Question about POODLE tls1 In-Reply-To: References: Message-ID: I've asked SSL Labs [1] to see if it could be a false positive and if not if there are more specific details. Thanks and regards, Bryan [1] http://sourceforge.net/p/ssllabs/mailman/ssllabs-discuss/?viewmonth=201511&viewday=18 On Wed, Nov 18, 2015 at 4:07 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Nov 17, 2015 at 3:32 PM, Bryan Quigley > wrote: >>>gnutls 2.12 is not maintained since long time. However, poodle is easily >>>solvable by disabling SSL 3.0. There should be a configuration setting in >>>the program that you use to achieve that. >> That's what I assumed as well, but since Poodle was released it was >> found to also affect some implementations of TLS. This is a test >> server [1] (using cups TLS) that has SSLv3 disabled but ssllabs has >> determined TLS is affected by Poodle. The best description of this >> slightly different Poodle is available here[2]. > > It may be that the test done by qualys does not reflect the > description in [2]. GnuTLS 2.12.x does the padding correctly so either > the tests only checks for CBC ciphersuites and tag the server as > broken, or the test is broken. > > regards, > Nikos From nmav at gnutls.org Fri Nov 20 22:05:26 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Nov 2015 22:05:26 +0100 Subject: [gnutls-help] FIPS checks in FIPS mode In-Reply-To: References: Message-ID: <1448053526.3997.0.camel@gnutls.org> On Wed, 2015-11-18 at 11:52 -0500, jonetsu wrote: > Hello, > > > Are any FIPS self-checks done when executing gnutls_global_init(); > and gnutls_init(); Yes From nmav at gnutls.org Sun Nov 22 13:44:37 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Nov 2015 13:44:37 +0100 Subject: [gnutls-help] gnutls 3.3.19 Message-ID: <1448196277.22666.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.19. This is a bug-fix release on the current stable branch. * Version 3.3.19 (released 2015-11-22) ** libgnutls: Properly require TLS 1.2 to all the CBC-SHA256 and CBC-SHA384 ciphersuites. This solves an interoperability issue with openssl. Reported by Viktor Dukhovni. ** libgnutls: Fixed memory leak in gnutls_pubkey_get_preferred_hash_algorithm(), patch by Lennert Buytenhek. ** libgnutls: When writing a certificate into a PKCS #11 token, ensure that CKA_SERIAL_NUMBER and CKA_ISSUER are written. ** libgnutls: Allow the presence of legacy ciphers and key exchanges in priority strings and consider them a no-op. ** libgnutls: On a rehandshake allow switching from anonymous to ECDHE and DHE ciphersuites. ** libgnutls: Added GNUTLS_SKIP_GLOBAL_INIT macro to allow programs skipping the implicit global initialization. ** gnutls.pc: Don't include libtool specific options to link flags. Reported by Dan Kegel. ** API and ABI modifications: GNUTLS_SKIP_GLOBAL_INIT: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.19.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Nov 22 13:46:35 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Nov 2015 13:46:35 +0100 Subject: [gnutls-help] gnutls 3.4.7 Message-ID: <1448196395.22666.3.camel@gnutls.org> Hello, I've just released gnutls 3.4.7. This version fixes bugs and adds minor features to the next stable branch. * Version 3.4.7 (released 2015-11-22) ** libgnutls: Properly require TLS 1.2 in all CBC-SHA256 and CBC-SHA384 ciphersuites. This solves an interoperability issue with openssl. Reported by Viktor Dukhovni. ** libgnutls: Corrected the setting of salt size in gnutls_pkcs12_mac_info(). ** libgnutls: On a rehandshake allow switching from anonymous to ECDHE and DHE ciphersuites. ** libgnutls: Corrected regression from 3.3.x which prevented ARCFOUR128 from using arbitrary key sizes. Reported by Andreas Schneider. ** libgnutls: Added GNUTLS_SKIP_GLOBAL_INIT macro to allow programs skipping the implicit global initialization. ** gnutls.pc: Don't include libtool specific options to link flags. Reported by Dan Kegel. ** tools: Better support for FTP AUTH TLS negotiation ** API and ABI modifications: gnutls_x509_crt_set_issuer_unique_id: Added gnutls_x509_crt_set_subject_unique_id: Added gnutls_certificate_set_flags: Added GNUTLS_CERTIFICATE_SKIP_KEY_CERT_MATCH: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.7.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From bkorb at gnu.org Wed Nov 18 22:25:33 2015 From: bkorb at gnu.org (Bruce Korb) Date: Wed, 18 Nov 2015 21:25:33 -0000 Subject: [gnutls-help] Error using certtool with config file on Win32 In-Reply-To: <564B3441.8070109@ib-weinhardt.de> References: <56460FBE.8030209@ib-weinhardt.de> <1447577750.18823.2.camel@gmail.com> <56488AF9.7070406@ib-weinhardt.de> <564B3441.8070109@ib-weinhardt.de> Message-ID: <564CE66C.5040106@gnu.org> On 11/17/15 06:05, J?rg Weinhardt wrote: > Hello Nikos, I think I've mentioned that I am not a Windows fan. Anyway, the next release will have this: diff --git a/autoopts/text_mmap.c b/autoopts/text_mmap.c index 07c0bf1..23c8658 100644 --- a/autoopts/text_mmap.c +++ b/autoopts/text_mmap.c @@ -185,7 +185,11 @@ validate_mmap(char const * fname, int prot, int flag s, tmap_info_t * mapinfo) * then our updates will show in the file, so we must open with * write access. */ - int o_flag = FILE_WRITABLE(prot, flags) ? O_RDWR : O_RDONLY; + int o_flag = +#ifdef _WIN32 + O_BINARY | +#endif + FILE_WRITABLE(prot, flags) ? O_RDWR : O_RDONLY; /* * If you're not sharing the file and you are writing to it, From luis.marsano at gmail.com Sat Nov 28 20:02:05 2015 From: luis.marsano at gmail.com (Luis Marsano) Date: Sat, 28 Nov 2015 19:02:05 -0000 Subject: [gnutls-help] certtool not outputting requested key usage Message-ID: certtool isn't allowing me to create certificates with key usages I specify. Sample shell session $ certtool --version certtool 3.3.17 ? $ certtool --ecc --sec-param high --generate-privkey --outfile key.pem Generating a 256 bit EC private key... $ echo 'cn = test encryption_key' >ss.conf $ certtool --generate-self-signed --load-privkey key.pem --template ss.conf Generating a self signed certificate... ? Key Usage (critical): Digital signature. Subject Key Identifier (not critical): ? I'm not getting the key encipherment I'm asking for. What am I doing wrong?