From nicolas at babelouest.org Thu Jan 2 02:08:51 2020 From: nicolas at babelouest.org (Nicolas Mora) Date: Wed, 1 Jan 2020 20:08:51 -0500 Subject: [gnutls-help] How to check if a gnutls_x509_crt_t contains a private key Message-ID: <09ae2cd3-a2fb-bb6c-2b58-5c102e7465f2@babelouest.org> Hello, I'd like to check if a gnutls_x509_crt_t created via gnutls_x509_crt_import contains a private key. I can't find in the documentation a function that would give me a straight answer. Is there a way to make that check? /Nicolas From nicolas at babelouest.org Thu Jan 2 05:02:53 2020 From: nicolas at babelouest.org (Nicolas Mora) Date: Wed, 1 Jan 2020 23:02:53 -0500 Subject: [gnutls-help] How to check if a gnutls_x509_crt_t contains a private key In-Reply-To: <09ae2cd3-a2fb-bb6c-2b58-5c102e7465f2@babelouest.org> References: <09ae2cd3-a2fb-bb6c-2b58-5c102e7465f2@babelouest.org> Message-ID: <471d8533-a8b8-c6e6-1c4b-01244fccdb94@babelouest.org> > > I'd like to check if a gnutls_x509_crt_t created via > gnutls_x509_crt_import contains a private key. > I think I found the answer, the gnutls_x509_crt_t contains only a public key. If I want to import an unknown DER certificate, I need to try it first in gnutls_x509_privkey_t format with gnutls_x509_privkey_import. If the import fails, then try with gnutls_x509_crt_import. Sorry for the noise From nmav at gnutls.org Fri Jan 3 10:20:28 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 3 Jan 2020 10:20:28 +0100 Subject: [gnutls-help] "built-in" gnutls config, with optional-only config file on disk In-Reply-To: References: Message-ID: On Tue, Dec 31, 2019 at 4:48 PM Dimitri John Ledkov wrote: > > > What about for the other overrides? I.e. can one somehow compile-in > > > default [overrides] that is used, unless system config specifies one? > > > I.e. built-in config specifying [overrides] disabled-versions=tls1.0, > > > with users able to turn it back on by creating the config and > > > specifying like empty [overrides] paragraph, or like using > > > reenable-versions=tls1.0. > > > > > > Maybe I am overthinking all of this, and what I really want is simply > > > support for > > > [overrides] > > > default-priority-string = NORMAL > > > Whilst the library itself is compiled with something stronger, i.e. > > > --with-default-priority-string='NORMAL:-VERS-TLS1.0'. > > > > That sounds like something reasonable. There is an ongoing coversation > > on how to handle national standards like GOST with a similar mechanism > > at: > > https://gitlab.com/gnutls/gnutls/merge_requests/1119 > > Would you like to move that discussion there so that we combine the > > requirements? > > Possibly. At the moment I do not see any better way than to introduce > [overrides]default-priority-string in the config file. As I want > NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in > default but a way for users to override this behaviour in a config > file, which I don't see a way to do at the moment. Please open an issue at our tracker to continue this discussion there. > Also there isn't a compiled-in default for the [overrides] > verify-profile key, nor for the compiled-in [overrides] > disabled-version key, nor a way to reenable compiled-in > disabled-versions. The configuration as it is now it sets the minimum bar that cannot be changed by applications. That's to provide assurance that no application opts out from that minimum bar. The goal is to use that bar to configure for inflexible requirements (e.g., compliance, or other legal ones). Nevertheless, the fact that we do not set a verification profile outside TLS is something that I missed as well. I've opened this to track for the next major update: https://gitlab.com/gnutls/gnutls/issues/895 > Imho, any library should have sensible compiled-in defaults, which can > be overridden with config files, such that one can have "available, > but disabled by default" algos / protocol version / profile levels / > etc, which users can opt-into anyway. This is separete to choosing to > not even compile unwanted protocol versions (i.e. just disable tls1.3 > at build time, and not include that functionality in the library at > all). I believe the defaults provided by gnutls are sensible and quite conservative, even though TLS-focused. Of course a distribution can go better using the configuration file (see fedora crypto policies). If you refer to the certificate verification outside TLS defaults, indeed as I said that's something missing but it looks like me like an ABI break and I do not think we should not break ABI considerably outside a major update. Otherwise test suites and applications that worked before may break unexpectedly. regards, Nikos From xnox at ubuntu.com Sat Jan 4 21:26:22 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Sat, 4 Jan 2020 20:26:22 +0000 Subject: [gnutls-help] "built-in" gnutls config, with optional-only config file on disk In-Reply-To: References: Message-ID: On Fri, 3 Jan 2020 at 09:21, Nikos Mavrogiannopoulos wrote: > > On Tue, Dec 31, 2019 at 4:48 PM Dimitri John Ledkov wrote: > > > > What about for the other overrides? I.e. can one somehow compile-in > > > > default [overrides] that is used, unless system config specifies one? > > > > I.e. built-in config specifying [overrides] disabled-versions=tls1.0, > > > > with users able to turn it back on by creating the config and > > > > specifying like empty [overrides] paragraph, or like using > > > > reenable-versions=tls1.0. > > > > > > > > Maybe I am overthinking all of this, and what I really want is simply > > > > support for > > > > [overrides] > > > > default-priority-string = NORMAL > > > > Whilst the library itself is compiled with something stronger, i.e. > > > > --with-default-priority-string='NORMAL:-VERS-TLS1.0'. > > > > > > That sounds like something reasonable. There is an ongoing coversation > > > on how to handle national standards like GOST with a similar mechanism > > > at: > > > https://gitlab.com/gnutls/gnutls/merge_requests/1119 > > > Would you like to move that discussion there so that we combine the > > > requirements? > > > > Possibly. At the moment I do not see any better way than to introduce > > [overrides]default-priority-string in the config file. As I want > > NORMAL:-VERS-TLS1.0:-VERS-TLS1.1:%PROFILE_MEDIUM as the compiled-in > > default but a way for users to override this behaviour in a config > > file, which I don't see a way to do at the moment. > > Please open an issue at our tracker to continue this discussion there. > ok. > > Also there isn't a compiled-in default for the [overrides] > > verify-profile key, nor for the compiled-in [overrides] > > disabled-version key, nor a way to reenable compiled-in > > disabled-versions. > > The configuration as it is now it sets the minimum bar that cannot be > changed by applications. That's to provide assurance that no > application opts out from that minimum bar. The goal is to use that > bar to configure for inflexible requirements (e.g., compliance, or > other legal ones). > > Nevertheless, the fact that we do not set a verification profile > outside TLS is something that I missed as well. I've opened this to > track for the next major update: > https://gitlab.com/gnutls/gnutls/issues/895 > Nice. > > Imho, any library should have sensible compiled-in defaults, which can > > be overridden with config files, such that one can have "available, > > but disabled by default" algos / protocol version / profile levels / > > etc, which users can opt-into anyway. This is separete to choosing to > > not even compile unwanted protocol versions (i.e. just disable tls1.3 > > at build time, and not include that functionality in the library at > > all). > > I believe the defaults provided by gnutls are sensible and quite > conservative, even though TLS-focused. Of course a distribution can go > better using the configuration file (see fedora crypto policies). If > you refer to the certificate verification outside TLS defaults, indeed > as I said that's something missing but it looks like me like an ABI > break and I do not think we should not break ABI considerably outside > a major update. Otherwise test suites and applications that worked > before may break unexpectedly. It's not an api/abi break in a classic sense, but a runtime break. Debian has already did so with OpenSSL forcing all the reverse dependencies to upgrade the certificates to stronger ones (key sizes / signature hashes). All major web browser are turning off TLS less than 1.2 by default this year, yet still compiling it in and allowing users to enable it back on. I will be doing similar in Ubuntu too for all the major crypto libraries. I am working on a patch that allows at configure time mark TLS 1.0/1.1, DTLS 0.9 / 1.1 versions struct supported = 0, and allow to use overrides to force mark those back up as supported. It still follows the minimum bar principle, i.e. if at configure time older tls versions are marked as unsupported a system-wide config & app need to both enable tls1.0 usage for it to succeed. I will post this as soon as all the tests pass in all the configuration options. -- Regards, Dimitri. From john.sha.jiang at gmail.com Wed Jan 8 05:40:48 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 8 Jan 2020 12:40:48 +0800 Subject: [gnutls-help] How to enable AES-256-CBC? Message-ID: Hi, I'm using GnuTLS 3.6.10. It looks this version disables AES-256-CBC. With my testing on gnutls-serv, if a client supports cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 only, the connecting just fails. But if the client uses TLS_RSA_WITH_AES_128_GCM_SHA256, the connection can be established. Could this cipher suite be enabled by priority string? I have tried "NORMAL:+RSA:+AES-256-CBC", but it didn't work. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Jan 9 15:52:09 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 9 Jan 2020 15:52:09 +0100 Subject: [gnutls-help] How to enable AES-256-CBC? In-Reply-To: References: Message-ID: On Wed, Jan 8, 2020 at 6:01 AM John Jiang wrote: > > Hi, > I'm using GnuTLS 3.6.10. > It looks this version disables AES-256-CBC. > With my testing on gnutls-serv, if a client supports cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 only, the connecting just fails. > But if the client uses TLS_RSA_WITH_AES_128_GCM_SHA256, the connection can be established. > Could this cipher suite be enabled by priority string? > I have tried "NORMAL:+RSA:+AES-256-CBC", but it didn't work. Hi, AES-256-CBC is not disabled. SHA256 as HMAC is. You need to add +SHA256 in a priority string. For context see: https://gitlab.com/gnutls/gnutls/issues/831 regards, Nikos From john.sha.jiang at gmail.com Fri Jan 10 02:21:48 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Fri, 10 Jan 2020 09:21:48 +0800 Subject: [gnutls-help] How to enable AES-256-CBC? In-Reply-To: References: Message-ID: On Thu, Jan 9, 2020 at 10:52 PM Nikos Mavrogiannopoulos wrote: > On Wed, Jan 8, 2020 at 6:01 AM John Jiang > wrote: > > > > Hi, > > I'm using GnuTLS 3.6.10. > > It looks this version disables AES-256-CBC. > > With my testing on gnutls-serv, if a client supports cipher suite > TLS_RSA_WITH_AES_256_CBC_SHA256 only, the connecting just fails. > > But if the client uses TLS_RSA_WITH_AES_128_GCM_SHA256, the connection > can be established. > > Could this cipher suite be enabled by priority string? > > I have tried "NORMAL:+RSA:+AES-256-CBC", but it didn't work. > > Hi, > AES-256-CBC is not disabled. SHA256 as HMAC is. You need to add > +SHA256 in a priority string. > It works, thanks! BTW, could I get SSLv3.0 back? I tried "NORMAL:+VERS-SSL3.0:+RSA:+SHA256", but got protocol_version alert with TLS_RSA_WITH_AES_128_CBC_SHA and SSLv3. If used TLSv1.0 and the same cipher suite, my test passed. > For context see: https://gitlab.com/gnutls/gnutls/issues/831 > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Jan 10 09:42:51 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Jan 2020 09:42:51 +0100 Subject: [gnutls-help] How to enable AES-256-CBC? In-Reply-To: References: Message-ID: On Fri, Jan 10, 2020 at 2:22 AM John Jiang wrote: > > On Thu, Jan 9, 2020 at 10:52 PM Nikos Mavrogiannopoulos wrote: >> >> On Wed, Jan 8, 2020 at 6:01 AM John Jiang wrote: >> > >> > Hi, >> > I'm using GnuTLS 3.6.10. >> > It looks this version disables AES-256-CBC. >> > With my testing on gnutls-serv, if a client supports cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256 only, the connecting just fails. >> > But if the client uses TLS_RSA_WITH_AES_128_GCM_SHA256, the connection can be established. >> > Could this cipher suite be enabled by priority string? >> > I have tried "NORMAL:+RSA:+AES-256-CBC", but it didn't work. >> >> Hi, >> AES-256-CBC is not disabled. SHA256 as HMAC is. You need to add >> +SHA256 in a priority string. > > It works, thanks! > > BTW, could I get SSLv3.0 back? > I tried "NORMAL:+VERS-SSL3.0:+RSA:+SHA256", but got protocol_version alert with TLS_RSA_WITH_AES_128_CBC_SHA and SSLv3. > If used TLSv1.0 and the same cipher suite, my test passed. It is disabled by default without any option to enable. You'll need to recompile the library and enable ssl3 in the configure step. regards, Nikos From john.sha.jiang at gmail.com Mon Jan 13 00:41:22 2020 From: john.sha.jiang at gmail.com (John Jiang) Date: Mon, 13 Jan 2020 07:41:22 +0800 Subject: [gnutls-help] How to enable AES-256-CBC? In-Reply-To: References: Message-ID: Hi, On Fri, Jan 10, 2020 at 4:43 PM Nikos Mavrogiannopoulos wrote: > On Fri, Jan 10, 2020 at 2:22 AM John Jiang > wrote: > > > > On Thu, Jan 9, 2020 at 10:52 PM Nikos Mavrogiannopoulos > wrote: > >> > >> On Wed, Jan 8, 2020 at 6:01 AM John Jiang > wrote: > >> > > >> > Hi, > >> > I'm using GnuTLS 3.6.10. > >> > It looks this version disables AES-256-CBC. > >> > With my testing on gnutls-serv, if a client supports cipher suite > TLS_RSA_WITH_AES_256_CBC_SHA256 only, the connecting just fails. > >> > But if the client uses TLS_RSA_WITH_AES_128_GCM_SHA256, the > connection can be established. > >> > Could this cipher suite be enabled by priority string? > >> > I have tried "NORMAL:+RSA:+AES-256-CBC", but it didn't work. > >> > >> Hi, > >> AES-256-CBC is not disabled. SHA256 as HMAC is. You need to add > >> +SHA256 in a priority string. > > > > It works, thanks! > > > > BTW, could I get SSLv3.0 back? > > I tried "NORMAL:+VERS-SSL3.0:+RSA:+SHA256", but got protocol_version > alert with TLS_RSA_WITH_AES_128_CBC_SHA and SSLv3. > > If used TLSv1.0 and the same cipher suite, my test passed. > > It is disabled by default without any option to enable. You'll need to > recompile the library and enable ssl3 in the configure step. > I tried configure option "--enable-ssl3-support", and it worked. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From islam.turkozz at gmail.com Tue Jan 14 14:31:54 2020 From: islam.turkozz at gmail.com (=?UTF-8?B?SXNsYW0gdMO8cmvDtno=?=) Date: Tue, 14 Jan 2020 16:31:54 +0300 Subject: [gnutls-help] GnuTLS for Windows Message-ID: Hi, I want to develop a project about mutual authentication with smart card for client side. I donwloaded your files under ?GnuTLS for Windows? but i cannot use it on my project. What should i do to apply these on my project. Do you have any docs ? *Thanks & Regards* -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandor5 at gmail.com Wed Jan 22 15:24:56 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Wed, 22 Jan 2020 09:24:56 -0500 Subject: [gnutls-help] Help allowing SHA1 Message-ID: Hello everyone: A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. >From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` What am I doing wrong? Any help would be much appreciated. Thanks, Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnox at ubuntu.com Thu Jan 23 08:28:34 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Thu, 23 Jan 2020 09:28:34 +0200 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: Hi, On Wed, 22 Jan 2020 at 16:42, Brandon Sawyers wrote: > > Hello everyone: > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. > > From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. > > I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > What am I doing wrong? > This seems ok. Looking at gnutls master, a few things jump out. GNUTLS_VERIFY_ALLOW_BROKEN doesn't include the GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1 flag. Thus if gnutls-cli does specify --verify-allow-broken that doesn't add SHA1. I guess --insecure will do perform the connection. However, the best you can do is to upgrade your certs. Even if it is internal.directory.org you should be able to get letsencrypt cert, and if needed instrument a reverse proxy webserver in front of internal.directory.org if for some reason it can't do TLSv1.2 / bigger certs / legacy clients / etc. Similarly one can do similarish things on client, i.e. download the older gnutls28 from the archive/launchpad and LD_PRELOAD the old libgnutls30 - the api/abi should have stayed stable to do that. -- Regards, Dimitri. From brandor5 at gmail.com Thu Jan 23 12:35:31 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Thu, 23 Jan 2020 06:35:31 -0500 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: The problem is that we're not on master. Ubuntu 1604 is shipping 3.4.10 and 1804 has 3.5.18. There options you mentioned are not available in those versions. We are will aware of what there correct answer is, however moving a large organization at once isn't a valid option for us. Thanks, Brandon On Thu, Jan 23, 2020, 02:28 Dimitri John Ledkov wrote: > Hi, > > On Wed, 22 Jan 2020 at 16:42, Brandon Sawyers wrote: > > > > Hello everyone: > > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 > (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still > in the process of migrating our last services off of SHA1 with a target > date of April this has put us in a pickle. > > > > From reading the docs I expect I should be able to use priority and > allow SHA1 to function, however making this work has been rather > frustrating. > > > > I've tried several different versions of the following command but I > would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should > work. > > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem > --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > > > What am I doing wrong? > > > > This seems ok. > > Looking at gnutls master, a few things jump out. > GNUTLS_VERIFY_ALLOW_BROKEN doesn't include the > GNUTLS_VERIFY_ALLOW_SIGN_WITH_SHA1 flag. Thus if gnutls-cli does > specify --verify-allow-broken that doesn't add SHA1. > > I guess --insecure will do perform the connection. > > However, the best you can do is to upgrade your certs. Even if it is > internal.directory.org you should be able to get letsencrypt cert, and > if needed instrument a reverse proxy webserver in front of > internal.directory.org if for some reason it can't do TLSv1.2 / bigger > certs / legacy clients / etc. > > Similarly one can do similarish things on client, i.e. download the > older gnutls28 from the archive/launchpad and LD_PRELOAD the old > libgnutls30 - the api/abi should have stayed stable to do that. > > > -- > Regards, > > Dimitri. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Jan 23 13:00:00 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 23 Jan 2020 13:00:00 +0100 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers wrote: > > Hello everyone: > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. > > From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. > > I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available priority strings are documented in: https://gnutls.org/manual/html_node/Priority-Strings.html regards, Nikos From xnox at ubuntu.com Thu Jan 23 13:16:14 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Thu, 23 Jan 2020 14:16:14 +0200 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos wrote: > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers wrote: > > > > Hello everyone: > > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. > > > > From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. > > > > I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. > > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available > priority strings are documented in: > https://gnutls.org/manual/html_node/Priority-Strings.html > >From what I can tell is that the backports do not include that flag.... I'm escalating this, as this is regression-security as I do not believe that upstream code is affected as this is an issue in the patch set released in ubuntu. I hope to move this discussion downstream to https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 -- Regards, Dimitri. From brandor5 at gmail.com Thu Jan 23 14:39:35 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Thu, 23 Jan 2020 08:39:35 -0500 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: Thank you very much! I will track the bug there. Thanks, Brandon On Thu, Jan 23, 2020, 07:16 Dimitri John Ledkov wrote: > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos > wrote: > > > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers > wrote: > > > > > > Hello everyone: > > > > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 > (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still > in the process of migrating our last services off of SHA1 with a target > date of April this has put us in a pickle. > > > > > > From reading the docs I expect I should be able to use priority and > allow SHA1 to function, however making this work has been rather > frustrating. > > > > > > I've tried several different versions of the following command but I > would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should > work. > > > > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem > --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available > > priority strings are documented in: > > https://gnutls.org/manual/html_node/Priority-Strings.html > > > > From what I can tell is that the backports do not include that > flag.... I'm escalating this, as this is regression-security as I do > not believe that upstream code is affected as this is an issue in the > patch set released in ubuntu. > > I hope to move this discussion downstream to > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 > > > -- > Regards, > > Dimitri. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnox at ubuntu.com Sun Jan 26 22:56:16 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Sun, 26 Jan 2020 21:56:16 +0000 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov wrote: > > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos wrote: > > > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers wrote: > > > > > > Hello everyone: > > > > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. > > > > > > From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. > > > > > > I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. > > > > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available > > priority strings are documented in: > > https://gnutls.org/manual/html_node/Priority-Strings.html > > > > From what I can tell is that the backports do not include that > flag.... I'm escalating this, as this is regression-security as I do > not believe that upstream code is affected as this is an issue in the > patch set released in ubuntu. > > I hope to move this discussion downstream to > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 > To close this out, a further update got published to the affected releases which adds support to use "%VERIFY_ALLOW_BROKEN" and "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing one to re-enable obsoleted hashes in certificate signatures. But please upgrade your certificates to use SHA256 nonetheless as progressively more software will start outright reject SHA1 certificates without a way to turn them back on. -- Regards, Dimitri. From brandor5 at gmail.com Sun Jan 26 23:18:14 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Sun, 26 Jan 2020 17:18:14 -0500 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: Thanks for the help. We are already in the process of updating so of the certs. Thanks for the reminder. Now I just need to figure out how to have the priority strong apply system wide instead of just gnutls-cli. Any tips there? Thanks again, Brandon On Sun, Jan 26, 2020, 16:56 Dimitri John Ledkov wrote: > On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov wrote: > > > > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos > wrote: > > > > > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers > wrote: > > > > > > > > Hello everyone: > > > > > > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and > 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are > still in the process of migrating our last services off of SHA1 with a > target date of April this has put us in a pickle. > > > > > > > > From reading the docs I expect I should be able to use priority and > allow SHA1 to function, however making this work has been rather > frustrating. > > > > > > > > I've tried several different versions of the following command but I > would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should > work. > > > > > > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem > --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > > > > > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available > > > priority strings are documented in: > > > https://gnutls.org/manual/html_node/Priority-Strings.html > > > > > > > From what I can tell is that the backports do not include that > > flag.... I'm escalating this, as this is regression-security as I do > > not believe that upstream code is affected as this is an issue in the > > patch set released in ubuntu. > > > > I hope to move this discussion downstream to > > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 > > > > To close this out, a further update got published to the affected > releases which adds support to use "%VERIFY_ALLOW_BROKEN" and > "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing > one to re-enable obsoleted hashes in certificate signatures. > > But please upgrade your certificates to use SHA256 nonetheless as > progressively more software will start outright reject SHA1 > certificates without a way to turn them back on. > > -- > Regards, > > Dimitri. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandor5 at gmail.com Mon Jan 27 05:27:41 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Sun, 26 Jan 2020 23:27:41 -0500 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: Sorry, I should have made it clear before. I've tried putting the string in both /etc/gnutls/config and /etc/gnutls/default-priorites according to the docs I found but, neither worked. Thanks, On Sun, Jan 26, 2020, 17:18 Brandon Sawyers wrote: > Thanks for the help. > > We are already in the process of updating so of the certs. Thanks for the > reminder. > > Now I just need to figure out how to have the priority strong apply system > wide instead of just gnutls-cli. > > Any tips there? > > Thanks again, > Brandon > > > > On Sun, Jan 26, 2020, 16:56 Dimitri John Ledkov wrote: > >> On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov >> wrote: >> > >> > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos >> wrote: >> > > >> > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers >> wrote: >> > > > >> > > > Hello everyone: >> > > > >> > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and >> 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are >> still in the process of migrating our last services off of SHA1 with a >> target date of April this has put us in a pickle. >> > > > >> > > > From reading the docs I expect I should be able to use priority and >> allow SHA1 to function, however making this work has been rather >> frustrating. >> > > > >> > > > I've tried several different versions of the following command but >> I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set >> should work. >> > > > >> > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem >> --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` >> > > >> > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available >> > > priority strings are documented in: >> > > https://gnutls.org/manual/html_node/Priority-Strings.html >> > > >> > >> > From what I can tell is that the backports do not include that >> > flag.... I'm escalating this, as this is regression-security as I do >> > not believe that upstream code is affected as this is an issue in the >> > patch set released in ubuntu. >> > >> > I hope to move this discussion downstream to >> > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 >> > >> >> To close this out, a further update got published to the affected >> releases which adds support to use "%VERIFY_ALLOW_BROKEN" and >> "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing >> one to re-enable obsoleted hashes in certificate signatures. >> >> But please upgrade your certificates to use SHA256 nonetheless as >> progressively more software will start outright reject SHA1 >> certificates without a way to turn them back on. >> >> -- >> Regards, >> >> Dimitri. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Jan 30 10:33:11 2020 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Jan 2020 10:33:11 +0100 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: I do not think (but please correct me), that this version of ubuntu you're using has something like a system-wide policy, so it will not be possible to change the sha1 acceptance system-wide. In that case it will be more effective to try and change the priority string on the specific applications you are interested. The newer versions of gnutls have a more powerful configuration that can be used to implement a modifiable system-wide policy. regards, Nikos On Mon, Jan 27, 2020 at 5:29 AM Brandon Sawyers wrote: > > Sorry, I should have made it clear before. > > I've tried putting the string in both /etc/gnutls/config and /etc/gnutls/default-priorites according to the docs I found but, neither worked. > > Thanks, > > On Sun, Jan 26, 2020, 17:18 Brandon Sawyers wrote: >> >> Thanks for the help. >> >> We are already in the process of updating so of the certs. Thanks for the reminder. >> >> Now I just need to figure out how to have the priority strong apply system wide instead of just gnutls-cli. >> >> Any tips there? >> >> Thanks again, >> Brandon >> >> >> >> On Sun, Jan 26, 2020, 16:56 Dimitri John Ledkov wrote: >>> >>> On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov wrote: >>> > >>> > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos wrote: >>> > > >>> > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers wrote: >>> > > > >>> > > > Hello everyone: >>> > > > >>> > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are still in the process of migrating our last services off of SHA1 with a target date of April this has put us in a pickle. >>> > > > >>> > > > From reading the docs I expect I should be able to use priority and allow SHA1 to function, however making this work has been rather frustrating. >>> > > > >>> > > > I've tried several different versions of the following command but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set should work. >>> > > > >>> > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` >>> > > >>> > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The available >>> > > priority strings are documented in: >>> > > https://gnutls.org/manual/html_node/Priority-Strings.html >>> > > >>> > >>> > From what I can tell is that the backports do not include that >>> > flag.... I'm escalating this, as this is regression-security as I do >>> > not believe that upstream code is affected as this is an issue in the >>> > patch set released in ubuntu. >>> > >>> > I hope to move this discussion downstream to >>> > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 >>> > >>> >>> To close this out, a further update got published to the affected >>> releases which adds support to use "%VERIFY_ALLOW_BROKEN" and >>> "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing >>> one to re-enable obsoleted hashes in certificate signatures. >>> >>> But please upgrade your certificates to use SHA256 nonetheless as >>> progressively more software will start outright reject SHA1 >>> certificates without a way to turn them back on. >>> >>> -- >>> Regards, >>> >>> Dimitri. > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From brandor5 at gmail.com Thu Jan 30 18:35:45 2020 From: brandor5 at gmail.com (Brandon Sawyers) Date: Thu, 30 Jan 2020 12:35:45 -0500 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: Yes that's the conclusion we came to as well. Our plan is to hold updates to libgnutls30 until we can update the bad cert. Thanks, On Thu, Jan 30, 2020, 04:33 Nikos Mavrogiannopoulos wrote: > I do not think (but please correct me), that this version of ubuntu > you're using has something like a system-wide policy, so it will not > be possible to change the sha1 acceptance system-wide. In that case it > will be more effective to try and change the priority string on the > specific applications you are interested. The newer versions of gnutls > have a more powerful configuration that can be used to implement a > modifiable system-wide policy. > > regards, > Nikos > > On Mon, Jan 27, 2020 at 5:29 AM Brandon Sawyers > wrote: > > > > Sorry, I should have made it clear before. > > > > I've tried putting the string in both /etc/gnutls/config and > /etc/gnutls/default-priorites according to the docs I found but, neither > worked. > > > > Thanks, > > > > On Sun, Jan 26, 2020, 17:18 Brandon Sawyers wrote: > >> > >> Thanks for the help. > >> > >> We are already in the process of updating so of the certs. Thanks for > the reminder. > >> > >> Now I just need to figure out how to have the priority strong apply > system wide instead of just gnutls-cli. > >> > >> Any tips there? > >> > >> Thanks again, > >> Brandon > >> > >> > >> > >> On Sun, Jan 26, 2020, 16:56 Dimitri John Ledkov > wrote: > >>> > >>> On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov > wrote: > >>> > > >>> > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos < > nmav at gnutls.org> wrote: > >>> > > > >>> > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers < > brandor5 at gmail.com> wrote: > >>> > > > > >>> > > > Hello everyone: > >>> > > > > >>> > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) and > 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we are > still in the process of migrating our last services off of SHA1 with a > target date of April this has put us in a pickle. > >>> > > > > >>> > > > From reading the docs I expect I should be able to use priority > and allow SHA1 to function, however making this work has been rather > frustrating. > >>> > > > > >>> > > > I've tried several different versions of the following command > but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set > should work. > >>> > > > > >>> > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem > --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` > >>> > > > >>> > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The > available > >>> > > priority strings are documented in: > >>> > > https://gnutls.org/manual/html_node/Priority-Strings.html > >>> > > > >>> > > >>> > From what I can tell is that the backports do not include that > >>> > flag.... I'm escalating this, as this is regression-security as I do > >>> > not believe that upstream code is affected as this is an issue in the > >>> > patch set released in ubuntu. > >>> > > >>> > I hope to move this discussion downstream to > >>> > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 > >>> > > >>> > >>> To close this out, a further update got published to the affected > >>> releases which adds support to use "%VERIFY_ALLOW_BROKEN" and > >>> "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing > >>> one to re-enable obsoleted hashes in certificate signatures. > >>> > >>> But please upgrade your certificates to use SHA256 nonetheless as > >>> progressively more software will start outright reject SHA1 > >>> certificates without a way to turn them back on. > >>> > >>> -- > >>> Regards, > >>> > >>> Dimitri. > > > > _______________________________________________ > > Gnutls-help mailing list > > Gnutls-help at lists.gnutls.org > > http://lists.gnupg.org/mailman/listinfo/gnutls-help > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnox at ubuntu.com Thu Jan 30 23:54:01 2020 From: xnox at ubuntu.com (Dimitri John Ledkov) Date: Thu, 30 Jan 2020 22:54:01 +0000 Subject: [gnutls-help] Help allowing SHA1 In-Reply-To: References: Message-ID: I think apt pinning down the update is the best option you have for now. In gnutls master, I have added a straight forward default priority barring override, such that if something like this happens in 20.04 LTS there will be a straight forward to apply a different global default. On Thu, 30 Jan 2020, 17:35 Brandon Sawyers, wrote: > Yes that's the conclusion we came to as well. > > Our plan is to hold updates to libgnutls30 until we can update the bad > cert. > > Thanks, > > On Thu, Jan 30, 2020, 04:33 Nikos Mavrogiannopoulos > wrote: > >> I do not think (but please correct me), that this version of ubuntu >> you're using has something like a system-wide policy, so it will not >> be possible to change the sha1 acceptance system-wide. In that case it >> will be more effective to try and change the priority string on the >> specific applications you are interested. The newer versions of gnutls >> have a more powerful configuration that can be used to implement a >> modifiable system-wide policy. >> >> regards, >> Nikos >> >> On Mon, Jan 27, 2020 at 5:29 AM Brandon Sawyers >> wrote: >> > >> > Sorry, I should have made it clear before. >> > >> > I've tried putting the string in both /etc/gnutls/config and >> /etc/gnutls/default-priorites according to the docs I found but, neither >> worked. >> > >> > Thanks, >> > >> > On Sun, Jan 26, 2020, 17:18 Brandon Sawyers wrote: >> >> >> >> Thanks for the help. >> >> >> >> We are already in the process of updating so of the certs. Thanks for >> the reminder. >> >> >> >> Now I just need to figure out how to have the priority strong apply >> system wide instead of just gnutls-cli. >> >> >> >> Any tips there? >> >> >> >> Thanks again, >> >> Brandon >> >> >> >> >> >> >> >> On Sun, Jan 26, 2020, 16:56 Dimitri John Ledkov >> wrote: >> >>> >> >>> On Thu, 23 Jan 2020 at 12:16, Dimitri John Ledkov >> wrote: >> >>> > >> >>> > On Thu, 23 Jan 2020 at 14:01, Nikos Mavrogiannopoulos < >> nmav at gnutls.org> wrote: >> >>> > > >> >>> > > On Wed, Jan 22, 2020 at 3:42 PM Brandon Sawyers < >> brandor5 at gmail.com> wrote: >> >>> > > > >> >>> > > > Hello everyone: >> >>> > > > >> >>> > > > A recent package upgrade in ubuntu 1604 (v3.4.10-4ubuntu1.6) >> and 1804 (v3.5.18-1ubuntu1.2) has left us without SHA1 support. Since we >> are still in the process of migrating our last services off of SHA1 with a >> target date of April this has put us in a pickle. >> >>> > > > >> >>> > > > From reading the docs I expect I should be able to use priority >> and allow SHA1 to function, however making this work has been rather >> frustrating. >> >>> > > > >> >>> > > > I've tried several different versions of the following command >> but I would expect just having "NORMAL:+SIGN-RSA-SHA1:+SHA1" priority set >> should work. >> >>> > > > >> >>> > > > `gnutls-bin --x509cafile ./cachain-with-sha1-signed-cert.pem >> --priority='NORMAL:+SIGN-RSA-SHA1:+SHA1' -p 636 internal.directory.org` >> >>> > > >> >>> > > Have you tried appending %VERIFY_ALLOW_SIGN_WITH_SHA1? The >> available >> >>> > > priority strings are documented in: >> >>> > > https://gnutls.org/manual/html_node/Priority-Strings.html >> >>> > > >> >>> > >> >>> > From what I can tell is that the backports do not include that >> >>> > flag.... I'm escalating this, as this is regression-security as I do >> >>> > not believe that upstream code is affected as this is an issue in >> the >> >>> > patch set released in ubuntu. >> >>> > >> >>> > I hope to move this discussion downstream to >> >>> > https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1860656 >> >>> > >> >>> >> >>> To close this out, a further update got published to the affected >> >>> releases which adds support to use "%VERIFY_ALLOW_BROKEN" and >> >>> "%VERIFY_ALLOW_SIGN_WITH_SHA1" in the priority string option, allowing >> >>> one to re-enable obsoleted hashes in certificate signatures. >> >>> >> >>> But please upgrade your certificates to use SHA256 nonetheless as >> >>> progressively more software will start outright reject SHA1 >> >>> certificates without a way to turn them back on. >> >>> >> >>> -- >> >>> Regards, >> >>> >> >>> Dimitri. >> > >> > _______________________________________________ >> > Gnutls-help mailing list >> > Gnutls-help at lists.gnutls.org >> > http://lists.gnupg.org/mailman/listinfo/gnutls-help >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: