From nmav at gnutls.org Wed Jun 1 16:24:13 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 1 Jun 2016 16:24:13 +0200 Subject: [gnutls-devel] Support for OCSP Must-staple ? In-Reply-To: <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org> References: <7143243.RrO4Tg8rEH@blitz-lx> <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org> Message-ID: On Mon, May 23, 2016 at 11:50 PM, Tim Kosse wrote: > If I remember correctly, the following things are still missing: > - More unit tests > - Copying of the feature extension data from CRQs into the generated > certificates Hi, That was already handled (but needed the honor_crq_extensions template directive). I've included this as a functionality check in cert-tests/tlsfeature-test. > - Dealing with certificate chains as described in section 4.2.2 of RFC7633 This should now be complete. https://gitlab.com/gnutls/gnutls/merge_requests/11 I've created it as a merge request, since it touches the verification boundary which is quite sensitive. If you (or anyone else) would like to review it, I'd appreciate it. The most concerning commits are 132d3f84 and 39c1239c . regards, Nikos From tim.kosse at filezilla-project.org Wed Jun 1 18:40:53 2016 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Wed, 1 Jun 2016 18:40:53 +0200 Subject: [gnutls-devel] Support for OCSP Must-staple ? In-Reply-To: References: <7143243.RrO4Tg8rEH@blitz-lx> <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org> Message-ID: <8c5cf452-0dcb-87ee-ca12-c0c978478690@filezilla-project.org> Hi, I had a look at the merge request. While I couldn't find any major issues, there are still a few small things that should probably be fixed: verify_crt in lib/x509/verify.c: Function description still mentions the removed issuer parameter verify_crt in lib/x509/verify.c: The TLS feature check re-uses the nc_done label from the name constraints checks. While the functionality is correct right now, it's an easy source for errors should this function be changed in the future. I suggest moving the TLS feature checking below the nc_done label and adding a separate feat_done label. gnutls_x509_tlsfeatures_crt in lib/x509/tls_features.c: Line 240, format specifier doesn't match type of arguments. The size in gnutls_x509_tlsfeatures_t is unsigned int. parse_tlsfeatures in lib/x509/x509_ext.c: The size limitation check should be done after the duplicate check, otherwise appending fails when verifying chains where certificates use the maximum allowed number of features. tests/tlsfeature-ext.c: Lines 145 and 146: The comment doesn't match the assert. Regards, Tim On 2016-06-01 16:24, Nikos Mavrogiannopoulos wrote: > On Mon, May 23, 2016 at 11:50 PM, Tim Kosse > wrote: >> If I remember correctly, the following things are still missing: >> - More unit tests >> - Copying of the feature extension data from CRQs into the generated >> certificates > > Hi, > That was already handled (but needed the honor_crq_extensions > template directive). I've included this as a functionality check in > cert-tests/tlsfeature-test. > >> - Dealing with certificate chains as described in section 4.2.2 of RFC7633 > > This should now be complete. > https://gitlab.com/gnutls/gnutls/merge_requests/11 > > I've created it as a merge request, since it touches the verification > boundary which is quite sensitive. If you (or anyone else) would like > to review it, I'd appreciate it. The most concerning commits are > 132d3f84 and 39c1239c . > > regards, > Nikos > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > From berrange at redhat.com Fri Jun 3 15:56:38 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 3 Jun 2016 14:56:38 +0100 Subject: [gnutls-devel] DCO statement Message-ID: <20160603135637.GM13827@redhat.com> Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From berrange at redhat.com Fri Jun 3 15:59:11 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 3 Jun 2016 14:59:11 +0100 Subject: [gnutls-devel] [PATCH] _gnutls_resolve_priorities: always try to re-read sys priority file Message-ID: <1464962351-15505-1-git-send-email-berrange@redhat.com> Previously if the system priority file was edited, that would take effect on the very next TLS session an application created. As of: commit 006b89d4464ae1bb6d545ea5716998654124df45 Author: Nikos Mavrogiannopoulos Date: Fri Apr 1 10:46:12 2016 +0200 priorities: preload the system priorities on library loading time It is required to restart every application after changing the system priority file to get changes to take effect. Further, for applications running in a chroot, it will no longer honour a system priority file that may exist inside the chroot, always using the originally cached data from outside the chroot. This patch changes the caching so that we always try to reload the cache of system priorities. A mtime check is used to avoid actually re-reading the file unless its content has obviously changed. If the file no longer exists, the cache will not be invalidated. This ensures that the current priority file is always honoured, whether inside a chroot or not, while at the same time allowing apps to work in a chroot when no system priority file is present. Signed-off-by: Daniel P. Berrange --- lib/priority.c | 55 +++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 45 insertions(+), 10 deletions(-) diff --git a/lib/priority.c b/lib/priority.c index 14b6251..5fcc97f 100644 --- a/lib/priority.c +++ b/lib/priority.c @@ -32,6 +32,7 @@ #include #include #include "fips.h" +#include "errno.h" #define MAX_ELEMENTS 64 @@ -926,26 +927,54 @@ static char *check_str(char *line, size_t line_size, const char *needle, size_t static const char *system_priority_file = SYSTEM_PRIORITY_FILE; static char *system_priority_buf = NULL; static size_t system_priority_buf_size = 0; +static time_t system_priority_last_mod = 0; -void _gnutls_load_system_priorities(void) + +static void _gnutls_update_system_priorities(void) { +#ifdef HAVE_FMEMOPEN gnutls_datum_t data; - const char *p; int ret; + struct stat sb; - p = secure_getenv("GNUTLS_SYSTEM_PRIORITY_FILE"); - if (p != NULL) - system_priority_file = p; + if (stat(system_priority_file, &sb) < 0) { + _gnutls_debug_log("unable to access: %s: %d\n", + system_priority_file, errno); + return; + } + + if (sb.st_mtime == system_priority_last_mod) { + _gnutls_debug_log("system priority %s has not changed\n", + system_priority_file); + return; + } -#ifdef HAVE_FMEMOPEN ret = gnutls_load_file(system_priority_file, &data); - if (ret < 0) + if (ret < 0) { + _gnutls_debug_log("unable to load: %s: %d\n", + system_priority_file, ret); return; + } + _gnutls_debug_log("cached system priority %s mtime %lld\n", + system_priority_file, + (unsigned long long)sb.st_mtime); + gnutls_free(system_priority_buf); system_priority_buf = (char*)data.data; system_priority_buf_size = data.size; + system_priority_last_mod = sb.st_mtime; #endif - return; +} + +void _gnutls_load_system_priorities(void) +{ + const char *p; + + p = secure_getenv("GNUTLS_SYSTEM_PRIORITY_FILE"); + if (p != NULL) + system_priority_file = p; + + _gnutls_update_system_priorities(); } void _gnutls_unload_system_priorities(void) @@ -955,6 +984,7 @@ void _gnutls_unload_system_priorities(void) #endif system_priority_buf = NULL; system_priority_buf_size = 0; + system_priority_last_mod = 0; } /* Returns the new priorities if SYSTEM is specified in @@ -990,10 +1020,15 @@ size_t n, n2 = 0, line_size; } #ifdef HAVE_FMEMOPEN + /* Always try to refresh the cached data, to + * allow it to be updated without restarting + * all applications + */ + _gnutls_update_system_priorities(); fp = fmemopen(system_priority_buf, system_priority_buf_size, "r"); +#else + fp = fopen(system_priority_file, "r"); #endif - if (fp == NULL) - fp = fopen(system_priority_file, "r"); if (fp == NULL) {/* fail */ ret = NULL; goto finish; -- 2.5.5 From berrange at redhat.com Fri Jun 3 17:57:02 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 3 Jun 2016 16:57:02 +0100 Subject: [gnutls-devel] [PATCH] gnutls_priority_init: multiple @KEYWORD lookups with fallback Message-ID: <1464969422-15012-1-git-send-email-berrange@redhat.com> The support for using "@KEYWORD" as a priority string is very useful to separate selection of priorities from application specific code or config files. It is, however, not general enough to fully serve all reasonable use cases. For example, consider an application sets gnutls_priority_set_direct(session, "@SYSTEM", NULL); The system administrator can modify the global priorities file to change what "@SYSTEM" resolves to for all apps using GNUTLS. As soon as one application wishes to have a slightly different configuration from others on the host, you have to go back and start modifying application specific configuration files once more. This is bad for the system administrator as it means there's no longer one single place where they can see the priority configuration for all apps. They may try to get around this problem by configuring the app to use a different keyword, instead of a full priority string, eg "@LIBVIRT". So the global priorities file can now define entries for both "SYSTEM" and "LIBVIRT". This has still placed a burden on the administrator change the config in two places - both libvirt config files and the global priorities file. What is more desirable is if applications were able to provide a list of keywords that would be tried in order, picking the first that existed. For example, libvirt could be written to request the following by default gnutls_priority_set_direct(session, "@LIBVIRT,SYSTEM", NULL); With this, gnutls would first try to find the "LIBVIRT" keyword in the global configuration file, and if that is not present, then it would fallback to trying to find the "SYSTEM" keyword. This provides nice "out of the box" behaviour for system administrators, whereby the app would be using "SYSTEM" initially and if the admin wishes to give the app a custom configuration, they can simply modify the global priorities file to add in the application specific keyword "LIBVIRT". There is never a need for the sysadmin to modify any application specific configuration files any more. It is exclusively controlled in one place via the global priorities file. Signed-off-by: Daniel P. Berrange --- lib/priority.c | 98 +++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 66 insertions(+), 32 deletions(-) diff --git a/lib/priority.c b/lib/priority.c index 5fcc97f..faa9e9b 100644 --- a/lib/priority.c +++ b/lib/priority.c @@ -999,8 +999,8 @@ char *_gnutls_resolve_priorities(const char* priorities) char *p = (char*)priorities; char *additional = NULL; char *ret = NULL; -char *ss, *line = NULL; -unsigned ss_len; +char *ss, *ss_next, *line = NULL; +unsigned ss_len, ss_next_len; int l; FILE* fp = NULL; size_t n, n2 = 0, line_size; @@ -1010,40 +1010,64 @@ size_t n, n2 = 0, line_size; if (*p == '@') { ss = p+1; - - additional = strchr(p, ':'); + additional = strchr(ss, ':'); if (additional != NULL) { - ss_len = additional - ss; additional++; - } else { - ss_len = strlen(ss); } + do { + ss_next = strchr(ss, ','); + if (ss_next != NULL) { + if (additional && ss_next > additional) + ss_next = NULL; + else + ss_next++; + } + + if (ss_next) { + ss_len = ss_next - ss - 1; + ss_next_len = additional - ss_next - 1; + } else if (additional) { + ss_len = additional - ss - 1; + ss_next_len = 0; + } else { + ss_len = strlen(ss); + ss_next_len = 0; + } + #ifdef HAVE_FMEMOPEN - /* Always try to refresh the cached data, to - * allow it to be updated without restarting - * all applications - */ - _gnutls_update_system_priorities(); - fp = fmemopen(system_priority_buf, system_priority_buf_size, "r"); + /* Always try to refresh the cached data, to + * allow it to be updated without restarting + * all applications + */ + _gnutls_update_system_priorities(); + fp = fmemopen(system_priority_buf, system_priority_buf_size, "r"); #else - fp = fopen(system_priority_file, "r"); + fp = fopen(system_priority_file, "r"); #endif - if (fp == NULL) {/* fail */ - ret = NULL; - goto finish; - } - - do { - l = getline(&line, &line_size, fp); - if (l > 0) { - p = check_str(line, line_size, ss, ss_len); - if (p != NULL) - break; + if (fp == NULL) {/* fail */ + ret = NULL; + goto finish; } - } while (l>0); + + do { + l = getline(&line, &line_size, fp); + if (l > 0) { + p = check_str(line, line_size, ss, ss_len); + if (p != NULL) + break; + } + } while (l>0); + + _gnutls_debug_log("resolved '%.*s' to '%s', next '%.*s'\n", + ss_len, ss, p ? : "", ss_next_len, ss_next ? : ""); + ss = ss_next; + fclose(fp); + fp = NULL; + } while (ss && p == NULL); if (p == NULL) { + _gnutls_debug_log("unable to resolve %s\n", priorities); ret = NULL; goto finish; } @@ -1129,12 +1153,22 @@ finish: * "NONE" means nothing is enabled. This disables even protocols and * compression methods. * - * "@KEYWORD" The system administrator imposed settings. The provided keywords - * will be expanded from a configuration-time provided file - default is: - * /etc/gnutls/default-priorities. Any keywords that follow it, will - * be appended to the expanded string. If there is no system string, - * then the function will fail. The system file should be formatted - * as "KEYWORD=VALUE", e.g., "SYSTEM=NORMAL:+ARCFOUR-128". + * "@KEYWORD1,KEYWORD2,..." The system administrator imposed settings. + * The provided keyword(s) will be expanded from a configuration-time + * provided file - default is: /etc/gnutls/default-priorities. + * Any attributes that follow it, will be appended to the expanded + * string. If multiple keywords are provided, separated by commas, + * then the first keyword that exists in the configuration file + * will be used. At least one of the keywords must exist, or this + * function will return an error. Typical usage would be to specify + * an application specified keyword first, followed by "SYSTEM" as + * a default fallback. e.g., "@LIBVIRT, at SYSTEM:!-VERS-SSL3.0" will + * first try to find a config file entry matching "LIBVIRT", but if + * that does not exist will use the entry for "SYSTEM". If "SYSTEM" + * does not exist either, an error will be returned. In all cases, + * the SSL3.0 protocol will be disabled. The system priority file + * entries should be formatted as "KEYWORD=VALUE", e.g., + * "SYSTEM=NORMAL:+ARCFOUR-128". * * Special keywords are "!", "-" and "+". * "!" or "-" appended with an algorithm will remove this algorithm. -- 2.5.5 From guillaume.roguez at savoirfairelinux.com Fri Jun 3 21:43:19 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Fri, 3 Jun 2016 15:43:19 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake Message-ID: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> Hi, Using gnutls 3.4.12, I'm trying to implement an encrypted and authenticated UDP channel using DTLS. To not send the certificate in clear during the handshake, I'm doing a double hanshake, starting with an anonymous credential session, then forcing a re-handshake using a certified credential session. My in-production code was worked well... until some users complain about the certified handshake not working. After investigation I've found that the packet containing (completely or partially) the client certificate is shift in time at server side. This packet is encryted as it's inside anonymous session, quite big (all allowed bytes used = MTU size) and re-ordered by the network. It seems that gnutls handshake doesn't like this situation: the server drops all following packets. To not enter into a complex code (our product is https://ring.cx), I've written a simple client/server working on GNU/Linux based from samples found in gnutls documentation, added a bit of code to do the double handshake and simulate the packet re-ordering by swapping the first big packet with the next one (only in server code). Questions: What am I doing wrong? In this case, what's the good way to implement my anonymous certificate exchange? The code (there is a bit of C++11 code, just easier for me to write few things): client: http://gpl.savoirfairelinux.net/ring-download/tests/gnutls_reordering_client.cpp build with command (GCC5.x): g++ -std=c++11 -g -Wall gnutls_reordering_client.cpp -o gnutls_reordering_client -pthread -lgnutls -lnettle server: http://gpl.savoirfairelinux.net/ring-download/tests/gnutls_reordering_server.cpp build with command (GCC5.x): g++ -std=c++11 -g -Wall gnutls_reordering_server.cpp -o gnutls_reordering_server -pthread -lgnutls -lnettle each binary must be run with 3 arguments: cafile certfile keyfile (to establish the certified session) Thanks for any help, Guillaume R. From home_pw at msn.com Fri Jun 3 22:46:39 2016 From: home_pw at msn.com (Peter Williams) Date: Fri, 3 Jun 2016 13:46:39 -0700 Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> Message-ID: Is a masked connection less handshake really supported ? (Recall lots of American ietfers are nsa agents. Lots of uk academics in ietfers crypto and phone telco are beholden to police forensics funding too.) Think about its original design intent (enable export control regime). Sent from my iPhone > On Jun 3, 2016, at 13:19, Guillaume Roguez wrote: > > Hi, > > Using gnutls 3.4.12, I'm trying to implement an encrypted and authenticated UDP channel using DTLS. > To not send the certificate in clear during the handshake, I'm doing a double hanshake, starting > with an anonymous credential session, then forcing a re-handshake using a certified credential session. > > My in-production code was worked well... until some users complain about the certified handshake not working. > > After investigation I've found that the packet containing (completely or partially) the client certificate is > shift in time at server side. > This packet is encryted as it's inside anonymous session, quite big (all allowed bytes used = MTU size) > and re-ordered by the network. > > It seems that gnutls handshake doesn't like this situation: the server drops all following packets. > > To not enter into a complex code (our product is https://ring.cx), I've written a simple client/server working on GNU/Linux > based from samples found in gnutls documentation, added a bit of code to do the double handshake > and simulate the packet re-ordering by swapping the first big packet with the next one (only in server code). > > > Questions: What am I doing wrong? In this case, what's the good way to implement my anonymous certificate exchange? > > The code (there is a bit of C++11 code, just easier for me to write few things): > > client: http://gpl.savoirfairelinux.net/ring-download/tests/gnutls_reordering_client.cpp > build with command (GCC5.x): g++ -std=c++11 -g -Wall gnutls_reordering_client.cpp -o gnutls_reordering_client -pthread -lgnutls -lnettle > > server: http://gpl.savoirfairelinux.net/ring-download/tests/gnutls_reordering_server.cpp > build with command (GCC5.x): g++ -std=c++11 -g -Wall gnutls_reordering_server.cpp -o gnutls_reordering_server -pthread -lgnutls -lnettle > > each binary must be run with 3 arguments: cafile certfile keyfile > (to establish the certified session) > > Thanks for any help, > Guillaume R. > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Sat Jun 4 18:48:13 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 04 Jun 2016 18:48:13 +0200 Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1465058893.1953.5.camel@gnutls.org> On Fri, 2016-06-03 at 15:43 -0400, Guillaume Roguez wrote: > Hi, > > Using gnutls 3.4.12, I'm trying to implement an encrypted and > authenticated UDP channel using DTLS. > To not send the certificate in clear during the handshake, I'm doing > a double hanshake, starting > with an anonymous credential session, then forcing a re-handshake > using a certified credential session. > > My in-production code was worked well... until some users complain > about the certified handshake not working. > After investigation I've found that the packet containing (completely > or partially) the client certificate is > shift in time at server side. > This packet is encryted as it's inside anonymous session, quite big > (all allowed bytes used = MTU size) > and re-ordered by the network. Hi, ?Could you modify tests/mini-dtls-rehandshake.c to do the same re- ordering so that I can reproduce and also include it in the test suite? > To not enter into a complex code (our product is https://ring.cx), > I've written a simple client/server working on GNU/Linux > based from samples found in gnutls documentation, added a bit of code > to do the double handshake > and simulate the packet re-ordering by swapping the first big packet > with the next one (only in server code). > Questions: What am I doing wrong? In this case, what's the good way > to implement my anonymous certificate exchange? I'll have to check the debugging output on what's wrong. There are several tests for re-orders and lost packets (tests/dtls/dtls) but it may be that a corner case is not covered (the issue may also depend on packet size). The best would be to have an easy to use reproducer in order for me to check it. regards, Nikos From guillaume.roguez at savoirfairelinux.com Mon Jun 6 06:20:52 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Mon, 6 Jun 2016 00:20:52 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1465058893.1953.5.camel@gnutls.org> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> Message-ID: <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> > On Fri, 2016-06-03 at 15:43 -0400, Guillaume Roguez wrote: >> Hi, >> >> Using gnutls 3.4.12, I'm trying to implement an encrypted and >> authenticated UDP channel using DTLS. >> To not send the certificate in clear during the handshake, I'm doing >> a double hanshake, starting >> with an anonymous credential session, then forcing a re-handshake >> using a certified credential session. >> >> My in-production code was worked well... until some users complain >> about the certified handshake not working. >> After investigation I've found that the packet containing (completely >> or partially) the client certificate is >> shift in time at server side. >> This packet is encryted as it's inside anonymous session, quite big >> (all allowed bytes used = MTU size) >> and re-ordered by the network. > > Hi, >?Could you modify tests/mini-dtls-rehandshake.c to do the same re- > ordering so that I can reproduce and also include it in the test suite? > For sure, I'm joining a patch to modify this test (also utils to permit extra arguments). It must be applied inside tests/ directory. Notice you need to give CA, certificate and key as arguments for x509 authentification. The patch gives a working version, uncomment the line: //#define DO_PACKET_REORDERING 1 to obtain a version with a simulation of packet re-ordering. The second handshake will never success. >> To not enter into a complex code (our product is https://ring.cx), >> I've written a simple client/server working on GNU/Linux >> based from samples found in gnutls documentation, added a bit of code >> to do the double handshake >> and simulate the packet re-ordering by swapping the first big packet >> with the next one (only in server code). >> Questions: What am I doing wrong? In this case, what's the good way >> to implement my anonymous certificate exchange? > > I'll have to check the debugging output on what's wrong. There are > several tests for re-orders and lost packets (tests/dtls/dtls) but it > may be that a corner case is not covered (the issue may also depend on > packet size). The best would be to have an easy to use reproducer in > order for me to check it. > > regards, > Nikos Thanks, Guillaume -------------- next part -------------- A non-text attachment was scrubbed... Name: reordering_patch Type: text/x-patch Size: 5450 bytes Desc: not available URL: From guillaume.roguez at savoirfairelinux.com Mon Jun 6 15:50:50 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Mon, 6 Jun 2016 09:50:50 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1859022783.100355.1465221050657.JavaMail.zimbra@savoirfairelinux.com> >> On Fri, 2016-06-03 at 15:43 -0400, Guillaume Roguez wrote: >>> Hi, >>> >>> Using gnutls 3.4.12, I'm trying to implement an encrypted and >>> authenticated UDP channel using DTLS. >>> To not send the certificate in clear during the handshake, I'm doing >>> a double hanshake, starting >>> with an anonymous credential session, then forcing a re-handshake >>> using a certified credential session. >>> >>> My in-production code was worked well... until some users complain >>> about the certified handshake not working. >>> After investigation I've found that the packet containing (completely >>> or partially) the client certificate is >>> shift in time at server side. >>> This packet is encryted as it's inside anonymous session, quite big >>> (all allowed bytes used = MTU size) >>> and re-ordered by the network. >> >> Hi, >>?Could you modify tests/mini-dtls-rehandshake.c to do the same re- >> ordering so that I can reproduce and also include it in the test suite? >> > > For sure, I'm joining a patch to modify this test (also utils to permit > extra arguments). It must be applied inside tests/ directory. > Notice you need to give CA, certificate and key as arguments for x509 > authentification. > > The patch gives a working version, uncomment the line: > > //#define DO_PACKET_REORDERING 1 > > to obtain a version with a simulation of packet re-ordering. > The second handshake will never success. > >>> To not enter into a complex code (our product is https://ring.cx), >>> I've written a simple client/server working on GNU/Linux >>> based from samples found in gnutls documentation, added a bit of code >>> to do the double handshake >>> and simulate the packet re-ordering by swapping the first big packet >>> with the next one (only in server code). >>> Questions: What am I doing wrong? In this case, what's the good way >>> to implement my anonymous certificate exchange? >> >> I'll have to check the debugging output on what's wrong. There are >> several tests for re-orders and lost packets (tests/dtls/dtls) but it >> may be that a corner case is not covered (the issue may also depend on >> packet size). The best would be to have an easy to use reproducer in >> order for me to check it. >> >> regards, >> Nikos > > Thanks, > Guillaume My attachment has been drop by the ML engine. I'm putting it inline right here: --- mini-dtls-rehandshake.c +++ mini-dtls-rehandshake.c @@ -71,2 +71,12 @@ +#define FIRST_PRIORITY "SECURE192:-KX-ALL:-VERS-TLS-ALL:+VERS-DTLS-ALL:+ANON-DH:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION" +#define CERT_PRIORITY "SECURE192:-VERS-TLS-ALL:+VERS-DTLS-ALL:-RSA:%SERVER_PRECEDENCE:%SAFE_RENEGOTIATION" +#define MTU 1500 +//#define DO_PACKET_REORDERING 1 + +static int server_fd = -1; +static char pkt_buf[MAX_BUF]; +static int pkt_found = 0; +static int pkt_delivered = 0; + static ssize_t @@ -76,2 +86,22 @@ +#ifdef DO_PACKET_REORDERING + // simulation of packet re-ordering + // invert the packet that reach MTU with the next one + if (fd == server_fd) { + if (!pkt_found && len == MTU) { + memcpy(pkt_buf, data, len); + pkt_found = 1; + printf("*** packet delayed\n"); + return len; + } + if (pkt_found && !pkt_delivered) { + int res = send(fd, data, len, 0); + send(fd, pkt_buf, MTU, 0); + pkt_delivered = 1; + printf("*** swap done\n"); + return res; + } + } +#endif + return send(fd, data, len, 0); @@ -79,2 +109,24 @@ +static int +check_certificate(gnutls_session_t session) +{ + if (gnutls_certificate_type_get(session) != GNUTLS_CRT_X509) { + return GNUTLS_E_CERTIFICATE_ERROR; + } + + unsigned int status = 0; + int ret = gnutls_certificate_verify_peers2(session, &status); + if (ret < 0 || (status & GNUTLS_CERT_SIGNATURE_FAILURE) != 0) { + return GNUTLS_E_CERTIFICATE_ERROR; + } + + unsigned int cert_list_size = 0; + const gnutls_datum_t *cert_list = gnutls_certificate_get_peers(session, &cert_list_size); + if (cert_list == NULL) { + return GNUTLS_E_CERTIFICATE_ERROR; + } + + return GNUTLS_E_SUCCESS; +} + static void client(int fd, int server_init) @@ -84,2 +136,3 @@ gnutls_anon_client_credentials_t anoncred; + gnutls_certificate_credentials_t x509_cred; gnutls_session_t session; @@ -97,2 +150,8 @@ + /* x509 crediandials */ + gnutls_certificate_allocate_credentials(&x509_cred); + gnutls_certificate_set_x509_trust_file(x509_cred, extra_argv[0], GNUTLS_X509_FMT_PEM); + gnutls_certificate_set_x509_key_file(x509_cred, extra_argv[1], extra_argv[2], GNUTLS_X509_FMT_PEM); + gnutls_certificate_set_verify_function(x509_cred, check_certificate); + /* Initialize TLS session @@ -100,3 +159,3 @@ gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_DATAGRAM); - gnutls_dtls_set_mtu(session, 1500); + gnutls_dtls_set_mtu(session, MTU); @@ -104,3 +163,3 @@ gnutls_priority_set_direct(session, - "NONE:+VERS-DTLS1.0:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+ANON-ECDH:+CURVE-ALL", + FIRST_PRIORITY, NULL); @@ -135,2 +194,6 @@ + gnutls_priority_set_direct(session, CERT_PRIORITY, NULL); + gnutls_credentials_clear(session); + gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, x509_cred); + if (!server_init) { @@ -208,2 +271,13 @@ +static gnutls_dh_params_t dh_params; + +static void +generate_dh_params(void) +{ + int bits = gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_HIGH); + gnutls_dh_params_init(&dh_params); + success("Generating DH...\n"); + gnutls_dh_params_generate2(dh_params, bits); +} + static void server(int fd, int server_init) @@ -213,2 +287,3 @@ gnutls_anon_server_credentials_t anoncred; + gnutls_certificate_credentials_t x509_cred; gnutls_session_t session; @@ -217,2 +292,3 @@ global_init(); + generate_dh_params(); @@ -224,2 +300,10 @@ gnutls_anon_allocate_server_credentials(&anoncred); + gnutls_anon_set_server_dh_params(anoncred, dh_params); + + /* x509 crediandials */ + gnutls_certificate_allocate_credentials(&x509_cred); + gnutls_certificate_set_x509_trust_file(x509_cred, extra_argv[0], GNUTLS_X509_FMT_PEM); + gnutls_certificate_set_x509_key_file(x509_cred, extra_argv[1], extra_argv[2], GNUTLS_X509_FMT_PEM); + gnutls_certificate_set_verify_function(x509_cred, check_certificate); + gnutls_certificate_set_dh_params(x509_cred, dh_params); @@ -232,3 +316,3 @@ gnutls_priority_set_direct(session, - "NONE:+VERS-DTLS1.0:+CIPHER-ALL:+MAC-ALL:+SIGN-ALL:+COMP-ALL:+ANON-ECDH:+CURVE-ALL", + FIRST_PRIORITY, NULL); @@ -236,2 +320,3 @@ gnutls_credentials_set(session, GNUTLS_CRD_ANON, anoncred); + gnutls_certificate_server_set_request(session, GNUTLS_CERT_REQUIRE); @@ -259,2 +344,6 @@ + gnutls_priority_set_direct(session, CERT_PRIORITY, NULL); + gnutls_credentials_clear(session); + gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, x509_cred); + /* see the Getting peer's information example */ @@ -348,2 +437,5 @@ + pkt_found = 0; + pkt_delivered = 0; + ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd); @@ -365,2 +457,3 @@ + server_fd = fd[0]; server(fd[0], server_initiated); --- utils.c +++ utils.c @@ -222,4 +222,10 @@ +int extra_argc = 0; +char ** extra_argv = NULL; + int main(int argc, char *argv[]) { + int extra_first = -1; + int copy_argc = argc; + do @@ -238,4 +244,11 @@ return 1; + } else { + extra_first = argc - 1; + } + while (argc-- > 2); + + if (extra_first != -1) { + extra_argc = copy_argc - extra_first; + extra_argv = argv + extra_first; } - while (argc-- > 1) ; --- utils.h +++ utils.h @@ -81,2 +81,5 @@ +extern int extra_argc; +extern char ** extra_argv; + #endif /* UTILS_H */ From nmav at gnutls.org Mon Jun 6 19:41:51 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 06 Jun 2016 19:41:51 +0200 Subject: [gnutls-devel] gnutls 3.4.13 Message-ID: <1465234911.24533.4.camel@gnutls.org> Hello,? ?I've just released gnutls 3.4.13. This is a bug fix release of the current stable branch, which addresses a vulnerability for setuid programs introduced in gnutls 3.4.12 -see http://www.gnutls.org/security.html#GNUTLS-SA-2016-1? * Version 3.4.13 (released 2016-06-06) ** libgnutls: Consider the SSLKEYLOGFILE environment to be compatible with ???NSS instead of using a separate variable; in addition append any keys to ???the file instead of overwriting it. ** libgnutls: use secure_getenv() where available to obtain environment ???variables. Addresses GNUTLS-SA-2016-1. ** 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 compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.13.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.13.tar.xz.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 Jun 9 16:59:47 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 09 Jun 2016 16:59:47 +0200 Subject: [gnutls-devel] [PATCH] _gnutls_resolve_priorities: always try to re-read sys priority file In-Reply-To: <1464962351-15505-1-git-send-email-berrange@redhat.com> References: <1464962351-15505-1-git-send-email-berrange@redhat.com> Message-ID: <1465484387.3609.2.camel@gnutls.org> On Fri, 2016-06-03 at 14:59 +0100, Daniel P. Berrange wrote: > Previously if the system priority file was edited, that would > take effect on the very next TLS session an application created. > > As of: > > ? commit 006b89d4464ae1bb6d545ea5716998654124df45 > ? Author: Nikos Mavrogiannopoulos > ? Date:???Fri Apr 1 10:46:12 2016 +0200 > > ????priorities: preload the system priorities on library loading time > > It is required to restart every application after changing the > system priority file to get changes to take effect. > > Further, for applications running in a chroot, it will no longer > honour a system priority file that may exist inside the chroot, > always using the originally cached data from outside the chroot. Applied, thank you! From n.mavrogiannopoulos at gmail.com Thu Jun 9 17:29:27 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 09 Jun 2016 17:29:27 +0200 Subject: [gnutls-devel] [PATCH] gnutls_priority_init: multiple @KEYWORD lookups with fallback In-Reply-To: <1464969422-15012-1-git-send-email-berrange@redhat.com> References: <1464969422-15012-1-git-send-email-berrange@redhat.com> Message-ID: <1465486167.3609.9.camel@gmail.com> On Fri, 2016-06-03 at 16:57 +0100, Daniel P. Berrange wrote: > The support for using "@KEYWORD" as a priority string is very > useful to separate selection of priorities from application > specific code or config files. It is, however, not general > enough to fully serve all reasonable use cases. > > For example, consider an application sets > > ? gnutls_priority_set_direct(session, "@SYSTEM", NULL); > > The system administrator can modify the global priorities > file to change what "@SYSTEM" resolves to for all apps using > GNUTLS. As soon as one application wishes to have a slightly > different configuration from others on the host, you have to > go back and start modifying application specific configuration > files once more. This is bad for the system administrator as > it means there's no longer one single place where they can > see the priority configuration for all apps. > > They may try to get around this problem by configuring the > app to use a different keyword, instead of a full priority > string, eg "@LIBVIRT". So the global priorities file can > now define entries for both "SYSTEM" and "LIBVIRT". This > has still placed a burden on the administrator change the > config in two places - both libvirt config files and the > global priorities file. > > What is more desirable is if applications were able to provide > a list of keywords that would be tried in order, picking the > first that existed. For example, libvirt could be written to > request the following by default > > ? gnutls_priority_set_direct(session, "@LIBVIRT,SYSTEM", NULL); > > With this, gnutls would first try to find the "LIBVIRT" keyword > in the global configuration file, and if that is not present, > then it would fallback to trying to find the "SYSTEM" keyword. > > This provides nice "out of the box" behaviour for system > administrators, whereby the app would be using "SYSTEM" initially > and if the admin wishes to give the app a custom configuration, > they can simply modify the global priorities file to add in the > application specific keyword "LIBVIRT". There is never a need > for the sysadmin to modify any application specific configuration > files any more. It is exclusively controlled in one place via the > global priorities file. The keyword fallback could also be useful in applications which are intended to run on different systems with different system-wide keywords. I think it makes sense to add it. This patch currently breaks tests/system-prio-file.c. Irrespective of that it would be very good to have some test cases there for the fallback option too. > + * a default fallback. e.g., "@LIBVIRT, at SYSTEM:!-VERS-SSL3.0" will There seems to be a typo here. Shouldn't that be @LIBVIRT,SYSTEM? regards, Nikos From nmav at gnutls.org Thu Jun 9 17:47:07 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 09 Jun 2016 17:47:07 +0200 Subject: [gnutls-devel] [PATCH] gnutls_priority_init: multiple @KEYWORD lookups with fallback In-Reply-To: <1465486167.3609.9.camel@gmail.com> References: <1464969422-15012-1-git-send-email-berrange@redhat.com> <1465486167.3609.9.camel@gmail.com> Message-ID: <1465487227.3609.16.camel@gnutls.org> On Thu, 2016-06-09 at 17:29 +0200, Nikos Mavrogiannopoulos wrote: > This patch currently breaks tests/system-prio-file.c. Irrespective of > that it would be very good to have some test cases there for the > fallback option too. I replied too fast here. There is no issue with the system-prio-file test, I was simply running it wrongly. I've included some basic testing of the new feature, and applied the change in master. Please suggest additional testing for any corner cases I may have missed. Thank you.? Nikos From nmav at gnutls.org Thu Jun 9 17:52:44 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 09 Jun 2016 17:52:44 +0200 Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1465487564.3609.21.camel@gnutls.org> On Mon, 2016-06-06 at 00:20 -0400, Guillaume Roguez wrote: > > > > On Fri, 2016-06-03 at 15:43 -0400, Guillaume Roguez wrote: > > > > > > Hi, > > > > > > Using gnutls 3.4.12, I'm trying to implement an encrypted and > > > authenticated UDP channel using DTLS. > > > To not send the certificate in clear during the handshake, I'm > > > doing > > > a double hanshake, starting > > > with an anonymous credential session, then forcing a re-handshake > > > using a certified credential session. > > > > > > My in-production code was worked well... until some users > > > complain > > > about the certified handshake not working. > > > After investigation I've found that the packet containing > > > (completely > > > or partially) the client certificate is > > > shift in time at server side. > > > This packet is encryted as it's inside anonymous session, quite > > > big > > > (all allowed bytes used = MTU size) > > > and re-ordered by the network. > > Hi, > > ?Could you modify tests/mini-dtls-rehandshake.c to do the same re- > > ordering so that I can reproduce and also include it in the test > > suite? > > > For sure, I'm joining a patch to modify this test (also utils to > permit > extra arguments). It must be applied inside tests/ directory. > Notice you need to give CA, certificate and key as arguments for x509 > authentification. I usually try to hard-code the certs from "cert-common.h" to allow for easier testing. Anyway I'll check the issue the next few days. regards, Nikos From berrange at redhat.com Thu Jun 9 18:48:21 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 9 Jun 2016 17:48:21 +0100 Subject: [gnutls-devel] [PATCH] gnutls_priority_init: multiple @KEYWORD lookups with fallback In-Reply-To: <1465487227.3609.16.camel@gnutls.org> References: <1464969422-15012-1-git-send-email-berrange@redhat.com> <1465486167.3609.9.camel@gmail.com> <1465487227.3609.16.camel@gnutls.org> Message-ID: <20160609164821.GH7218@redhat.com> On Thu, Jun 09, 2016 at 05:47:07PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 2016-06-09 at 17:29 +0200, Nikos Mavrogiannopoulos wrote: > > > This patch currently breaks tests/system-prio-file.c. Irrespective of > > that it would be very good to have some test cases there for the > > fallback option too. > > I replied too fast here. There is no issue with the system-prio-file > test, I was simply running it wrongly. > > I've included some basic testing of the new feature, and applied the > change in master. Please suggest additional testing for any corner > cases I may have missed. Thank you.? Thanks, I'll take a look at the tests you added. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| From nmav at gnutls.org Fri Jun 10 14:09:55 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Jun 2016 14:09:55 +0200 Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1465560595.4678.6.camel@gnutls.org> On Mon, 2016-06-06 at 00:20 -0400, Guillaume Roguez wrote: > For sure, I'm joining a patch to modify this test (also utils to > permit > extra arguments). It must be applied inside tests/ directory. > Notice you need to give CA, certificate and key as arguments for x509 > authentification. > > The patch gives a working version, uncomment the line: I could not reproduce it. Could you please use the attached file as starting point for your test? It is based on a newly introduced test for DTLS and uses the embedded certificates and keys. If to reproduce you need different certificates please include them in the test. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: dtls-rehandshake-cert-2.c Type: text/x-csrc Size: 9689 bytes Desc: not available URL: From berrange at redhat.com Fri Jun 10 14:41:22 2016 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 10 Jun 2016 13:41:22 +0100 Subject: [gnutls-devel] [PATCH] tests: test trailing comma in system priorities Message-ID: <1465562482-3650-1-git-send-email-berrange@redhat.com> Add tests which verify behaviour when the list of system priorities has a trailing ','. Avoid crash in test suite if the test unexpectedly succeeds when expected_str is NULL. Signed-off-by: Daniel P. Berrange --- tests/system-prio-file.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tests/system-prio-file.c b/tests/system-prio-file.c index 59c960d..e0dfa94 100644 --- a/tests/system-prio-file.c +++ b/tests/system-prio-file.c @@ -51,7 +51,7 @@ try_prio(const char *prio, const char *expected_str) if (p == NULL && expected_str == NULL) goto ok; - if (p == NULL || strcmp(p, expected_str) != 0) { + if (p == NULL || expected_str == NULL || strcmp(p, expected_str) != 0) { fail("test: %s: error; got: %s, expected: %s\n", prio, p, expected_str); exit(1); } @@ -72,6 +72,7 @@ void doit(void) try_prio("@HELLO1,HELLO2", "NORMAL"); try_prio("@HELLO1,HELLO2:+AES-128-CBC", "NORMAL:+AES-128-CBC"); try_prio("@HELLO1,HELLO1", "NORMAL"); + try_prio("@HELLO1,", "NORMAL"); try_prio("@HELLO2,HELLO1", "NORMAL:+AES-128-CBC"); try_prio("@HELLO2,HELLO1, at HELLONO", "NORMAL:+AES-128-CBC"); try_prio("@HELLO2,HELLO1, at HELLO3", "NORMAL:+AES-128-CBC"); @@ -79,5 +80,8 @@ void doit(void) try_prio("@HELLONO,HELLONO2,HELLO1", "NORMAL"); try_prio("@HELLONO,HELLONO2,HELLO1:+AES-128-CBC", "NORMAL:+AES-128-CBC"); try_prio("@HELLONO", NULL); + try_prio("@HELLONO,", NULL); + try_prio("@HELLONO:+AES-128-CBC", NULL); + try_prio("@HELLONO,:+AES-128-CBC", NULL); } -- 2.5.5 From n.mavrogiannopoulos at gmail.com Fri Jun 10 21:29:38 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 10 Jun 2016 21:29:38 +0200 Subject: [gnutls-devel] [PATCH] tests: test trailing comma in system priorities In-Reply-To: <1465562482-3650-1-git-send-email-berrange@redhat.com> References: <1465562482-3650-1-git-send-email-berrange@redhat.com> Message-ID: <1465586978.3248.0.camel@gmail.com> On Fri, 2016-06-10 at 13:41 +0100, Daniel P. Berrange wrote: > Add tests which verify behaviour when the list of system > priorities has a trailing ','. Avoid crash in test suite > if the test unexpectedly succeeds when expected_str is > NULL. Applied, thank you. From guillaume.roguez at savoirfairelinux.com Tue Jun 14 16:05:52 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Tue, 14 Jun 2016 10:05:52 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1465912710.338.2.camel@gmail.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> <1465560595.4678.6.camel@gnutls.org> <1465912710.338.2.camel@gmail.com> Message-ID: <1070164606.110094.1465913152808.JavaMail.zimbra@savoirfairelinux.com> ----- Le 14 Juin 16, ? 9:58, Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com a ?crit : > On Fri, 2016-06-10 at 14:09 +0200, Nikos Mavrogiannopoulos wrote: >> On Mon, 2016-06-06 at 00:20 -0400, Guillaume Roguez wrote: >> >> > >> > For sure, I'm joining a patch to modify this test (also utils to >> > permit >> > extra arguments). It must be applied inside tests/ directory. >> > Notice you need to give CA, certificate and key as arguments for >> > x509 >> > authentification. >> > >> > The patch gives a working version, uncomment the line: >> I could not reproduce it. Could you please use the attached file as >> starting point for your test? It is based on a newly introduced test >> for DTLS and uses the embedded certificates and keys. If to reproduce >> you need different certificates please include them in the test. > > Ping? I'm suspecting it may be related to the certificate size. If you > cannot include the certificates you are using please generate a test > pair with size close to the problematic one. > > regards, > Nikos I'm going to test and report to you my results. Thanks Guillaume From nmav at gnutls.org Tue Jun 14 16:44:56 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Jun 2016 16:44:56 +0200 Subject: [gnutls-devel] gnutls 3.5.1 Message-ID: <1465915496.338.6.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.1. This is a minor feature update for the 3.5.x branch. * Version 3.5.1 (released 2016-06-14) ** libgnutls: The SSL 3.0 protocol support can completely be removed ???using a compile time option. The configure option is? ? ?--disable-ssl3-support. ** libgnutls: The SSL 2.0 client hello support can completely be? ? ?removed using a compile time option. The configure option is? ? ?--disable-ssl2-support. For info on why this is not the ? ?default see?https://gitlab.com/gnutls/gnutls/issues/97 ** libgnutls: Added support for OCSP Must staple PKIX extension. That ? ?is, implemented the RFC7633 TLSFeature for OCSP status request? ? ?extension. Feature implemented by Tim Kosse. ** libgnutls: More strict OCSP staple verification. That is, no longer ???ignore invalid or too old OCSP staples. The previous behavior was ???to rely on application use gnutls_ocsp_status_request_is_checked(), ???while the new behavior is to include OCSP verification by default ???and set the GNUTLS_CERT_INVALID_OCSP_STATUS verification flag on ? ?error. ** libgnutls: Treat CA certificates with the "Server Gated? ? ?Cryptography" key ?purpose OIDs equivalent to having the ? ?GNUTLS_KP_TLS_WWW_SERVER OID. This improves interoperability with ? ?several old intermediate CA certificates carrying these legacy OIDs. ** libgnutls: Re-read the system wide priority file when needed. Patch ? ?by Daniel P. Berrange. ** libgnutls: Allow for fallback in system-specific initial keywords ???(prefixed with '@'). That allows to specify a keyword such as ???"@KEYWORD1,KEYWORD2" which will use the first available of these ???two keywords. Patch by Daniel P. Berrange. ** libgnutls: The SSLKEYLOGFILE environment variable can be used to log ???session keys. These session keys are compatible with the NSS Key Log ???Format and can be used to decrypt the session for debugging using ???wireshark. ** API and ABI modifications: GNUTLS_CERT_INVALID_OCSP_STATUS: Added gnutls_x509_crt_set_crq_extension_by_oid: Added gnutls_x509_ext_import_tlsfeatures: Added gnutls_x509_ext_export_tlsfeatures: Added gnutls_x509_tlsfeatures_add: Added gnutls_x509_tlsfeatures_init: Added gnutls_x509_tlsfeatures_deinit: Added gnutls_x509_tlsfeatures_get: Added gnutls_x509_crt_get_tlsfeatures: Added gnutls_x509_crt_set_tlsfeatures: Added gnutls_x509_crq_get_tlsfeatures: Added gnutls_x509_crq_set_tlsfeatures: Added gnutls_ext_get_name: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.1.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.1.tar.xz.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 guillaume.roguez at savoirfairelinux.com Tue Jun 14 17:14:01 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Tue, 14 Jun 2016 11:14:01 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <1070164606.110094.1465913152808.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> <1465560595.4678.6.camel@gnutls.org> <1465912710.338.2.camel@gmail.com> <1070164606.110094.1465913152808.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <288292223.159682.1465917241290.JavaMail.zimbra@savoirfairelinux.com> ----- Le 14 Juin 16, ? 10:05, Guillaume Roguez guillaume.roguez at savoirfairelinux.com a ?crit : > ----- Le 14 Juin 16, ? 9:58, Nikos Mavrogiannopoulos > n.mavrogiannopoulos at gmail.com a ?crit : > >> On Fri, 2016-06-10 at 14:09 +0200, Nikos Mavrogiannopoulos wrote: >>> On Mon, 2016-06-06 at 00:20 -0400, Guillaume Roguez wrote: >>> >>> > >>> > For sure, I'm joining a patch to modify this test (also utils to >>> > permit >>> > extra arguments). It must be applied inside tests/ directory. >>> > Notice you need to give CA, certificate and key as arguments for >>> > x509 >>> > authentification. >>> > >>> > The patch gives a working version, uncomment the line: >>> I could not reproduce it. Could you please use the attached file as >>> starting point for your test? It is based on a newly introduced test >>> for DTLS and uses the embedded certificates and keys. If to reproduce >>> you need different certificates please include them in the test. >> >> Ping? I'm suspecting it may be related to the certificate size. If you >> cannot include the certificates you are using please generate a test >> pair with size close to the problematic one. >> >> regards, >> Nikos > > I'm going to test and report to you my results. > Thanks > > Guillaume Ok, your example doesn't trig the packet re-odering code, that's why it pass ;-) Just change the line 87 like this: before: if (!pkt_found && len == MTU) { after: if (!pkt_found && len > 1200) { In my case the biggest client packet is 1485 bytes, that's trigging the re-ordering simulator. Using this change on your code causes the issue. Regards, Guillaume From tim.kosse at filezilla-project.org Tue Jun 14 17:24:54 2016 From: tim.kosse at filezilla-project.org (Tim Kosse) Date: Tue, 14 Jun 2016 17:24:54 +0200 Subject: [gnutls-devel] Support for OCSP Must-staple ? In-Reply-To: <8c5cf452-0dcb-87ee-ca12-c0c978478690@filezilla-project.org> References: <7143243.RrO4Tg8rEH@blitz-lx> <3030f504-b81f-2003-4079-f7e19a8286c2@filezilla-project.org> <8c5cf452-0dcb-87ee-ca12-c0c978478690@filezilla-project.org> Message-ID: Hi, I'm not sure whether you have seen my comments. It looks like the original merge request has been committed to master and released as 3.5.1 unchanged. Regards, Tim On 2016-06-01 18:40, Tim Kosse wrote: > Hi, > > I had a look at the merge request. While I couldn't find any major > issues, there are still a few small things that should probably be fixed: > > verify_crt in lib/x509/verify.c: > Function description still mentions the removed issuer parameter > > verify_crt in lib/x509/verify.c: > The TLS feature check re-uses the nc_done label from the name > constraints checks. While the functionality is correct right now, it's > an easy source for errors should this function be changed in the future. > I suggest moving the TLS feature checking below the nc_done label and > adding a separate feat_done label. > > gnutls_x509_tlsfeatures_crt in lib/x509/tls_features.c: > Line 240, format specifier doesn't match type of arguments. The size in > gnutls_x509_tlsfeatures_t is unsigned int. > > parse_tlsfeatures in lib/x509/x509_ext.c: > The size limitation check should be done after the duplicate check, > otherwise appending fails when verifying chains where certificates use > the maximum allowed number of features. > > tests/tlsfeature-ext.c: > Lines 145 and 146: The comment doesn't match the assert. > > Regards, > Tim > From n.mavrogiannopoulos at gmail.com Thu Jun 16 12:03:35 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 16 Jun 2016 12:03:35 +0200 Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: <288292223.159682.1465917241290.JavaMail.zimbra@savoirfairelinux.com> References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> <1465560595.4678.6.camel@gnutls.org> <1465912710.338.2.camel@gmail.com> <1070164606.110094.1465913152808.JavaMail.zimbra@savoirfairelinux.com> <288292223.159682.1465917241290.JavaMail.zimbra@savoirfairelinux.com> Message-ID: On Tue, Jun 14, 2016 at 5:14 PM, Guillaume Roguez wrote: > Ok, your example doesn't trig the packet re-odering code, that's why it pass ;-) Thank you. It seems there was an issue when a split handshake packet under DTLS was re-ordered. The split packets was not covered by the DTLS re-ordering test suite and that's why it wasn't caught. I've committed a fix at https://gitlab.com/gnutls/gnutls/commit/ddb5a53cbd6e570d745fa7f61f57ae2ebe63891b and included your reproducer to the test suite. regards, Nikos From guillaume.roguez at savoirfairelinux.com Thu Jun 16 15:52:42 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Thu, 16 Jun 2016 09:52:42 -0400 (EDT) Subject: [gnutls-devel] handshake packet re-ordering issue during encrypted handshake In-Reply-To: References: <520525464.309383.1464982999313.JavaMail.zimbra@savoirfairelinux.com> <1465058893.1953.5.camel@gnutls.org> <1499771578.40981.1465186852495.JavaMail.zimbra@savoirfairelinux.com> <1465560595.4678.6.camel@gnutls.org> <1465912710.338.2.camel@gmail.com> <1070164606.110094.1465913152808.JavaMail.zimbra@savoirfairelinux.com> <288292223.159682.1465917241290.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <441536790.49602.1466085162187.JavaMail.zimbra@savoirfairelinux.com> ---- Le 16 Juin 16, ? 6:03, Nikos Mavrogiannopoulos n.mavrogiannopoulos at gmail.com a ?crit : > On Tue, Jun 14, 2016 at 5:14 PM, Guillaume Roguez > wrote: >> Ok, your example doesn't trig the packet re-odering code, that's why it pass ;-) > > Thank you. It seems there was an issue when a split handshake packet > under DTLS was re-ordered. The split packets > was not covered by the DTLS re-ordering test suite and that's why it > wasn't caught. I've committed a fix at > https://gitlab.com/gnutls/gnutls/commit/ddb5a53cbd6e570d745fa7f61f57ae2ebe63891b > > and included your reproducer to the test suite. > > regards, > Nikos That's a good news! I'm going to test that into Ring as soon as possible. Thanks. Guillaume Roguez | Senior Free Software Consultant Ring Development Project Director, https://ring.cx RingID: 007871859FFA8E8FFDE776A6BA8E8FA35ABD9A7B PGP: 2A3A3627C9DCA7E733EE1034820371F4E07DE571 Savoir-faire Linux 7275 Saint Urbain Bureau 200 Montr?al, QC, H2R 2Y5 From guillaume.roguez at savoirfairelinux.com Fri Jun 17 17:54:00 2016 From: guillaume.roguez at savoirfairelinux.com (Guillaume Roguez) Date: Fri, 17 Jun 2016 11:54:00 -0400 (EDT) Subject: [gnutls-devel] gnutls archives not more accessible Message-ID: <168845943.132770.1466178840262.JavaMail.zimbra@savoirfairelinux.com> Hi, I notice the FTP directory ftp://ftp.gnutls.org/gcrypt/gnutls seems to have been removed, and not more accessible. All sync mirrors have also deleted the directory. -- Guillaume Roguez | Senior Free Software Consultant Ring Development Project Director - https://ring.cx RingID: 007871859FFA8E8FFDE776A6BA8E8FA35ABD9A7B PGP : 2A3A3627C9DCA7E733EE1034820371F4E07DE571 From nmav at gnutls.org Fri Jun 17 23:20:55 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 17 Jun 2016 23:20:55 +0200 Subject: [gnutls-devel] gnutls archives not more accessible In-Reply-To: <168845943.132770.1466178840262.JavaMail.zimbra@savoirfairelinux.com> References: <168845943.132770.1466178840262.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1466198455.5566.1.camel@gnutls.org> No idea about that. I add Werner who is administering the server. regards, Nikos On Fri, 2016-06-17 at 11:54 -0400, Guillaume Roguez wrote: > Hi, > > I notice the FTP directory ftp://ftp.gnutls.org/gcrypt/gnutls seems > to have been removed, > and not more accessible. > All sync mirrors have also deleted the directory. > From wk at gnupg.org Sat Jun 18 13:14:26 2016 From: wk at gnupg.org (Werner Koch) Date: Sat, 18 Jun 2016 13:14:26 +0200 Subject: [gnutls-devel] gnutls archives not more accessible In-Reply-To: <1466198455.5566.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 17 Jun 2016 23:20:55 +0200") References: <168845943.132770.1466178840262.JavaMail.zimbra@savoirfairelinux.com> <1466198455.5566.1.camel@gnutls.org> Message-ID: <8760t6da0d.fsf@wheatstone.g10code.de> On Fri, 17 Jun 2016 23:20, nmav at gnutls.org said: > No idea about that. I add Werner who is administering the server. Yeah, we run out of space and I had to move gnutls to another partition. Unfortunately I tested only the https access and forgot that the ftp server does a chroot and thus won't follow the new symlink. I replaced the symlink by a bind mount. I apologize for the trouble. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. /* EFH in Erkrath: https://alt-hochdahl.de/haus */ From nmav at gnutls.org Sat Jun 18 17:52:05 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 18 Jun 2016 17:52:05 +0200 Subject: [gnutls-devel] gnutls archives not more accessible In-Reply-To: <8760t6da0d.fsf@wheatstone.g10code.de> References: <168845943.132770.1466178840262.JavaMail.zimbra@savoirfairelinux.com> <1466198455.5566.1.camel@gnutls.org> <8760t6da0d.fsf@wheatstone.g10code.de> Message-ID: <1466265125.2491.2.camel@gnutls.org> On Sat, 2016-06-18 at 13:14 +0200, Werner Koch wrote: > On Fri, 17 Jun 2016 23:20, nmav at gnutls.org said: > > > > No idea about that. I add Werner who is administering the server. > Yeah, we run out of space and I had to move gnutls to another > partition.??Unfortunately I tested only the https access and forgot > that > the ftp server does a chroot and thus won't follow the new > symlink.??I > replaced the symlink by a bind mount. > > I apologize for the trouble. Thank you for the prompt fix. From ametzler at bebt.de Sat Jun 18 18:46:54 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 18 Jun 2016 18:46:54 +0200 Subject: [gnutls-devel] [patch] typos Message-ID: <20160618164654.GB24723@argenau.bebt.de> Hello, lintian found some typos, trivial patch attached. 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: 0001-Typo-fixes-found-by-lintian-extention-reencode.patch Type: text/x-diff Size: 3828 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Sun Jun 19 10:12:58 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sun, 19 Jun 2016 10:12:58 +0200 Subject: [gnutls-devel] [patch] typos In-Reply-To: <20160618164654.GB24723@argenau.bebt.de> References: <20160618164654.GB24723@argenau.bebt.de> Message-ID: <1466323978.32166.0.camel@gmail.com> On Sat, 2016-06-18 at 18:46 +0200, Andreas Metzler wrote: > Hello, > > lintian found some typos, trivial patch attached. Applied, thank you.