From mk at cognitivedissonance.ca Sat Dec 6 19:16:22 2014 From: mk at cognitivedissonance.ca (MK) Date: Sat, 6 Dec 2014 13:16:22 -0500 Subject: [gnutls-help] Certtool: Generate private key with password Message-ID: <20141206131622.ed704ccc80f7fa9d106c05e4@cognitivedissonance.ca> In the certtool man page, there is the option to specify a password on the command line w/ `--password`. In the online manual: http://www.gnutls.org/manual/html_node/certtool-Invocation.html This option is described as useful "to specify the password in the command line instead of reading it from the tty". This implies that without this option, a password can be read from stdin. However, there doesn't seem to be any way to invoke such behavior. The example in the man page of how to generate a private key is: certtool --generate-privkey --outfile key.pem --rsa But this never asks for a password. How can I generate a password protected private key without specifying the password on the command line? The only option I can find to specify an encryption algorithm is `--pkcs-cipher`, but that seems inappropriate and doesn't do anything in this case. The certtool version is 3.2.11 compiled for Fedora 20. Thanks -- MK -- "Philosophy, love of wisdom, asserts a distance between love and wisdom, and in this gap that tenuously joins what it separates, we shall attempt to set up our cables." -> Avital Ronell From aniruddha.dandekar at hp.com Mon Dec 8 06:31:29 2014 From: aniruddha.dandekar at hp.com (Dandekar, Aniruddha (TCS)) Date: Mon, 8 Dec 2014 05:31:29 +0000 Subject: [gnutls-help] GnuTLS: Help needed to understand the versioning scheme Message-ID: Hello, Try to access GnuTLS for a porting requirement. But I am not able to understand the difference between 3 version streams - 3.1.x, 3.2.x and 3.3.x. Can anybody help me understand this. I see versions being released on all 3 streams. Thanks and regards, Aniruddha -------------- next part -------------- An HTML attachment was scrubbed... URL: From tzz at lifelogs.com Mon Dec 8 19:49:42 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Mon, 08 Dec 2014 13:49:42 -0500 Subject: [gnutls-help] User-level visibility of GnuTLS security and tuning Message-ID: I am posting this question, originally from Lars Magne Ingebrigtsen, about how much control Emacs should give its users. RMS suggested we ask experts like Simon Josefsson but I think it's even better to ask here on the GnuTLS users mailing list. FWIW my suggestion was to augment the GnuTLS priority strings. So the user would say "NORMAL:NSM(medium,warn-rc4)" or something like that, but we'd strip off the Emacs-specific things out before passing it to GnuTLS. But we're definitely open to suggestions. Thanks! Ted ---- Some other browsers are discussing switching off "weak" encryption in one form or another. I don't think that's a good idea, because sometimes you want to visit web sites and don't care whether they use "good" encryption or not. But it might make sense to warn users that this is happening. Perhaps by default, perhaps only if they have switched to `high' security. Candidates for these warnings would be * low prime-bits used in the Diffie-Hellman handshake * SSL1, SSL2 and SSL3 * usage of RC4 anywhere Can anybody think of anything else that's considered "weak" these days? Perhaps it might make sense to allow users to specify high-grained security policies? That is (setq network-security-level '(starttls-downgrade ssl3 rc4)) or something? Where `medium' would just be an alias for the default things we check for... On the other hand, perhaps not. There's a temptation in Emacs to make everything configurable, and I think that's a mistake. Instead of implementing a feature, we end up implementing a framework for creating the feature, so the user ends up having to do all the work to get things into a reasonable state. And allowing users to configure stuff means that we don't have to be as thorough in getting things just right, because "they can always switch it off" or something, which is a cop-out. And making stuff configurable inevitably means that it's more prone to bugs, because there are code paths almost never taken. From nmav at gnutls.org Tue Dec 9 17:25:28 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 9 Dec 2014 17:25:28 +0100 Subject: [gnutls-help] User-level visibility of GnuTLS security and tuning In-Reply-To: References: Message-ID: On Mon, Dec 8, 2014 at 7:49 PM, Ted Zlatanov wrote: > Some other browsers are discussing switching off "weak" encryption in > one form or another. I don't think that's a good idea, because > sometimes you want to visit web sites and don't care whether they use > "good" encryption or not. > But it might make sense to warn users that this is happening. Perhaps > by default, perhaps only if they have switched to `high' security. > > Candidates for these warnings would be > > * low prime-bits used in the Diffie-Hellman handshake > * SSL1, SSL2 and SSL3 If the code is gnutls, it only supports SSL 3.0 or later (btw. there is no SSL 1.0). I'd warn on TLS 1.0 (inclusive due to BEAST attack) and earlier. > Can anybody think of anything else that's considered "weak" these days? > Perhaps it might make sense to allow users to specify high-grained > security policies? I think a good approach is to define few understandable policies. Fedora for example provides LEGACY, DEFAULT and FUTURE. The idea is that legacy would work with any server providing something better than plaintext, default a reasonable security level for today's metrics, and future is a security level with the state of the art encryption requirements of today. You may get inspired by the gnutls settings for them: https://github.com/nmav/fedora-crypto-policies/tree/master/profiles regards, Nikos From nmav at gnutls.org Thu Dec 11 09:10:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 09:10:23 +0100 Subject: [gnutls-help] gnutls 3.2.21 Message-ID: <1418285423.2059.1.camel@gnutls.org> Hello, I've just released gnutls 3.2.21. This is a bugfix release on the previous stable branch. * Version 3.2.21 (released 2014-12-11) ** libgnutls: Corrected regression introduced in 3.2.19 related to session renegotiation. Reported by Dan Winship. ** libgnutls: Corrected parsing issue with OCSP responses. ** 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.2/gnutls-3.2.21.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.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 Thu Dec 11 09:11:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 09:11:18 +0100 Subject: [gnutls-help] gnutls 3.3.11 Message-ID: <1418285478.2059.2.camel@gnutls.org> Hello, I've just released gnutls 3.3.11. This is a bug-fix release on the current stable branch. * Version 3.3.11 (released 2014-12-11) ** libgnutls: Corrected regression introduced in 3.3.9 related to session renegotiation. Reported by Dan Winship. ** libgnutls: Corrected parsing issue with OCSP responses. ** 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.11.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.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 tzz at lifelogs.com Thu Dec 11 16:31:44 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Thu, 11 Dec 2014 10:31:44 -0500 Subject: [gnutls-help] User-level visibility of GnuTLS security and tuning References: Message-ID: On Tue, 9 Dec 2014 17:25:28 +0100 Nikos Mavrogiannopoulos wrote: NM> (btw. there is no SSL 1.0) Yup, sorry. So we should definitely not allow it ;) NM> I think a good approach is to define few understandable policies. NM> Fedora for example provides LEGACY, DEFAULT and FUTURE. The idea is NM> that legacy would work with any server providing something better than NM> plaintext, default a reasonable security level for today's metrics, NM> and future is a security level with the state of the art encryption NM> requirements of today. NM> You may get inspired by the gnutls settings for them: NM> https://github.com/nmav/fedora-crypto-policies/tree/master/profiles OK, that's very helpful. So that's an application-level setting that manages the GnuTLS settings and messaging. That's what Lars has done with the Emacs `network-security-level' variable, so users just have to set one thing. We'll stick with that. Thanks Ted From yanfiz at gmail.com Mon Dec 15 04:57:30 2014 From: yanfiz at gmail.com (Yan Fiz) Date: Mon, 15 Dec 2014 05:57:30 +0200 Subject: [gnutls-help] Generating DH Parameters larger than 3072 bits Message-ID: $ certtool --generate-dh-params --bits 4096 --outfile server.p3 --debug 9999 Setting log level to 9999 ** Note: Please use the --sec-param instead of --bits Generating DH parameters (4096 bits)... (might take long time) |<3>| ASSERT: pk.c:843 |<3>| ASSERT: gnutls_dh.c:223 Error generating parameters: Error in public key generation. $ certtool --generate-dh-params --sec-param ultra --outfile server.p3 --debug 9999 Setting log level to 9999 Generating DH parameters (15424 bits)... (might take long time) |<3>| ASSERT: pk.c:843 |<3>| ASSERT: gnutls_dh.c:223 Error generating parameters: Error in public key generation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Tue Dec 16 13:00:14 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Dec 2014 13:00:14 +0100 Subject: [gnutls-help] Generating DH Parameters larger than 3072 bits In-Reply-To: References: Message-ID: <1418731214.6441.1.camel@gnutls.org> On Mon, 2014-12-15 at 05:57 +0200, Yan Fiz wrote: > $ certtool --generate-dh-params --bits 4096 --outfile server.p3 > --debug 9999 > Setting log level to 9999 > ** Note: Please use the --sec-param instead of --bits > Generating DH parameters (4096 bits)... > (might take long time) Unfortunately that is a known issue in the 3.3.x release. You will need need nettle-2.7.1 with the attached patch in order to generate parameters larger than 3072 bits. I'll send that patch to the nettle maintainer, but I find it unlikely to have a new 2.7.x release. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-allow-the-usage-of-arbitrary-q_bits-sizes-in-DSA-key.patch Type: text/x-patch Size: 630 bytes Desc: not available URL: From deng at randomsample.de Fri Dec 19 18:10:17 2014 From: deng at randomsample.de (David Engster) Date: Fri, 19 Dec 2014 18:10:17 +0100 Subject: [gnutls-help] Detect whether certificate is self-signed Message-ID: <87r3vvlg5i.fsf@arcor.de> What is the best way with libgnutls do see whether a certificate is self-signed? I'm guessing you have to compare issuer with subject, but is there a preferred way to do that? From RFC5280 it seems to me that this comparison is not trivial to do, but maybe for self-signed they really always match byte for byte? -David From nmav at gnutls.org Sun Dec 21 07:44:38 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Dec 2014 08:44:38 +0200 Subject: [gnutls-help] Detect whether certificate is self-signed In-Reply-To: <87r3vvlg5i.fsf@arcor.de> References: <87r3vvlg5i.fsf@arcor.de> Message-ID: <1419144278.6044.5.camel@gnutls.org> On Fri, 2014-12-19 at 18:10 +0100, David Engster wrote: > What is the best way with libgnutls do see whether a certificate is > self-signed? I'm guessing you have to compare issuer with subject, but > is there a preferred way to do that? From RFC5280 it seems to me that > this comparison is not trivial to do, but maybe for self-signed they > really always match byte for byte? gnutls doesn't follow the rfc5280 comparison for DNs. It does a memcmp() to check if they are identical, and you are safe if you do that too. For two reasons, (1) adding an elaborate parsing layer to ensure identify may introduce bugs which allow false positives in the comparison, (2) it is unnecessary; there is no software that generates certificates with spacing differences or case-differences on the DN, that is the relic from the time where DNs were copied by a human using a keyboard and not by memcpy(). Said that, the easiest way to check for a self-signed certificate is using gnutls_x509_crt_check_issuer() against itself. regards, Nikos From deng at randomsample.de Sun Dec 21 18:19:38 2014 From: deng at randomsample.de (David Engster) Date: Sun, 21 Dec 2014 18:19:38 +0100 Subject: [gnutls-help] Detect whether certificate is self-signed In-Reply-To: <1419144278.6044.5.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 21 Dec 2014 08:44:38 +0200") References: <87r3vvlg5i.fsf@arcor.de> <1419144278.6044.5.camel@gnutls.org> Message-ID: <87d27cyl79.fsf@engster.org> Nikos Mavrogiannopoulos writes: > On Fri, 2014-12-19 at 18:10 +0100, David Engster wrote: >> What is the best way with libgnutls do see whether a certificate is >> self-signed? I'm guessing you have to compare issuer with subject, but >> is there a preferred way to do that? From RFC5280 it seems to me that >> this comparison is not trivial to do, but maybe for self-signed they >> really always match byte for byte? > > gnutls doesn't follow the rfc5280 comparison for DNs. It does a memcmp() > to check if they are identical, and you are safe if you do that too. For > two reasons, (1) adding an elaborate parsing layer to ensure identify > may introduce bugs which allow false positives in the comparison, (2) it > is unnecessary; there is no software that generates certificates with > spacing differences or case-differences on the DN, that is the relic > from the time where DNs were copied by a human using a keyboard and not > by memcpy(). Yes, I already wondered how that could happen in the first place. But... > Said that, the easiest way to check for a self-signed certificate is > using gnutls_x509_crt_check_issuer() against itself. ...that's way simpler. :-) Thanks! -David From tzz at lifelogs.com Wed Dec 24 13:28:22 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Wed, 24 Dec 2014 07:28:22 -0500 Subject: [gnutls-help] Detect whether certificate is self-signed References: <87r3vvlg5i.fsf@arcor.de> <1419144278.6044.5.camel@gnutls.org> <87d27cyl79.fsf@engster.org> Message-ID: On Sun, 21 Dec 2014 18:19:38 +0100 David Engster wrote: DE> Nikos Mavrogiannopoulos writes: >> Said that, the easiest way to check for a self-signed certificate is >> using gnutls_x509_crt_check_issuer() against itself. DE> ...that's way simpler. :-) Could this be abstracted into a function so, if GnuTLS implements it differently in the future (following the RFC or something else), clients don't have to be changed? It seems to be fairly useful. Thanks Ted From nmav at gnutls.org Fri Dec 26 18:50:09 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 26 Dec 2014 19:50:09 +0200 Subject: [gnutls-help] Detect whether certificate is self-signed In-Reply-To: References: <87r3vvlg5i.fsf@arcor.de> <1419144278.6044.5.camel@gnutls.org> <87d27cyl79.fsf@engster.org> Message-ID: <1419616209.15986.3.camel@gnutls.org> On Wed, 2014-12-24 at 07:28 -0500, Ted Zlatanov wrote: >DE> Nikos Mavrogiannopoulos writes: > >> Said that, the easiest way to check for a self-signed certificate is > >> using gnutls_x509_crt_check_issuer() against itself. > DE> ...that's way simpler. :-) > Could this be abstracted into a function so, if GnuTLS implements it > differently in the future (following the RFC or something else), clients > don't have to be changed? It seems to be fairly useful. Hi, Not sure if I follow. gnutls_x509_crt_check_issuer() is already a function, what do you think should be abstracted into a function? regards, Nikos