From ml at tocario.com Thu Aug 2 17:47:30 2018 From: ml at tocario.com (Mario Lombardo) Date: Thu, 2 Aug 2018 17:47:30 +0200 Subject: [gnutls-help] =?utf-8?q?TLS-Server_with_Let=E2=80=99s_Encrypt?= Message-ID: <671B4029-872F-4098-9DA8-FA05610F5058@tocario.com> Hi gnutls team, I?m looking for a way how to use gnutls for a TLS server in combination with Let?s Encrypt. As the validity of those certificates is just a couple of weeks, I would like to replace the current server key by new ones without restarting the server. The implementation is basically like this: // create credstore gnutls_certificate_allocate_credentials(&(ctx->tls_x509_cred)); // load x509 key pair gtls_returncode = gnutls_certificate_set_x509_key_file(ctx->tls_x509_cred, ctx->config->cert_bundle, ctx->config->key_file, GNUTLS_X509_FMT_PEM); // install signal handler signal(SIGUSR1, signal_handler); Once the signal SIGUSR1 arrives, I would like to re-read x509 stuff. The only solution I found (yet) is to free the credstore and allocate a new one (then read new keys). This has some downsides, as the server is not working anymore if there is something wrong with the key pair, because I already freed the existing credstore (here ctx->tls_x509_cred). And even this is the only way to proceed?do I need to block any incoming connections in the meantime? How long (in the process of the handshake) is blocking required (in other words: do I need to track if there are existing sockets in the handshake phase or is this safe as long as one handshake try for non-blocking sockets was done)? Is there any reference code/function to replace a key pair? I had a look into the apache2 module but as it seems, this module does not support a certificate change on reload. Any hints are welcome. Thank you. Mario From mrsam at courier-mta.com Thu Aug 2 23:14:46 2018 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Thu, 02 Aug 2018 17:14:46 -0400 Subject: [gnutls-help] =?utf-8?q?TLS-Server_with_Let=E2=80=99s_Encrypt?= References: <671B4029-872F-4098-9DA8-FA05610F5058@tocario.com> Message-ID: Mario Lombardo writes: > Hi gnutls team, > > I?m looking for a way how to use gnutls for a TLS server in combination with > Let?s Encrypt. As the validity of those certificates is just a couple of > weeks, I would like to replace the current server key by new ones without > restarting the server. > > The implementation is basically like this: > // create credstore > gnutls_certificate_allocate_credentials(&(ctx->tls_x509_cred)); > // load x509 key pair > gtls_returncode = gnutls_certificate_set_x509_key_file(ctx->tls_x509_cred, > ctx->config->cert_bundle, ctx->config->key_file, GNUTLS_X509_FMT_PEM); > // install signal handler > signal(SIGUSR1, signal_handler); > > Once the signal SIGUSR1 arrives, I would like to re-read x509 stuff. > > The only solution I found (yet) is to free the credstore and allocate a new > one (then read new keys). This has some downsides, as the server is not > working anymore if there is something wrong with the key pair, because I > already freed the existing credstore (here ctx->tls_x509_cred). And even Instead of gnutls_certificate_free_credentials() your old credential store first, and then gnutls_certificate_allocate_credentials() a new one and hope for the best, why don't you try gnutls_certificate_allocate_credentials() first, and if your endeavor succeeds you can free the old one, and replace it with the new one. You are gnutls_certificate_free_credentials() your old credential store first, right? Because if this is all what you do, that's shown above, then you must be leaking memory. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From ml at tocario.com Fri Aug 3 12:14:36 2018 From: ml at tocario.com (Mario Lombardo) Date: Fri, 3 Aug 2018 12:14:36 +0200 Subject: [gnutls-help] =?utf-8?q?TLS-Server_with_Let=E2=80=99s_Encrypt?= In-Reply-To: References: <671B4029-872F-4098-9DA8-FA05610F5058@tocario.com> Message-ID: <1CD93FB3-6339-4417-9B4F-B00911A1D544@tocario.com> Hi Sam, thank you for your message. What about the existing sessions (gnutls_session_t)? Can I call gnutls_credentials_clear() once the handshake is finished and keep the connection for this session established? I believe it is not safe to gnutls_certificate_free_credentials() as long as there are sessions bound to this store, is it? Or is there any other best practice? Can I set other credentials on an existing session (after handshake)? Thanks in advance. Mario > On 2. Aug 2018, at 23:14, Sam Varshavchik wrote: > > Signed PGP part > Mario Lombardo writes: > >> Hi gnutls team, >> >> I?m looking for a way how to use gnutls for a TLS server in combination with Let?s Encrypt. As the validity of those certificates is just a couple of weeks, I would like to replace the current server key by new ones without restarting the server. >> >> The implementation is basically like this: >> // create credstore >> gnutls_certificate_allocate_credentials(&(ctx->tls_x509_cred)); >> // load x509 key pair >> gtls_returncode = gnutls_certificate_set_x509_key_file(ctx->tls_x509_cred, ctx->config->cert_bundle, ctx->config->key_file, GNUTLS_X509_FMT_PEM); >> // install signal handler >> signal(SIGUSR1, signal_handler); >> >> Once the signal SIGUSR1 arrives, I would like to re-read x509 stuff. >> >> The only solution I found (yet) is to free the credstore and allocate a new one (then read new keys). This has some downsides, as the server is not working anymore if there is something wrong with the key pair, because I already freed the existing credstore (here ctx->tls_x509_cred). And even > > Instead of gnutls_certificate_free_credentials() your old credential store first, and then gnutls_certificate_allocate_credentials() a new one and hope for the best, why don't you try gnutls_certificate_allocate_credentials() first, and if your endeavor succeeds you can free the old one, and replace it with the new one. > > You are gnutls_certificate_free_credentials() your old credential store first, right? Because if this is all what you do, that's shown above, then you must be leaking memory. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrsam at courier-mta.com Fri Aug 3 12:59:26 2018 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 03 Aug 2018 06:59:26 -0400 Subject: [gnutls-help] =?utf-8?q?TLS-Server_with_Let=E2=80=99s_Encrypt?= References: <671B4029-872F-4098-9DA8-FA05610F5058@tocario.com> <1CD93FB3-6339-4417-9B4F-B00911A1D544@tocario.com> Message-ID: Mario Lombardo writes: > Hi Sam, > > > thank you for your message. What about the existing sessions > (gnutls_session_t)? Can I call?gnutls_credentials_clear() once the handshake > is finished and keep the connection for this session established? I believe > it is not safe to?gnutls_certificate_free_credentials() as long as there are > sessions bound to this store, is it? Presuming there are no multiple thread-related issues, I would expect it to be safe. If the library needs it, for some reason, I expect it to make its own copy. I find nothing in the public documentation that requires credential to exist as long as some session that used them, initially, is still around. > Or is there any other best practice? Can I set other credentials on an > existing session (after handshake)? You can also take the approach of creating a new context for all new sessions, and keep the old context, with the old credentials, until all existing session which use it go away. I don't believe this is necessary, but this is also one possible way to do it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From jgh at wizmail.org Thu Aug 9 23:16:53 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 9 Aug 2018 22:16:53 +0100 Subject: [gnutls-help] priority strings Message-ID: Hi, My code is trying to do: gnutls_priority_init(NONE:+VERS-TLS-ALL:+MAC-ALL:+RSA:+AES-128-CBC:+CAMELLIA-256-GCM:+SIGN-ALL:+COMP-NULL) This used to work, I think with a previous library version. Under GnuTLS 3.6.3 (on f28) I'm getting: "failed at offset 0, "NONE:+VE.." failed: No or insufficient priorities were set". The manual at https://gnutls.org/manual/html_node/Priority-Strings.html still says, in Table 6.3 for "NONE": "Means nothing is enabled. This disables even protocol versions. It should be followed by the algorithms to be enabled." What should I now be using? -- Thanks, Jeremy From ametzler at bebt.de Sat Aug 11 07:01:35 2018 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 11 Aug 2018 07:01:35 +0200 Subject: [gnutls-help] priority strings References: Message-ID: <20180811050135.GA1403@argenau.bebt.de> Jeremy Harris wrote: > My code is trying to do: > gnutls_priority_init(NONE:+VERS-TLS-ALL:+MAC-ALL:+RSA:+AES-128-CBC:+CAMELLIA-256-GCM:+SIGN-ALL:+COMP-NULL) > This used to work, I think with a previous library version. > Under GnuTLS 3.6.3 (on f28) I'm getting: > "failed at offset 0, "NONE:+VE.." failed: No or insufficient priorities were set". > The manual at https://gnutls.org/manual/html_node/Priority-Strings.html still > says, in Table 6.3 for "NONE": > "Means nothing is enabled. This disables even protocol versions. > It should be followed by the algorithms to be enabled." > What should I now be using? Hello, playing around with gnutls-cli -l --priority '...' it looks like adding ':+GROUP-ALL' succeeds. I am not sure this makes sense, though, and it has the downside of not being accepted by GnuTLS 3.5.x. How about NORMAL:-VERS-ALL:+VERS-TLS-ALL:-KX-ALL:+RSA:-CIPHER-ALL:+AES-128-CBC:+CAMELLIA-256-GCM:-COMP-ALL:+COMP-NULL 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 nmav at gnutls.org Mon Aug 13 08:25:37 2018 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 13 Aug 2018 08:25:37 +0200 Subject: [gnutls-help] priority strings In-Reply-To: <20180811050135.GA1403@argenau.bebt.de> References: <20180811050135.GA1403@argenau.bebt.de> Message-ID: On Sat, Aug 11, 2018 at 7:01 AM, Andreas Metzler wrote: > Jeremy Harris wrote: >> My code is trying to do: > >> gnutls_priority_init(NONE:+VERS-TLS-ALL:+MAC-ALL:+RSA:+AES-128-CBC:+CAMELLIA-256-GCM:+SIGN-ALL:+COMP-NULL) > >> This used to work, I think with a previous library version. >> Under GnuTLS 3.6.3 (on f28) I'm getting: > >> "failed at offset 0, "NONE:+VE.." failed: No or insufficient priorities were set". > > >> The manual at https://gnutls.org/manual/html_node/Priority-Strings.html still >> says, in Table 6.3 for "NONE": > >> "Means nothing is enabled. This disables even protocol versions. >> It should be followed by the algorithms to be enabled." > > >> What should I now be using? > > Hello, > > playing around with > gnutls-cli -l --priority '...' > it looks like adding ':+GROUP-ALL' succeeds. I am not sure this makes > sense, though, and it has the downside of not being accepted by GnuTLS > 3.5.x. Maybe we should document that the none + build up approach is version-specific and cannot be guaranteed to work on protocol updates, or across minor gnutls version updates. That was not the original intention, but in practice over every TLS update (1.1 -> 1.2 -> 1.3) these strings that were derived from none broke. > How about > NORMAL:-VERS-ALL:+VERS-TLS-ALL:-KX-ALL:+RSA:-CIPHER-ALL:+AES-128-CBC:+CAMELLIA-256-GCM:-COMP-ALL:+COMP-NULL That is certainly much better, but from the perspective of someone who has seen numerous of these priority strings in applications, I'd really recommend using the defaults. Applications typically keep that string fixed for more than a decade whereas gnutls defaults gets updated (quite conservatively) to eliminate insecure configurations and add new ciphers (think of SSL3.0, RC4, 3DES, DSA etc). As such, I'd recommend gnutls_set_default_priority() or gnutls_set_default_priority_append() -in 3.6.x-. regards, Nikos From jgh at wizmail.org Mon Aug 20 14:33:40 2018 From: jgh at wizmail.org (Jeremy Harris) Date: Mon, 20 Aug 2018 13:33:40 +0100 Subject: [gnutls-help] priority strings In-Reply-To: References: <20180811050135.GA1403@argenau.bebt.de> Message-ID: <95c929b1-2153-dc1f-b38a-eb4207a035c6@wizmail.org> On 08/13/2018 07:25 AM, Nikos Mavrogiannopoulos wrote: > Maybe we should document that the none + build up approach is > version-specific and cannot be guaranteed to work on protocol updates, > or across minor gnutls version updates. That was not the original > intention, but in practice over every TLS update (1.1 -> 1.2 -> 1.3) > these strings that were derived from none broke. > >> How about >> NORMAL:-VERS-ALL:+VERS-TLS-ALL:-KX-ALL:+RSA:-CIPHER-ALL:+AES-128-CBC:+CAMELLIA-256-GCM:-COMP-ALL:+COMP-NULL > > That is certainly much better, but from the perspective of someone who > has seen numerous of these priority strings in applications, I'd > really recommend using the defaults. The use-case here is for testing an application. So I need to be able to set odd combinations, for example to check what happens at application level when the TL connect fails for lack of compatible key-exchange. Having to make the testsuite tls-library-version aware would be sucky. Also fails, presumably for equivalent reasons: gnutls_priority_init(NORMAL:!MAC-ALL:+MD5) failed at offset 0, "NORMAL.."): No or insufficient priorities were set. -- Cheers, Jeremy From nmav at gnutls.org Mon Aug 20 14:59:16 2018 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Aug 2018 14:59:16 +0200 Subject: [gnutls-help] priority strings In-Reply-To: <95c929b1-2153-dc1f-b38a-eb4207a035c6@wizmail.org> References: <20180811050135.GA1403@argenau.bebt.de> <95c929b1-2153-dc1f-b38a-eb4207a035c6@wizmail.org> Message-ID: On Mon, Aug 20, 2018 at 2:33 PM, Jeremy Harris wrote: > On 08/13/2018 07:25 AM, Nikos Mavrogiannopoulos wrote: >> Maybe we should document that the none + build up approach is >> version-specific and cannot be guaranteed to work on protocol updates, >> or across minor gnutls version updates. That was not the original >> intention, but in practice over every TLS update (1.1 -> 1.2 -> 1.3) >> these strings that were derived from none broke. >> >>> How about >>> NORMAL:-VERS-ALL:+VERS-TLS-ALL:-KX-ALL:+RSA:-CIPHER-ALL:+AES-128-CBC:+CAMELLIA-256-GCM:-COMP-ALL:+COMP-NULL >> >> That is certainly much better, but from the perspective of someone who >> has seen numerous of these priority strings in applications, I'd >> really recommend using the defaults. > > The use-case here is for testing an application. So I need > to be able to set odd combinations, for example to check > what happens at application level when the TL connect > fails for lack of compatible key-exchange. > > Having to make the testsuite tls-library-version aware > would be sucky. > > > > > Also fails, presumably for equivalent reasons: > > gnutls_priority_init(NORMAL:!MAC-ALL:+MD5) failed at offset 0, > "NORMAL.."): No or insufficient priorities were set. Because you are adding MD5 which is only available in combination with RC4. RC4 is no longer included in the NORMAL set, so you'd need something like: 'NORMAL:-MAC-ALL:+MD5:+ARCFOUR-128' regards, Nikos From nmav at gnutls.org Mon Aug 20 15:06:26 2018 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Aug 2018 15:06:26 +0200 Subject: [gnutls-help] priority strings In-Reply-To: References: <20180811050135.GA1403@argenau.bebt.de> <95c929b1-2153-dc1f-b38a-eb4207a035c6@wizmail.org> Message-ID: On Mon, Aug 20, 2018 at 2:59 PM, Nikos Mavrogiannopoulos wrote: >>> >>>> How about >>>> NORMAL:-VERS-ALL:+VERS-TLS-ALL:-KX-ALL:+RSA:-CIPHER-ALL:+AES-128-CBC:+CAMELLIA-256-GCM:-COMP-ALL:+COMP-NULL >>> >>> That is certainly much better, but from the perspective of someone who >>> has seen numerous of these priority strings in applications, I'd >>> really recommend using the defaults. >> >> The use-case here is for testing an application. So I need >> to be able to set odd combinations, for example to check >> what happens at application level when the TL connect >> fails for lack of compatible key-exchange. >> >> Having to make the testsuite tls-library-version aware >> would be sucky. >> >> >> >> >> Also fails, presumably for equivalent reasons: >> >> gnutls_priority_init(NORMAL:!MAC-ALL:+MD5) failed at offset 0, >> "NORMAL.."): No or insufficient priorities were set. > > Because you are adding MD5 which is only available in combination with > RC4. RC4 is no longer included in the NORMAL set, so you'd need > something like: > 'NORMAL:-MAC-ALL:+MD5:+ARCFOUR-128' Do you have a list of strings with NONE that fail with 3.6.x? Maybe we can have a work-around and enable any missing items in that case, though it will be tricky to distinguish intentional leaving out of parameters and unintentional one. regards, Nikos