From kurt at roeckx.be Sun Jun 1 12:44:09 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Jun 2014 12:44:09 +0200 Subject: [gnutls-devel] Restrictions on tag types Message-ID: <20140601104409.GA26651@roeckx.be> Hi, In lib/x509/common.c there is this: [...] ENTRY("2.5.4.6", "C", NULL, ASN1_ETYPE_PRINTABLE_STRING), ENTRY("2.5.4.9", "street", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), ENTRY("2.5.4.12", "title", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), ENTRY("2.5.4.10", "O", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), [...] I'm seeing certificates that encode the "C" with an UTF8String and not a PrintableString, which then result in getting an error that it has invalid DER. "C" can of course only contain a certain amount of characters. But I don't see why it shouldn't be allowed to encode this is whatever charset they want. Since they should use either PrintableString or UTF8String in a DN it makes sense to me that they would do everything in UTF8String even when not needed. Is there a good reason to only allow PrintableString? Kurt From nmav at gnutls.org Sun Jun 1 19:48:28 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 01 Jun 2014 19:48:28 +0200 Subject: [gnutls-devel] Restrictions on tag types In-Reply-To: <20140601104409.GA26651@roeckx.be> References: <20140601104409.GA26651@roeckx.be> Message-ID: <1401644908.13554.3.camel@nomad.lan> On Sun, 2014-06-01 at 12:44 +0200, Kurt Roeckx wrote: > Hi, > > In lib/x509/common.c there is this: > [...] > ENTRY("2.5.4.6", "C", NULL, ASN1_ETYPE_PRINTABLE_STRING), > ENTRY("2.5.4.9", "street", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > ENTRY("2.5.4.12", "title", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > ENTRY("2.5.4.10", "O", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > [...] > I'm seeing certificates that encode the "C" with an UTF8String and > not a PrintableString, which then result in getting an error that > it has invalid DER. It is invalid encoding as RFC5280 specifies: X520countryName ::= PrintableString How common are these certificates? Are they so widespread we would need to add support for them? > "C" can of course only contain a certain amount of characters. But > I don't see why it shouldn't be allowed to encode this is whatever > charset they want. Since they should use either PrintableString > or UTF8String in a DN it makes sense to me that they would do > everything in UTF8String even when not needed. > Is there a good reason to only allow PrintableString? We just follow the protocol :) The names that allow multiple encodings are encoded as DirectoryString not as PrintableString. regards, Nikos From kurt at roeckx.be Sun Jun 1 19:59:43 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Jun 2014 19:59:43 +0200 Subject: [gnutls-devel] Restrictions on tag types In-Reply-To: <1401644908.13554.3.camel@nomad.lan> References: <20140601104409.GA26651@roeckx.be> <1401644908.13554.3.camel@nomad.lan> Message-ID: <20140601175943.GA3434@roeckx.be> On Sun, Jun 01, 2014 at 07:48:28PM +0200, Nikos Mavrogiannopoulos wrote: > On Sun, 2014-06-01 at 12:44 +0200, Kurt Roeckx wrote: > > Hi, > > > > In lib/x509/common.c there is this: > > [...] > > ENTRY("2.5.4.6", "C", NULL, ASN1_ETYPE_PRINTABLE_STRING), > > ENTRY("2.5.4.9", "street", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > > ENTRY("2.5.4.12", "title", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > > ENTRY("2.5.4.10", "O", "PKIX1.DirectoryString", ASN1_ETYPE_INVALID), > > [...] > > I'm seeing certificates that encode the "C" with an UTF8String and > > not a PrintableString, which then result in getting an error that > > it has invalid DER. > > It is invalid encoding as RFC5280 specifies: > X520countryName ::= PrintableString I guess I have missed that. Thanks. I guess this is something I'll add to my list of tests at some point. > How common are these certificates? Are they so widespread we would need > to add support for them? So for I only know about 1 such issuer. And it's in the DN of the issuer itself so they would need to create a new CA. Kurt From kurt at roeckx.be Sun Jun 1 22:50:08 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Jun 2014 22:50:08 +0200 Subject: [gnutls-devel] CRLs Message-ID: <20140601205008.GA7905@roeckx.be> Hi, I'm currently importing CRLs, and currently have 2 issues: - Dealing with CRLs is really slow. Currently waiting 20 minutes for the output of: certtool --infile file.crl --inder -l Which is a 5 MB file. It only seems to be allocating memory during that time. - There seems to be a gnutls_x509_crl_reason_flags_t, but there doesn't seem to be any function that can return it. Kurt From kurt at roeckx.be Sun Jun 1 22:54:21 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 1 Jun 2014 22:54:21 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: <20140601205008.GA7905@roeckx.be> References: <20140601205008.GA7905@roeckx.be> Message-ID: <20140601205421.GA8608@roeckx.be> On Sun, Jun 01, 2014 at 10:50:08PM +0200, Kurt Roeckx wrote: > Hi, > > I'm currently importing CRLs, and currently have 2 issues: > - Dealing with CRLs is really slow. Currently waiting 20 > minutes for the output of: > certtool --infile file.crl --inder -l > Which is a 5 MB file. It only seems to be allocating memory > during that time. I think one of the problem might be that calling gnutls_x509_crl_get_crt_serial() starts from 0 each time and needs to walk all elements in between to find the serial it needs. Kurt From nmav at gnutls.org Mon Jun 2 08:31:58 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Jun 2014 08:31:58 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: <20140601205421.GA8608@roeckx.be> References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> Message-ID: On Sun, Jun 1, 2014 at 10:54 PM, Kurt Roeckx wrote: > On Sun, Jun 01, 2014 at 10:50:08PM +0200, Kurt Roeckx wrote: > > Hi, > > > > I'm currently importing CRLs, and currently have 2 issues: > > - Dealing with CRLs is really slow. Currently waiting 20 > > minutes for the output of: > > certtool --infile file.crl --inder -l > > Which is a 5 MB file. It only seems to be allocating memory > > during that time. > I think one of the problem might be that calling > gnutls_x509_crl_get_crt_serial() starts from 0 each time and > needs to walk all elements in between to find the serial it needs. > Do you mean the asn1_read_value() walk? How many elements are in the CRL in question? regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Mon Jun 2 08:45:41 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 2 Jun 2014 08:45:41 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> Message-ID: <20140602064541.GA17704@roeckx.be> On Mon, Jun 02, 2014 at 08:31:58AM +0200, Nikos Mavrogiannopoulos wrote: > On Sun, Jun 1, 2014 at 10:54 PM, Kurt Roeckx wrote: > > > On Sun, Jun 01, 2014 at 10:50:08PM +0200, Kurt Roeckx wrote: > > > Hi, > > > > > > I'm currently importing CRLs, and currently have 2 issues: > > > - Dealing with CRLs is really slow. Currently waiting 20 > > > minutes for the output of: > > > certtool --infile file.crl --inder -l > > > Which is a 5 MB file. It only seems to be allocating memory > > > during that time. > > I think one of the problem might be that calling > > gnutls_x509_crl_get_crt_serial() starts from 0 each time and > > needs to walk all elements in between to find the serial it needs. > > > > Do you mean the asn1_read_value() walk? How many elements are in the CRL in > question? I have some with over 100K entries. Kurt From nmav at gnutls.org Mon Jun 2 10:52:54 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 2 Jun 2014 10:52:54 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: <20140602064541.GA17704@roeckx.be> References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> Message-ID: On Mon, Jun 2, 2014 at 8:45 AM, Kurt Roeckx wrote: > > Do you mean the asn1_read_value() walk? How many elements are in the CRL > in > > question? > I have some with over 100K entries. > It would really help to have some cachegrind/perf results or a way to reproduce that. I'm working on some optimizations in libtasn1, and that could be part of it. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Mon Jun 2 18:18:49 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 2 Jun 2014 18:18:49 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> Message-ID: <20140602161849.GA25478@roeckx.be> On Mon, Jun 02, 2014 at 10:52:54AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, Jun 2, 2014 at 8:45 AM, Kurt Roeckx wrote: > > > > Do you mean the asn1_read_value() walk? How many elements are in the CRL > > in > > > question? > > I have some with over 100K entries. > > > > It would really help to have some cachegrind/perf results or a way to > reproduce that. I'm working on some optimizations in libtasn1, and that > could be part of it. This are all public CRLs that I downloaded. You can see a list of CRLs at https://isc.sans.edu/crls.html. You can pick the size that you want there. Kurt From dkg at fifthhorseman.net Tue Jun 3 00:33:40 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 02 Jun 2014 18:33:40 -0400 Subject: [gnutls-devel] Bug#750094: Misleading warning In-Reply-To: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> References: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> Message-ID: <538CFBC4.9040902@fifthhorseman.net> over on https://bugs.debian.org/750094, On 06/01/2014 10:01 AM, Juliusz Chroboczek wrote: > Package: gnutls-bin > Version: 3.2.14-1 > > Try the following: > > gnutls-cli --dh-bits 256 --starttls -p 80 www.debian.org > > It prints the following warning: > > |<1>| Note that the security level of the Diffie-Hellman key exchange > has been lowered to 256 bits and this may allow decryption of the > session data > > This warning is printed before any TLS negotiation happens, so it does not > reflect the parameters that were actually negotiated. The wording should > be changed in order to make it clear that the actual negotiated parameters > might be different. this can be replicated without the --starttls or -p 80, just with: gnutls-cli --dh-bits 256 www.debian.org the warning happens before the TLS handshake happens. I'm forwarding this to the gnutls-devel mailing list. It seems to me there could be two different kinds of warnings: 0) a warning that the configuration has lowered the DH key exchange strength and may cause weakness (what we're seeing here) -- Juliusz, can you propose an alternate text for this warning? 1) a warning in the _gnutls_audit_log when the dh bits is *actually* lower than whatever cutoff we deem to be absurdly unacceptable. I worry a little bit about either warning, mainly because it seems to imply that anything higher than 512 bits *won't* allow decryption of the session data, which probably isn't the case for, say, a 513-bit group :P Nikos, any thoughts on what makes sense to do here? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Wed Jun 4 09:30:42 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Jun 2014 09:30:42 +0200 Subject: [gnutls-devel] Bug#750094: Misleading warning In-Reply-To: <538CFBC4.9040902@fifthhorseman.net> References: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> <538CFBC4.9040902@fifthhorseman.net> Message-ID: On Tue, Jun 3, 2014 at 12:33 AM, Daniel Kahn Gillmor wrote: > over on https://bugs.debian.org/750094, >> This warning is printed before any TLS negotiation happens, so it does not >> reflect the parameters that were actually negotiated. The wording should >> be changed in order to make it clear that the actual negotiated parameters >> might be different. > this can be replicated without the --starttls or -p 80, just with: > gnutls-cli --dh-bits 256 www.debian.org > the warning happens before the TLS handshake happens. > I'm forwarding this to the gnutls-devel mailing list. > It seems to me there could be two different kinds of warnings: > 0) a warning that the configuration has lowered the DH key exchange > strength and may cause weakness (what we're seeing here) -- Juliusz, can > you propose an alternate text for this warning? > 1) a warning in the _gnutls_audit_log when the dh bits is *actually* > lower than whatever cutoff we deem to be absurdly unacceptable. I agree with your points. In fact the current warning was setup to cover (0). There could be another warning for (1), but gnutls-cli prints the size of the prime anyway if DHE is negotiated so I'm not sure how much another warning would help. > I worry a little bit about either warning, mainly because it seems to > imply that anything higher than 512 bits *won't* allow decryption of the > session data, which probably isn't the case for, say, a 513-bit group :P > Nikos, any thoughts on what makes sense to do here? I've put that warning once I saw people arguing in various fora to set dh-bits less than 256 bits in order to improve compatibility. Indeed 513 is not much more secure, and the warning could be changed to less than 700 or so. regards, Nikos From nmav at gnutls.org Wed Jun 4 11:38:55 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Jun 2014 11:38:55 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: <20140602161849.GA25478@roeckx.be> References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> <20140602161849.GA25478@roeckx.be> Message-ID: On Mon, Jun 2, 2014 at 6:18 PM, Kurt Roeckx wrote: >> It would really help to have some cachegrind/perf results or a way to >> reproduce that. I'm working on some optimizations in libtasn1, and that >> could be part of it. > This are all public CRLs that I downloaded. You can see a list > of CRLs at https://isc.sans.edu/crls.html. You can pick the size > that you want there. I've optimized some things in libtasn1 but the times were so bad that are insignificant. 50% of the time is spent on decoding (I guess that is expected as a large tree, is a large tree), and the other 50% on reading the individual values. My change gave a speedup on the decoding part by caching some values and drops it to 30% of the total time. However, to get further improvements an API change is required, i.e., an iterator based function to read values for large sequences or sets that are read in a serialized way. regards, Nikos From nmav at gnutls.org Wed Jun 4 15:16:48 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Jun 2014 15:16:48 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> <20140602161849.GA25478@roeckx.be> Message-ID: On Wed, Jun 4, 2014 at 11:38 AM, Nikos Mavrogiannopoulos wrote: > However, to get further improvements an API change is required, i.e., > an iterator based function to read values for large sequences or sets > that are read in a serialized way. It seems that using the low-level API of libtasn1 could help. I've managed to reduce to 1/3 of the running time using some caching, but unfortunately it requires a new function as it would change the semantics of gnutls_x509_crl_get_crt_serial(). Nevertheless the time for the command time ./certtool --outfile /dev/null --inder --crl-info < gsorganizationvalg2.crl user 29m23.138s when converted to gnutls_x509_crl_get_crt_serial2() reduces to: user 9m10.781s regards, Nikos From nmav at gnutls.org Wed Jun 4 17:45:40 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Jun 2014 17:45:40 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> <20140602161849.GA25478@roeckx.be> Message-ID: On Wed, Jun 4, 2014 at 3:16 PM, Nikos Mavrogiannopoulos wrote: > On Wed, Jun 4, 2014 at 11:38 AM, Nikos Mavrogiannopoulos > wrote: >> However, to get further improvements an API change is required, i.e., >> an iterator based function to read values for large sequences or sets >> that are read in a serialized way. > It seems that using the low-level API of libtasn1 could help. I've > managed to reduce to 1/3 of the running time using some caching, but > unfortunately it requires a new function as it would change the > semantics of gnutls_x509_crl_get_crt_serial(). Nevertheless the time > for the command > time ./certtool --outfile /dev/null --inder --crl-info < gsorganizationvalg2.crl > user 29m23.138s > when converted to gnutls_x509_crl_get_crt_serial2() reduces to: > user 9m10.781s And that drops to one second using the libtasn1 from git. regards, Nikos From dkg at fifthhorseman.net Wed Jun 4 17:50:15 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 04 Jun 2014 11:50:15 -0400 Subject: [gnutls-devel] Bug#750094: Misleading warning In-Reply-To: References: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> <538CFBC4.9040902@fifthhorseman.net> Message-ID: <538F4037.1080903@fifthhorseman.net> On 06/04/2014 03:30 AM, Nikos Mavrogiannopoulos wrote: > I agree with your points. In fact the current warning was setup to > cover (0). There could be another warning for (1), but gnutls-cli > prints the size of the prime anyway if DHE is negotiated so I'm not > sure how much another warning would help. I was thinking it'd be useful in that a warning is distinct from a routine printout. people with their own sense of what a threshhold should be can work from the routine information; but if we're providing a distinct warning, it would be for people who aren't making those kinds of decisions explicitly. > I've put that warning once I saw people arguing in various fora to set > dh-bits less than 256 bits in order to improve compatibility. Indeed > 513 is not much more secure, and the warning could be changed to less > than 700 or so. yeah, choosing a threshhold is hard, and probably would need to change over time, but at the moment, we have some concrete recommendations we can use. For example, ECRYPT II's 2011-2012 report suggests on page 30 that defense against just small/medium organizations to preserve confidentiality for a few months should be around 70 bits (symmetric-equivalent), which means a DLOG group a bit below 1024 bits. We could even use the ECRYPT language in the warning. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From kurt at roeckx.be Wed Jun 4 18:25:09 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 4 Jun 2014 18:25:09 +0200 Subject: [gnutls-devel] CRLs In-Reply-To: References: <20140601205008.GA7905@roeckx.be> <20140601205421.GA8608@roeckx.be> <20140602064541.GA17704@roeckx.be> <20140602161849.GA25478@roeckx.be> Message-ID: <20140604162509.GA12563@roeckx.be> On Wed, Jun 04, 2014 at 05:45:40PM +0200, Nikos Mavrogiannopoulos wrote: > On Wed, Jun 4, 2014 at 3:16 PM, Nikos Mavrogiannopoulos wrote: > > On Wed, Jun 4, 2014 at 11:38 AM, Nikos Mavrogiannopoulos > > wrote: > >> However, to get further improvements an API change is required, i.e., > >> an iterator based function to read values for large sequences or sets > >> that are read in a serialized way. > > It seems that using the low-level API of libtasn1 could help. I've > > managed to reduce to 1/3 of the running time using some caching, but > > unfortunately it requires a new function as it would change the > > semantics of gnutls_x509_crl_get_crt_serial(). Nevertheless the time > > for the command > > time ./certtool --outfile /dev/null --inder --crl-info < gsorganizationvalg2.crl > > user 29m23.138s > > when converted to gnutls_x509_crl_get_crt_serial2() reduces to: > > user 9m10.781s > > And that drops to one second using the libtasn1 from git. That sound great. Thanks. Kurt From jch at pps.univ-paris-diderot.fr Wed Jun 4 23:29:56 2014 From: jch at pps.univ-paris-diderot.fr (Juliusz Chroboczek) Date: Wed, 04 Jun 2014 23:29:56 +0200 Subject: [gnutls-devel] Bug#750094: Misleading warning In-Reply-To: <538CFBC4.9040902@fifthhorseman.net> References: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> <538CFBC4.9040902@fifthhorseman.net> Message-ID: <87oay8gy7f.wl%jch@pps.univ-paris-diderot.fr> Hi Daniel, nice to meet you. >> |<1>| Note that the security level of the Diffie-Hellman key exchange >> has been lowered to 256 bits and this may allow decryption of the >> session data > 0) a warning that the configuration has lowered the DH key exchange > strength and may cause weakness (what we're seeing here) -- Juliusz, can > you propose an alternate text for this warning? Note that the current configuration of either gnutls or your client software allows Diffie-Hellman key exchange to succeed with as little as 256 bits, which is not enough to guarantee a reasonable level of security. Please reconfigure gnutls or your client software with a more reasonable value (at least 1024, preferably 2048 or more). Please tweak the values at will, I'm not a crypto specialist. > 1) a warning in the _gnutls_audit_log when the dh bits is *actually* > lower than whatever cutoff we deem to be absurdly unacceptable. Yes, that would be helpful. > I worry a little bit about either warning, mainly because it seems to > imply that anything higher than 512 bits *won't* allow decryption of the > session data, which probably isn't the case for, say, a 513-bit group :P Very true, hence the "at least 1024, prerefably 2048 or more" in the suggested message above. -- Juliusz From anisimkov at ada-ru.org Fri Jun 6 08:53:05 2014 From: anisimkov at ada-ru.org (Dmitriy Anisimkov) Date: Fri, 06 Jun 2014 13:53:05 +0700 Subject: [gnutls-devel] turkish CA certificate Message-ID: <53916551.4050604@ada-ru.org> I got this certificate from OpenSUSE repository packageca-certificates-mozilla, I guess it is trusted and public available. OpenSSL shows it correctly openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt -text -noout But GNUTLS command certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i gives 2 errors error: get_issuer_dn: ASN1 parser: Error in DER parsing. error: get_dn: ASN1 parser: Error in DER parsing. I tried it on OS provided gnutls and on compiled from git master last commit commit 1eea0fbaa80d72fe35f9c9753e42eb4af7092325 Author: Nikos Mavrogiannopoulos Date: Thu Jun 5 10:50:11 2014 +0200 -------------- next part -------------- A non-text attachment was scrubbed... Name: TURKTRUST_Certificate_Services_Provider_Root_1.pem Type: application/x-pem-file Size: 1440 bytes Desc: not available URL: From nmav at gnutls.org Fri Jun 6 10:07:30 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Jun 2014 10:07:30 +0200 Subject: [gnutls-devel] turkish CA certificate In-Reply-To: <53916551.4050604@ada-ru.org> References: <53916551.4050604@ada-ru.org> Message-ID: On Fri, Jun 6, 2014 at 8:53 AM, Dmitriy Anisimkov wrote: > I got this certificate from OpenSUSE repository > packageca-certificates-mozilla, > I guess it is trusted and public available. > OpenSSL shows it correctly > openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt > -text -noout > But GNUTLS command > certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i Hello, This must be the same certificate Kurt reported few days ago. It mis-encodes the country name as UTF8String rather than printable string, and this is the reason decoding fails. RFC5280 is strict on the encoding of countryName and that is a PrintableString: X520countryName ::= PrintableString (SIZE (2)) I guess all other implementations give some slack to the spec and that's why they didn't notice. How important is that certificate would it make sense to work around and allow such invalid encodings? regards, Nikos From nmav at gnutls.org Fri Jun 6 10:24:48 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 6 Jun 2014 10:24:48 +0200 Subject: [gnutls-devel] turkish CA certificate In-Reply-To: References: <53916551.4050604@ada-ru.org> Message-ID: On Fri, Jun 6, 2014 at 10:07 AM, Nikos Mavrogiannopoulos wrote: >> I guess it is trusted and public available. >> OpenSSL shows it correctly >> openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt >> -text -noout >> But GNUTLS command >> certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i > Hello, > This must be the same certificate Kurt reported few days ago. It > mis-encodes the country name as UTF8String rather than printable > string, and this is the reason decoding fails. > RFC5280 is strict on the encoding of countryName and that is a PrintableString: > X520countryName ::= PrintableString (SIZE (2)) > I guess all other implementations give some slack to the spec and > that's why they didn't notice. How important is that certificate would > it make sense to work around and allow such invalid encodings? I think there is a good work-around. I've modified gnutls' DN decoding to treat invalid encodings as unsupported elements, thus the country name will be printed using the hex notation (see below). CN=T?RKTRUST Elektronik Sertifika Hizmet Sa?lay?c?s?,C=#0c025452,L=ANKARA,O=(c) 2005 T?RKTRUST Bilgi ?leti?im ve Bili?im G?venli?i Hizmetleri A.?. regards, Nikos From anisimkov at ada-ru.org Fri Jun 6 10:30:25 2014 From: anisimkov at ada-ru.org (Dmitriy Anisimkov) Date: Fri, 06 Jun 2014 15:30:25 +0700 Subject: [gnutls-devel] turkish CA certificate In-Reply-To: References: <53916551.4050604@ada-ru.org> Message-ID: <53917C21.2010008@ada-ru.org> On 2014-06-06 15:24, Nikos Mavrogiannopoulos wrote: > On Fri, Jun 6, 2014 at 10:07 AM, Nikos Mavrogiannopoulos > wrote: >>> I guess it is trusted and public available. >>> OpenSSL shows it correctly >>> openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt >>> -text -noout >>> But GNUTLS command >>> certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i >> Hello, >> This must be the same certificate Kurt reported few days ago. It >> mis-encodes the country name as UTF8String rather than printable >> string, and this is the reason decoding fails. >> RFC5280 is strict on the encoding of countryName and that is a PrintableString: >> X520countryName ::= PrintableString (SIZE (2)) >> I guess all other implementations give some slack to the spec and >> that's why they didn't notice. How important is that certificate would >> it make sense to work around and allow such invalid encodings? > I think there is a good work-around. I've modified gnutls' DN decoding > to treat invalid encodings as unsupported elements, thus the country > name will be printed using the hex notation (see below). > CN=T?RKTRUST Elektronik Sertifika Hizmet > Sa?lay?c?s?,C=#0c025452,L=ANKARA,O=(c) 2005 T?RKTRUST Bilgi ?leti?im > ve Bili?im G?venli?i Hizmetleri A.?. Ok. Thanks,, Frankly it was not critical for me, I just tested my certificates container by the public available certificates and found this wrong certificate. Best Regargs, Dimitriy From ludwig.nussel at suse.de Fri Jun 6 15:59:51 2014 From: ludwig.nussel at suse.de (Ludwig Nussel) Date: Fri, 06 Jun 2014 15:59:51 +0200 Subject: [gnutls-devel] turkish CA certificate In-Reply-To: References: <53916551.4050604@ada-ru.org> Message-ID: <5391C957.3080205@suse.de> Nikos Mavrogiannopoulos wrote: > On Fri, Jun 6, 2014 at 8:53 AM, Dmitriy Anisimkov wrote: >> I got this certificate from OpenSUSE repository >> packageca-certificates-mozilla, >> I guess it is trusted and public available. >> OpenSSL shows it correctly >> openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt >> -text -noout >> But GNUTLS command >> certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i > > Hello, > This must be the same certificate Kurt reported few days ago. It > mis-encodes the country name as UTF8String rather than printable > string, and this is the reason decoding fails. > RFC5280 is strict on the encoding of countryName and that is a PrintableString: > X520countryName ::= PrintableString (SIZE (2)) > > I guess all other implementations give some slack to the spec and > that's why they didn't notice. How important is that certificate would > it make sense to work around and allow such invalid encodings? If the certificate violates the spec it might also be worth reporting to mozilla so they don't accept such certificates in the first place. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From kurt at roeckx.be Fri Jun 6 18:11:59 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 6 Jun 2014 18:11:59 +0200 Subject: [gnutls-devel] turkish CA certificate In-Reply-To: <5391C957.3080205@suse.de> References: <53916551.4050604@ada-ru.org> <5391C957.3080205@suse.de> Message-ID: <20140606161159.GA4735@roeckx.be> On Fri, Jun 06, 2014 at 03:59:51PM +0200, Ludwig Nussel wrote: > Nikos Mavrogiannopoulos wrote: > >On Fri, Jun 6, 2014 at 8:53 AM, Dmitriy Anisimkov wrote: > >>I got this certificate from OpenSUSE repository > >>packageca-certificates-mozilla, > >>I guess it is trusted and public available. > >>OpenSSL shows it correctly > >>openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt > >>-text -noout > >>But GNUTLS command > >>certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i > > > >Hello, > > This must be the same certificate Kurt reported few days ago. It > >mis-encodes the country name as UTF8String rather than printable > >string, and this is the reason decoding fails. > >RFC5280 is strict on the encoding of countryName and that is a PrintableString: > >X520countryName ::= PrintableString (SIZE (2)) > > > >I guess all other implementations give some slack to the spec and > >that's why they didn't notice. How important is that certificate would > >it make sense to work around and allow such invalid encodings? > > If the certificate violates the spec it might also be worth reporting to > mozilla so they don't accept such certificates in the first place. This is actually on my list of things to do. I think have found a 2nd issuer but didn't have time to look at it yet. Kurt From home_pw at msn.com Fri Jun 6 18:14:39 2014 From: home_pw at msn.com (Peter Williams) Date: Fri, 6 Jun 2014 09:14:39 -0700 Subject: [gnutls-devel] turkish CA certificate Message-ID: More likely its a signature for traffic isolation. Sent from my Windows Phone ________________________________ From: Kurt Roeckx Sent: ?6/?6/?2014 9:12 AM To: Ludwig Nussel Cc: gnutls-devel at lists.gnutls.org Subject: Re: [gnutls-devel] turkish CA certificate On Fri, Jun 06, 2014 at 03:59:51PM +0200, Ludwig Nussel wrote: > Nikos Mavrogiannopoulos wrote: > >On Fri, Jun 6, 2014 at 8:53 AM, Dmitriy Anisimkov wrote: > >>I got this certificate from OpenSUSE repository > >>packageca-certificates-mozilla, > >>I guess it is trusted and public available. > >>OpenSSL shows it correctly > >>openssl x509 -in TURKTRUST_Certificate_Services_Provider_Root_1.pem.crt > >>-text -noout > >>But GNUTLS command > >>certtool --infile TURKTRUST_Certificate_Services_Provider_Root_1.pem -i > > > >Hello, > > This must be the same certificate Kurt reported few days ago. It > >mis-encodes the country name as UTF8String rather than printable > >string, and this is the reason decoding fails. > >RFC5280 is strict on the encoding of countryName and that is a PrintableString: > >X520countryName ::= PrintableString (SIZE (2)) > > > >I guess all other implementations give some slack to the spec and > >that's why they didn't notice. How important is that certificate would > >it make sense to work around and allow such invalid encodings? > > If the certificate violates the spec it might also be worth reporting to > mozilla so they don't accept such certificates in the first place. This is actually on my list of things to do. I think have found a 2nd issuer but didn't have time to look at it yet. Kurt _______________________________________________ Gnutls-devel mailing list Gnutls-devel at lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpbion at jfwest.com Mon Jun 9 00:27:17 2014 From: jpbion at jfwest.com (Joel Bion) Date: Sun, 8 Jun 2014 15:27:17 -0700 Subject: [gnutls-devel] Nettle 3.0 merges count_high/count_low into 64-bit count in many cases Message-ID: <180233aae85b5f98c30f358f1b362d77.squirrel@jfroot.com> This makes GnuTLS no longer compile: CC sha-padlock.lo In file included from sha-padlock.c:29:0: sha-padlock.c: In function 'padlock_sha1_update': sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_high' MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); ...look at /usr/include/nettle/sha1.h to see the definition of sha1_ctx Looks like some of the GnuTLS code that assumes the count is in two parts needs to deal with the fact it now is in one part? -Joel ^ From nmav at gnutls.org Mon Jun 9 09:44:36 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Jun 2014 09:44:36 +0200 Subject: [gnutls-devel] Nettle 3.0 merges count_high/count_low into 64-bit count in many cases In-Reply-To: <180233aae85b5f98c30f358f1b362d77.squirrel@jfroot.com> References: <180233aae85b5f98c30f358f1b362d77.squirrel@jfroot.com> Message-ID: On Mon, Jun 9, 2014 at 12:27 AM, Joel Bion wrote: > This makes GnuTLS no longer compile: > CC sha-padlock.lo > In file included from sha-padlock.c:29:0: > sha-padlock.c: In function 'padlock_sha1_update': > sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named > 'count_high' > MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); > ...look at /usr/include/nettle/sha1.h to see the definition of sha1_ctx > Looks like some of the GnuTLS code that assumes the count is in two parts > needs to deal with the fact it now is in one part? Hello, Most probably the code needs to be updated or we could just copy these definitions from the older nettle. Nettle 3.0 broke API and ABI and porting gnutls to it would take some time. As its API and ABI aren't stable yet and there are no new features we urgently need from it, porting to it is not on my immediate plans. regards, Nikos From nmav at gnutls.org Mon Jun 9 16:18:51 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Jun 2014 16:18:51 +0200 Subject: [gnutls-devel] Bug#750094: Misleading warning In-Reply-To: <538F4037.1080903@fifthhorseman.net> References: <877g50wwy0.wl%jch@pps.univ-paris-diderot.fr> <538CFBC4.9040902@fifthhorseman.net> <538F4037.1080903@fifthhorseman.net> Message-ID: On Wed, Jun 4, 2014 at 5:50 PM, Daniel Kahn Gillmor wrote: > On 06/04/2014 03:30 AM, Nikos Mavrogiannopoulos wrote: >> I agree with your points. In fact the current warning was setup to >> cover (0). There could be another warning for (1), but gnutls-cli >> prints the size of the prime anyway if DHE is negotiated so I'm not >> sure how much another warning would help. > I was thinking it'd be useful in that a warning is distinct from a > routine printout. people with their own sense of what a threshhold > should be can work from the routine information; but if we're providing > a distinct warning, it would be for people who aren't making those kinds > of decisions explicitly. That got pretty low on my todo list, if there is any patch on that I'll review it, but not planning in adding it myself. > yeah, choosing a threshhold is hard, and probably would need to change > over time, but at the moment, we have some concrete recommendations we > can use. > For example, ECRYPT II's 2011-2012 report suggests on page 30 that > defense against just small/medium organizations to preserve > confidentiality for a few months should be around 70 bits > (symmetric-equivalent), which means a DLOG group a bit below 1024 bits. > We could even use the ECRYPT language in the warning. I've now tied the warning to the security levels we have (and specifically the very weak one). regards, Nikos From jpbion at jfwest.com Mon Jun 9 17:13:07 2014 From: jpbion at jfwest.com (jpbion at jfwest.com) Date: Mon, 09 Jun 2014 08:13:07 -0700 Subject: [gnutls-devel] =?utf-8?q?Nettle_3=2E0_merges_count=5Fhigh/count?= =?utf-8?q?=5Flow_into_64-bit_count_in_many_cases?= In-Reply-To: References: <180233aae85b5f98c30f358f1b362d77.squirrel@jfroot.com> Message-ID: Nikos - Thank you for the reply. I am quite surprised at the choices of the Nettle team. The projects in the GNU tool-chain should be friends, and I cannot imagine a more important client of Nettle's then GNUTLS. To go and remove compatibility with prior versions, and not even coordinate it with their most important client just seems to be a poor decision from the Nettle team, at least in my opinion. -Joel On 2014-06-09 00:44, Nikos Mavrogiannopoulos wrote: > On Mon, Jun 9, 2014 at 12:27 AM, Joel Bion wrote: >> This makes GnuTLS no longer compile: >> CC sha-padlock.lo >> In file included from sha-padlock.c:29:0: >> sha-padlock.c: In function 'padlock_sha1_update': >> sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named >> 'count_high' >> MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); >> ...look at /usr/include/nettle/sha1.h to see the definition of >> sha1_ctx >> Looks like some of the GnuTLS code that assumes the count is in two >> parts >> needs to deal with the fact it now is in one part? > > Hello, > Most probably the code needs to be updated or we could just copy > these definitions from the older nettle. Nettle 3.0 broke API and ABI > and porting gnutls to it would take some time. As its API and ABI > aren't stable yet and there are no new features we urgently need from > it, porting to it is not on my immediate plans. > > regards, > Nikos From nmav at gnutls.org Mon Jun 9 17:20:46 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Jun 2014 17:20:46 +0200 Subject: [gnutls-devel] Nettle 3.0 merges count_high/count_low into 64-bit count in many cases In-Reply-To: References: <180233aae85b5f98c30f358f1b362d77.squirrel@jfroot.com> Message-ID: On Mon, Jun 9, 2014 at 5:13 PM, wrote: > Nikos - > Thank you for the reply. I am quite surprised at the choices of the Nettle > team. The projects in the GNU tool-chain should be friends, and I cannot > imagine a more important client of Nettle's then GNUTLS. To go and remove > compatibility with prior versions, and not even coordinate it with their > most important client just seems to be a poor decision from the Nettle team, > at least in my opinion. Well, there has been quite some feedback provided by me in nettle, so I don't think that there is no co-ordination. While we strive for stable APIs, there are often inefficiencies in designs that need now and then to be dropped (and that's what Niels is doing in nettle 3.0). I can certainly understand that (although I may not like it). We will eventually use it in gnutls, but that would be after 3.3 is declared as stable (on the 3.4 branch, hopefully with the new chacha cipher). regards, Nikos From amr_mahmoud38 at yahoo.com Fri Jun 13 15:53:22 2014 From: amr_mahmoud38 at yahoo.com (=?utf-8?B?2LnZhdix2Ygg2YPZhdin2YQg2KfZhNiv2YrZhiDYqNi02LEg2YXYrdmF2Yg=?= =?utf-8?B?2K8=?=) Date: Fri, 13 Jun 2014 14:53:22 +0100 (BST) Subject: [gnutls-devel] trying to compile gntls latest version Message-ID: <1402667602.94196.YahooMailNeo@web28906.mail.ir2.yahoo.com> hi every one? , as I was trying to build the latest version? of gnutls version 3? ,? I first made the this step 1- ./configure? 2- make? I got the following error? ?CC?????? sha-padlock.lo In file included from sha-padlock.c:29:0: sha-padlock.c: In function 'padlock_sha1_update': sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_high' ? MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); ????????????????????????????????????????????? ^ sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_low' ? MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); ????????????????????????????????????????????? ^ sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_high' ? MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); ????????????????????????????????????????????? ^ sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_low' ? MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); ????????????????????????????????????????????? ^ sha-padlock.c: In function 'padlock_sha256_update': sha-padlock.c:88:48: error: 'struct sha256_ctx' has no member named 'count_high' ? MD_UPDATE(ctx, length, data, SHA256_COMPRESS, MD_INCR(ctx)); ??????????????????????????????????????????????? ^ sha-padlock.c:88:48: error: 'struct sha256_ctx' has no member named 'count_low' ? MD_UPDATE(ctx, length, data, SHA256_COMPRESS, MD_INCR(ctx)); ??????????????????????????????????????????????? ^ sha-padlock.c:88:48: error: 'struct sha256_ctx' has no member named 'count_high' ? MD_UPDATE(ctx, length, data, SHA256_COMPRESS, MD_INCR(ctx)); ??????????????????????????????????????????????? ^ sha-padlock.c:88:48: error: 'struct sha256_ctx' has no member named 'count_low' ? MD_UPDATE(ctx, length, data, SHA256_COMPRESS, MD_INCR(ctx)); ??????????????????????????????????????????????? ^ sha-padlock.c: In function 'padlock_sha1_digest': sha-padlock.c:143:13: error: 'struct sha1_ctx' has no member named 'count_high' ? high = (ctx->count_high << 9) | (ctx->count_low >> 23); ???????????? ^ sha-padlock.c:143:38: error: 'struct sha1_ctx' has no member named 'count_low' ? high = (ctx->count_high << 9) | (ctx->count_low >> 23); ????????????????????????????????????? ^ sha-padlock.c:144:12: error: 'struct sha1_ctx' has no member named 'count_low' ? low = (ctx->count_low << 9) | (ctx->index << 3); ??????????? ^ sha-padlock.c: In function 'padlock_sha256_digest': sha-padlock.c:165:13: error: 'struct sha256_ctx' has no member named 'count_high' ? high = (ctx->count_high << 9) | (ctx->count_low >> 23); ???????????? ^ sha-padlock.c:165:38: error: 'struct sha256_ctx' has no member named 'count_low' ? high = (ctx->count_high << 9) | (ctx->count_low >> 23); ????????????????????????????????????? ^ sha-padlock.c:166:12: error: 'struct sha256_ctx' has no member named 'count_low' ? low = (ctx->count_low << 9) | (ctx->index << 3); when? I issue this command ?uname -a this is the output Linux amr-LIFEBOOK-AH531 3.8.0-42-generic #62~precise1-Ubuntu SMP Wed Jun 4 22:06:29 UTC 2014 i686 i686 i386 GNU/Linux can you please help me in building this successfully Thanks and Best Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From whitestone8214 at openmailbox.org Sat Jun 14 07:02:37 2014 From: whitestone8214 at openmailbox.org (whitestone8214 at openmailbox.org) Date: Sat, 14 Jun 2014 14:02:37 +0900 Subject: [gnutls-devel] Cannot build GnuTLS 3.3.4 on top of Nettle 3.0 Message-ID: <5fc21714d93e9f2488b4caf2ea7a9513@openmailbox.org> (...) sha-padlock.c: In function 'padlock_sha1_update': sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha256_update': sha-padlock.c:88:2: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:88:2: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c:88:2: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:88:2: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha1_digest': sha-padlock.c:143:13: error: 'struct sha1_ctx' has no member named 'count_high' sha-padlock.c:143:38: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c:144:12: error: 'struct sha1_ctx' has no member named 'count_low' sha-padlock.c: In function 'padlock_sha256_digest': sha-padlock.c:165:13: error: 'struct sha256_ctx' has no member named 'count_high' sha-padlock.c:165:38: error: 'struct sha256_ctx' has no member named 'count_low' sha-padlock.c:166:12: error: 'struct sha256_ctx' has no member named 'count_low' make[5]: *** [sha-padlock.lo] Error 1 (...) lib/accelerated/x86/sha-padlock.c uses 'count_high' and 'count_low' member in 'struct sha1_ctx' from Nettle. But in Nettle 3.0 'struct sha1_ctx' does not have 'count_high' and 'count_low'. What should I do to build GnuTLS 3.3.4? From ametzler at bebt.de Sat Jun 14 11:32:37 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 14 Jun 2014 11:32:37 +0200 Subject: [gnutls-devel] Cannot build GnuTLS 3.3.4 on top of Nettle 3.0 In-Reply-To: <5fc21714d93e9f2488b4caf2ea7a9513@openmailbox.org> References: <5fc21714d93e9f2488b4caf2ea7a9513@openmailbox.org> Message-ID: <20140614093237.GA11786@downhill.g.la> On 2014-06-14 whitestone8214 at openmailbox.org wrote: > (...) > sha-padlock.c: In function 'padlock_sha1_update': > sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named > 'count_high' > sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named 'count_low' > sha-padlock.c:81:2: error: 'struct sha1_ctx' has no member named (...) > lib/accelerated/x86/sha-padlock.c uses 'count_high' and 'count_low' member > in 'struct sha1_ctx' from Nettle. > But in Nettle 3.0 'struct sha1_ctx' does not have 'count_high' and > 'count_low'. > What should I do to build GnuTLS 3.3.4? GnuTLS cannot be built against Nettle 3.0. You'll need to use nettle 2.7. Rationale: There may be some problems in the new interfaces and new features which really need incompatible fixes. It is likely that there will be an update in the form of a 3.1 release in the not too distant future, with small but incompatible changes, and if that happens, bugfix-only releases 3.0.x are unlikely. Users and applications which desire better API and ABI stability are advised to stay with nettle-2.7.x (latest version is now 2.7.1) until the dust settles. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From attilamolnar at hush.com Sun Jun 15 17:51:35 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Sun, 15 Jun 2014 17:51:35 +0200 Subject: [gnutls-devel] doc: Corrections for gnutls_handshake_set_hook_function() Message-ID: <20140615155135.6F574601E5@smtp.hushmail.com> Hello everyone! A small patch follows, fixing minor errors in the documentation. Regards, Attila From attilamolnar at hush.com Sun Jun 15 17:52:46 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Sun, 15 Jun 2014 17:52:46 +0200 Subject: [gnutls-devel] [PATCH] doc: Corrections for gnutls_handshake_set_hook_function() Message-ID: <20140615155246.5AD57601E5@smtp.hushmail.com> >From fd9e734f2b65178a7fb9a042a79f23ea75c38d0f Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Sun, 15 Jun 2014 17:42:28 +0200 Subject: [PATCH] doc: Corrections for gnutls_handshake_set_hook_function() --- lib/gnutls_state.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/gnutls_state.c b/lib/gnutls_state.c index 1c2704e..e577425 100644 --- a/lib/gnutls_state.c +++ b/lib/gnutls_state.c @@ -1402,7 +1402,7 @@ gnutls_handshake_set_random(gnutls_session_t session, * handshake message has been received or generated. This is a * generalization of gnutls_handshake_set_post_client_hello_function(). * - * To call the hook function prior to the message being sent/generation use + * To call the hook function prior to the message being sent/generated use * %GNUTLS_HOOK_PRE as @post parameter, %GNUTLS_HOOK_POST to call * after, and %GNUTLS_HOOK_BOTH for both cases. * @@ -1415,8 +1415,6 @@ gnutls_handshake_set_random(gnutls_session_t session, * handshake based on client input unless you know what you are * doing. Before the handshake is finished there is no way to know if * there is a man-in-the-middle attack being performed. - * - * Returns: %GNUTLS_E_SUCCESS on success, or an error code. **/ void gnutls_handshake_set_hook_function(gnutls_session_t session, -- From nmav at gnutls.org Sun Jun 15 22:36:49 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Jun 2014 22:36:49 +0200 Subject: [gnutls-devel] doc: Corrections for gnutls_handshake_set_hook_function() In-Reply-To: <20140615155135.6F574601E5@smtp.hushmail.com> References: <20140615155135.6F574601E5@smtp.hushmail.com> Message-ID: <1402864609.4438.1.camel@nomad.lan> On Sun, 2014-06-15 at 17:51 +0200, Attila Molnar wrote: > Hello everyone! > > A small patch follows, fixing minor errors in the documentation. Thank you I've applied it. regards, Nikos From dkg at fifthhorseman.net Mon Jun 16 06:02:25 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 16 Jun 2014 00:02:25 -0400 Subject: [gnutls-devel] trying to compile gntls latest version In-Reply-To: <1402667602.94196.YahooMailNeo@web28906.mail.ir2.yahoo.com> References: <1402667602.94196.YahooMailNeo@web28906.mail.ir2.yahoo.com> Message-ID: <539E6C51.6020805@fifthhorseman.net> On 06/13/2014 09:53 AM, ???? ???? ????? ??? ????? wrote: > hi every one , > as I was trying to build the latest version of gnutls version 3 , > > I first made the this step > > 1- ./configure > 2- make > > I got the following error > > CC sha-padlock.lo > In file included from sha-padlock.c:29:0: > sha-padlock.c: In function 'padlock_sha1_update': > sha-padlock.c:81:46: error: 'struct sha1_ctx' has no member named 'count_high' > MD_UPDATE(ctx, length, data, SHA1_COMPRESS, MD_INCR(ctx)); It looks to me like you're trying to build against nettle 3.0. Please see the recent discussion about this on gnutls-devel: http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/7532/focus=7533 GnuTLS cannot be built against Nettle 3.0. You'll need to use nettle 2.7. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From attilamolnar at hush.com Mon Jun 16 20:55:06 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Mon, 16 Jun 2014 20:55:06 +0200 Subject: [gnutls-devel] Doc improvements Message-ID: <20140616185506.77E85601E5@smtp.hushmail.com> Hello everyone, Two doc patches follow; the first one is obvious. The second tries to clarify a grey area about the SRP server callback. Previously it was unclear what to do with the already allocated data that was put into the datum structures provided by gnutls if a failure happened in a later step (deallocate+clear it or leave it there?). Regards, Attila From attilamolnar at hush.com Mon Jun 16 20:56:03 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Mon, 16 Jun 2014 20:56:03 +0200 Subject: [gnutls-devel] [PATCH 1/2] doc: Correct comment about ignoring certs in the SRP server example Message-ID: <20140616185603.7C5EA601E5@smtp.hushmail.com> >From 79f2b158ce8c809c30772e2a58571717a9f6bfb4 Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Mon, 16 Jun 2014 18:04:10 +0200 Subject: [PATCH 1/2] doc: Correct comment about ignoring certs in the SRP server example Point readers to another example for a way to validate certificates in both the SRP and the X.509 server example Signed-off-by: Attila Molnar --- doc/examples/ex-serv-srp.c | 5 ++++- doc/examples/ex-serv-x509.c | 5 ++++- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/doc/examples/ex-serv-srp.c b/doc/examples/ex-serv-srp.c index e241765..9f1f58a 100644 --- a/doc/examples/ex-serv-srp.c +++ b/doc/examples/ex-serv-srp.c @@ -99,7 +99,10 @@ int main(void) gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cert_cred); - /* request client certificate if any. + /* We don't request any certificate from the client. + * If we did we would need to verify it. One way of + * doing that is shown in the "Verifying a certificate" + * example. */ gnutls_certificate_server_set_request(session, GNUTLS_CERT_IGNORE); diff --git a/doc/examples/ex-serv-x509.c b/doc/examples/ex-serv-x509.c index bc5b371..5380d60 100644 --- a/doc/examples/ex-serv-x509.c +++ b/doc/examples/ex-serv-x509.c @@ -125,8 +125,11 @@ int main(void) gnutls_priority_set(session, priority_cache); gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, x509_cred); + /* We don't request any certificate from the client. - * If we did we would need to verify it. + * If we did we would need to verify it. One way of + * doing that is shown in the "Verifying a certificate" + * example. */ gnutls_certificate_server_set_request(session, GNUTLS_CERT_IGNORE); -- From attilamolnar at hush.com Mon Jun 16 20:57:37 2014 From: attilamolnar at hush.com (Attila Molnar) Date: Mon, 16 Jun 2014 20:57:37 +0200 Subject: [gnutls-devel] [PATCH 2/2] doc: Explain post-callback deallocation behavior for the SRP server callback Message-ID: <20140616185737.C1AC2601E5@smtp.hushmail.com> >From fbdf93364366409239cf3c396db9b10aba17f944 Mon Sep 17 00:00:00 2001 From: Attila Molnar Date: Mon, 16 Jun 2014 18:10:09 +0200 Subject: [PATCH 2/2] doc: Explain post-callback deallocation behavior for the SRP server callback Signed-off-by: Attila Molnar --- lib/gnutls_srp.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/lib/gnutls_srp.c b/lib/gnutls_srp.c index 0423435..fb7c083 100644 --- a/lib/gnutls_srp.c +++ b/lib/gnutls_srp.c @@ -624,6 +624,11 @@ gnutls_srp_set_server_credentials_file(gnutls_srp_server_credentials_t res, * in using the gnutls_malloc(). For convenience @prime and @generator * may also be one of the static parameters defined in gnutls.h. * + * Initially, the data field is NULL in every #gnutls_datum_t + * structure that the callback has to fill in. When the + * callback is done GnuTLS deallocates all of those buffers + * which are non-NULL, regardless of the return value. + * * In order to prevent attackers from guessing valid usernames, * if a user does not exist, g and n values should be filled in * using a random user's parameters. In that case the callback must -- From nmav at gnutls.org Tue Jun 17 10:29:40 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Jun 2014 10:29:40 +0200 Subject: [gnutls-devel] Doc improvements In-Reply-To: <20140616185506.77E85601E5@smtp.hushmail.com> References: <20140616185506.77E85601E5@smtp.hushmail.com> Message-ID: On Mon, Jun 16, 2014 at 8:55 PM, Attila Molnar wrote: > Hello everyone, > Two doc patches follow; the first one is obvious. > The second tries to clarify a grey area about the SRP server callback. > Previously it was unclear what to do with the already allocated data > that was put into the datum structures provided by gnutls if a failure > happened in a later step (deallocate+clear it or leave it there?). Applied, thank you. From nmav at gnutls.org Thu Jun 26 20:36:42 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 26 Jun 2014 20:36:42 +0200 Subject: [gnutls-devel] gnutls 3.3.5 Message-ID: <1403807802.27453.4.camel@nomad.lan> Hello, I've just released gnutls 3.3.5. This release adds new features, and fixes bugs on the next-stable branch. * Version 3.3.5 (released 2014-06-26) ** libgnutls: Added gnutls_record_recv_packet() and gnutls_packet_deinit(). These functions provide a variant of gnutls_record_recv() that avoids the final memcpy of data. ** libgnutls: gnutls_x509_crl_iter_crt_serial() was added as a faster variant of gnutls_x509_crl_get_crt_serial() when coping with very large structures. ** libgnutls: When the decoding of a printable DN element fails, then treat it as unknown and print its hex value rather than failing. That works around an issue in a TURKTRST root certificate which improperly encodes the X520countryName element. ** libgnutls: gnutls_x509_trust_list_add_trust_file() will return the number of certificates present in a PKCS #11 token when loading it. ** libgnutls: Allow the post client hello callback to put the handshake on hold, by returning GNUTLS_E_AGAIN or GNUTLS_E_INTERRUPTED. ** certtool: option --to-p12 will now consider --load-ca-certificate ** certtol: Added option to specify the PKCS #12 friendly name on command line. ** p11tool: Allow marking a certificate copied to a token as a CA. ** API and ABI modifications: GNUTLS_PKCS11_OBJ_FLAG_MARK_CA: Added gnutls_x509_crl_iter_deinit: Added gnutls_x509_crl_iter_crt_serial: Added gnutls_record_recv_packet: Added gnutls_packet_deinit: Added gnutls_packet_get: 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.5.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.5.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.5.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.5.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 ametzler at bebt.de Sun Jun 29 07:45:18 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 29 Jun 2014 07:45:18 +0200 Subject: [gnutls-devel] 3.3.5 testsuite error on kfreebsd-amd64 Message-ID: <20140629054518.GA1480@downhill.g.la> Hello, ./tests/long-session-id occassionally fails on kfreebsd-amd64 with exitcode 141, sadly --verbose looks exactly the same as a succeeding test. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: long-session-id.log.fail.gz Type: application/gzip Size: 1148 bytes Desc: not available URL: From nmav at gnutls.org Sun Jun 29 13:19:57 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 29 Jun 2014 13:19:57 +0200 Subject: [gnutls-devel] 3.3.5 testsuite error on kfreebsd-amd64 In-Reply-To: <20140629054518.GA1480@downhill.g.la> References: <20140629054518.GA1480@downhill.g.la> Message-ID: <1404040797.7388.1.camel@nomad.lan> On Sun, 2014-06-29 at 07:45 +0200, Andreas Metzler wrote: > Hello, > > ./tests/long-session-id occassionally fails on kfreebsd-amd64 with > exitcode 141, sadly --verbose looks exactly the same as a succeeding > test. Hello, Does long-session-id.log contain anything useful? Could it be a SIGPIPE issue? In that case would: https://gitorious.org/gnutls/gnutls/commit/db5ea8edd614edb56ebd8052caf6049ea219ff4b help? From ametzler at bebt.de Sun Jun 29 14:51:34 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 29 Jun 2014 14:51:34 +0200 Subject: [gnutls-devel] 3.3.5 testsuite error on kfreebsd-amd64 In-Reply-To: <1404040797.7388.1.camel@nomad.lan> References: <20140629054518.GA1480@downhill.g.la> <1404040797.7388.1.camel@nomad.lan> Message-ID: <20140629125134.GO1498@downhill.g.la> On 2014-06-29 Nikos Mavrogiannopoulos wrote: > On Sun, 2014-06-29 at 07:45 +0200, Andreas Metzler wrote: >> ./tests/long-session-id occassionally fails on kfreebsd-amd64 with >> exitcode 141, sadly --verbose looks exactly the same as a succeeding >> test. > Hello, > Does long-session-id.log contain anything useful? Helo, no, just the normal output --------------- (sid_kfreebsd-amd64-dchroot)ametzler at falla:~/GNUTLS/gnutls28-3.3.5$ cat ./tests/long-session-id.log client: Handshake failed (expected) GnuTLS error: A record packet with illegal version was received. --------------- > Could it be a SIGPIPE issue? In that case would: > https://gitorious.org/gnutls/gnutls/commit/db5ea8edd614edb56ebd8052caf6049ea219ff4b > help? With this patch I am unable to reproduce the issue. :-) thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'