From hannes at mehnert.org Thu Jul 9 12:13:24 2015 From: hannes at mehnert.org (Hannes Mehnert) Date: Thu, 09 Jul 2015 11:13:24 +0100 Subject: [gnutls-devel] wrongly encoded padding extension in GnuTLS Message-ID: <559E4944.8040709@mehnert.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, while investigating an interoperability failure between GnuTLS and nqsb-TLS [1], I discovered that your encoding of the padding extension (ext/dumbfw.c) is slightly wrong. The IETF draft [2] specifies the extension type to be 0x00 0x15, followed by the extension length (another 16 bit), followed by extension length 0s, the example being: 00 15 00 06 00 00 00 00 00 00 But GnuTLS encodes another 16 bit length field inside the padding data: 00 15 00 06 00 04 00 00 00 00 While this is likely not a security issue yet, encoding arbitrary data in padding lead to several problems in the past (PKCS, ASN.1 encoding, POODLE, ...). You can reproduce this issue with https://nqsb.io . It'd be great to have GnuTLS fixed in this regard, by removing the superfluous length from padding data. Cheers, Hannes 1: https://github.com/mirleft/ocaml-tls/issues/293 2: https://tools.ietf.org/html/draft-ietf-tls-padding-01#section-3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCQAGBQJVnklEAAoJELyJZYjffCjuUgMP/2IicNvI7I3tCxBjU37juVhB Xss5q6V0gucnCVGuliVBeALp16m0gbICOx1LYmacEHtCSbGzk2seDV/1Wwwgt4u5 sbur2omsk5FR9R/I7AK64VJ71r+JosSw1z5adun8J0hzzUuOQpFoCV7eJkDs/DY/ uK0BdZ88rkBoeUXCP53OhXJ1rTn4JY19WlZFYoCGhFjxZVyhisdKEoF0H1YTh480 +al565Pm17IPNO9Cy+IOTXFshUfraNQ7NElgDRw4T/S1s479DUbObf22gCtkoT45 pjBQ8qh2pVQqRvR+tSqMUrapIBLKqjzN3uV2j3g+VEqfXgB6nZLJSvuMqN89G5s+ BO+a3MQn5FI0029CFfMz54vgdMwNh0hhviiEKjwbkwMcttumleIi1KncMkiVhWJe GP6TmeGfmgMF6nqQCPkiruRrihEg8i8oqqE9ZR3ivANjRfBdtkGg9zMWOsfHLjzp Kptm92yHByUgkg/tGzAg5PtJ8v53SY0XZm2+AyTTOjQiREry3TBM7k5TAM7W9fOv NZgoZFPJxdz7NgqaXC3jbhWicQ4i8ixiwRcQj/6TeNmTkRP1yYh50MK5k6jiFb5g FMJ2RCqmkImOGWWz7AnsZoYX7A8rR48SVyqeZjGTff2976x1wdSg+pTXKNhcJxKa uY0VYijFLNKo6zAncJ/P =uhQf -----END PGP SIGNATURE----- From nmav at gnutls.org Thu Jul 9 13:47:39 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 9 Jul 2015 13:47:39 +0200 Subject: [gnutls-devel] wrongly encoded padding extension in GnuTLS In-Reply-To: <559E4944.8040709@mehnert.org> References: <559E4944.8040709@mehnert.org> Message-ID: On Thu, Jul 9, 2015 at 12:13 PM, Hannes Mehnert wrote: > Hi, > while investigating an interoperability failure between GnuTLS and > nqsb-TLS [1], I discovered that your encoding of the padding extension > (ext/dumbfw.c) is slightly wrong. > The IETF draft [2] specifies the extension type to be 0x00 0x15, > followed by the extension length (another 16 bit), followed by > extension length 0s, the example being: > 00 15 00 06 00 00 00 00 00 00 > But GnuTLS encodes another 16 bit length field inside the padding data: > 00 15 00 06 00 04 00 00 00 00 Thanks, nice catch. That code seems to follow an earlier draft which allowed freedom in the contents. > While this is likely not a security issue yet, encoding arbitrary data > in padding lead to several problems in the past (PKCS, ASN.1 encoding, > POODLE, ...). I think that is an overstatement. The TLS extension padding is to avoid certain broken firewalls, and has no cryptographic significance whatsoever. regards, Nikos From felix.grehl at escrypt.com Fri Jul 10 15:35:06 2015 From: felix.grehl at escrypt.com (Felix Grehl) Date: Fri, 10 Jul 2015 15:35:06 +0200 Subject: [gnutls-devel] No identity hint when using DHE-PSK Message-ID: <626705c4-ed4b-4f48-a597-ada8310de74d@escrypt.com> Hi, I'm trying to use the cipher suite (TLS1.2)-(DHE-PSK-2048)-(AES-128-CBC)-(SHA1) with the server side. I'm setting an identity hint of non-zero length via gnutls_psk_set_server_credentials_hint(), but the ServerKeyExchange message still doesn't contain any hint (it has zero length). The same works fine if I only PSK instead of DHE-PSK (it's actually the very same code without setting the DH parameters in the credentials). Is this a known issue? My system environment is Win7 with cygwin: CYGWIN_NT-6.1-WOW bo3-140219-05 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 Cygwin I'm using GnuTLS version 3.3.15. From nmav at gnutls.org Fri Jul 10 21:19:43 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 10 Jul 2015 21:19:43 +0200 Subject: [gnutls-devel] No identity hint when using DHE-PSK In-Reply-To: <626705c4-ed4b-4f48-a597-ada8310de74d@escrypt.com> References: <626705c4-ed4b-4f48-a597-ada8310de74d@escrypt.com> Message-ID: <1436555983.16355.1.camel@gnutls.org> On Fri, 2015-07-10 at 15:35 +0200, Felix Grehl wrote: > Hi, > > I'm trying to use the cipher suite > (TLS1.2)-(DHE-PSK-2048)-(AES-128-CBC)-(SHA1) with the server side. I'm > setting an identity hint of non-zero length via > gnutls_psk_set_server_credentials_hint(), but the ServerKeyExchange > message still doesn't contain any hint (it has zero length). The same > works fine if I only PSK instead of DHE-PSK (it's actually the very > same code without setting the DH parameters in the credentials). Is > this a known issue? My system environment is Win7 with cygwin: > CYGWIN_NT-6.1-WOW bo3-140219-05 2.0.4(0.287/5/3) 2015-06-09 12:20 i686 > Cygwin I'm using GnuTLS version 3.3.15. Hi, That is a bug. The hint is not set, nor read in the DHE and ECDHE PSK ciphersuites. I've committed a fix which will be included in the next release. Thank you for reporting that. Nikos From nmav at gnutls.org Sun Jul 12 15:28:16 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 12 Jul 2015 15:28:16 +0200 Subject: [gnutls-devel] gnutls 3.3.16 Message-ID: <1436707696.18372.0.camel@gnutls.org> Hello, I've just released gnutls 3.3.16. This is a bug-fix release on the current stable branch. * Version 3.3.16 (released 2015-07-12) ** libgnutls: Allow compilation with nettle 3.0 or later ** libgnutls: corrected failure when importing plain files with gnutls_x509_privkey_import2(), and a password was provided. ** libgnutls: Don't reject certificates if a CA has the URI or IP address name constraints, and the end certificate doesn't have an IP address name or a URI set. ** libgnutls: set and read the hint in DHE-PSK and ECDHE-PSK ciphersuites. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.16.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.16.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.16.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.16.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Sun Jul 12 15:30:02 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 12 Jul 2015 15:30:02 +0200 Subject: [gnutls-devel] gnutls 3.4.3 Message-ID: <1436707802.18372.2.camel@gnutls.org> Hello, I've just released gnutls 3.4.3. This version fixes bugs and adds minor features to the next stable branch. * Version 3.4.3 (released 2015-07-12) ** libgnutls: Follow closely RFC5280 recommendations and use UTCTime for dates prior to 2050. ** libgnutls: Force 16-byte alignment to all input to ciphers (previously it was done only when cryptodev was enabled). ** libgnutls: Removed support for pthread_atfork() as it has undefined semantics when used with dlopen(), and may lead to a crash. ** libgnutls: corrected failure when importing plain files with gnutls_x509_privkey_import2(), and a password was provided. ** libgnutls: Don't reject certificates if a CA has the URI or IP address name constraints, and the end certificate doesn't have an IP address name or a URI set. ** libgnutls: set and read the hint in DHE-PSK and ECDHE-PSK ciphersuites. ** p11tool: Added --list-token-urls option, and print the token module name in list-tokens. ** API and ABI modifications: gnutls_ecc_curve_get_oid: Added gnutls_digest_get_oid: Added gnutls_pk_get_oid: Added gnutls_sign_get_oid: Added gnutls_ecc_curve_get_id: Added gnutls_oid_to_digest: Added gnutls_oid_to_pk: Added gnutls_oid_to_sign: Added gnutls_oid_to_ecc_curve: Added gnutls_pkcs7_get_signature_count: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.3.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.3.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.3.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.3.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From rick at openfortress.nl Sun Jul 19 20:47:43 2015 From: rick at openfortress.nl (Rick van Rein) Date: Sun, 19 Jul 2015 20:47:43 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) Message-ID: <55ABF0CF.9070205@openfortress.nl> Hello, The gnutls_prf() function takes arguments ?extra? and ?extra_size?, which are meant to conform to what RFC 5705 calls a ?context?. 1. The function docs state that "extra" is optional, but passing NULL in it causes a memcpy() with NULL source, which causes SEGFAULT (on Linux) even when copying 0 bytes. 2. The RFC states that the context is preceded with its length in 16 bits, if a context is provided. But gnutls_prf() does not check the length to fit in 16 bits, and it does not prefix the length. The function documentation also does not state that the caller must prefix the length -- which is probably not the idea anyway. 3. Ample warning about the distinction between "extra == NULL" (in which case no context or length is added) and "extra_size == 0" (zero bytes of context added, with a zero length preceding it) is missing in the function documentation. 4. The different naming of ?extra? from ?context? was confusing me when I was trying to use the function from the API spec plus the RFC; perhaps the RFC-name ?context? is a good name to preserve. If you agree that these are potential places for improvement, then please find patches to resolve the above attached. * The 3.2.21 patch was made against the version in which I encountered the problem, and against which I patched it. * The 3.3.16 patch is virtually the same, but against stable head; it has only been tested to compile well. * Note that I am not aware of an easy way to compare the generated PRF with a known-correct value. I hope you willl find these changes useful. Let me know if you would like me to deliver other / better / ? variations on top of, or instead of, these ones. Thanks! -Rick ? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls_prf-rfc5705-context-fix-3.2.21.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls_prf-rfc5705-context-fix-3.3.16.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 268 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Mon Jul 20 10:48:09 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Jul 2015 10:48:09 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) In-Reply-To: <55ABF0CF.9070205@openfortress.nl> References: <55ABF0CF.9070205@openfortress.nl> Message-ID: On Sun, Jul 19, 2015 at 8:47 PM, Rick van Rein wrote: > Hello, > The gnutls_prf() function takes arguments ?extra? and ?extra_size?, > which are meant to conform to what RFC 5705 calls a ?context?. > 1. > > The function docs state that "extra" is optional, but passing NULL > in it causes a memcpy() with NULL source, which causes SEGFAULT (on > Linux) even when copying 0 bytes. That's quite strange. I don't seem to be able to reproduce but it could be libc-version specific. > 2. > The RFC states that the context is preceded with its length in 16 > bits, if a context is provided. But gnutls_prf() does not check the > length to fit in 16 bits, and it does not prefix the length. The > function documentation also does not state that the caller must > prefix the length -- which is probably not the idea anyway. That's quite unfortunate. It seems that gnutls_prf() was not made to follow rfc5705 but rather an earlier draft and was not updated in the final version. I'm not sure whether gnutls_prf() should be updated to fix that issue. One reason is that there may be users of gnutls_prf() which already prefix extra properly to get the expected output, and the other is that gnutls_prf() is quite complicated. It has this "server_random_first" option, which while it may have been useful in pre-rfc5705 times, now it is plainly confusing. Hence, I think it would be cleaner to introduce another API to follow RFC5705. > The different naming of ?extra? from ?context? was confusing me when > I was trying to use the function from the API spec plus the RFC; > perhaps the RFC-name ?context? is a good name to preserve. > If you agree that these are potential places for improvement, then > please find patches to resolve the above attached. Thanks for bringing that up. I'll document that gnutls_prf() does not provide the expected for RFC5705, and add gnutls_prf_rfc5705() which will be easier to use. I'd appreciate if you could check the new function; it is uses gnutls_prf(), so you could use something similar directly. https://gitlab.com/gnutls/gnutls/commit/e4cddac1b97352587e8eefaf5c9e1f8dfcf2ad53 > * The 3.2.21 patch was made against the version in which I encountered > the problem, and against which I patched it. > * The 3.3.16 patch is virtually the same, but against stable head; it > has only been tested to compile well. > * Note that I am not aware of an easy way to compare the generated PRF > with a known-correct value. It is also unfortunate that the RFC doesn't include any known values. I've included a known answer test in tests/prf.c in the repository. regards, Nikos From rick at openfortress.nl Mon Jul 20 14:30:38 2015 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 20 Jul 2015 14:30:38 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) In-Reply-To: References: <55ABF0CF.9070205@openfortress.nl> Message-ID: <55ACE9EE.1000709@openfortress.nl> Hi Nikos, You're quick :) I encountered the SEGFAULT on: - Linux 2.6.32-5-openvz-amd64 SMP - libc6 2.11.3-4 Like you, I was hesitant about breaking the gnutls_prf() and agree you might split the function calls. I just couldn't find any code (or reason to have such code) for the current implementation. I backported your patch to the version that was troubled, and got the expected result: - SEGFAULT without my patch - No crash with your patch and use of gnutls_prf() using extra==NULL - No crash with your patch and use of gnutls_prf_rfc5705() using context==NULL One thing though; with your patch, gnutls_prf_rfc5705() responds to context==NULL and context_size=-1 with an error due to the unsigned check on > 65535. This does not seem helpful but it can be confusing -- or lead to unnoticed weak keys (I got AAAAAAAAAAAAAAAAAAAAAA== but who prints session keys??) It leads to extra code too, gnutls_prf_rfc5705 ( ..., (in2len >= 0)? in2len: 0, (in2len >= 0) ? in2: NULL, ...); so I'd propose changing the check to if (context && (context_size > 65535)) { gnutls_assert(); return GNUTLS_E_INVALID_REQUEST; } I tested this, and as expected it is more robust as it also works with the much simpler call gnutls_prf_rfc5705 ( ..., in2len, (in2len >= 0) ? in2: NULL, ...); I hope this is helpful. Your patch surely is, thanks! Cheers, -Rick From nmav at gnutls.org Mon Jul 20 15:25:08 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Jul 2015 15:25:08 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) In-Reply-To: <55ACE9EE.1000709@openfortress.nl> References: <55ABF0CF.9070205@openfortress.nl> <55ACE9EE.1000709@openfortress.nl> Message-ID: On Mon, Jul 20, 2015 at 2:30 PM, Rick van Rein wrote: > Like you, I was hesitant about breaking the gnutls_prf() and agree you > might split the function calls. I just couldn't find any code (or > reason to have such code) for the current implementation. Most likely we can live with a fixed version as even if gnutls_prf() is used, the context is not typically set. However, I'm pretty sure if I do that there will be a bug report for incompatibility at some point. > I backported your patch to the version that was troubled, and got the > expected result: > - SEGFAULT without my patch > - No crash with your patch and use of gnutls_prf() using extra==NULL > - No crash with your patch and use of gnutls_prf_rfc5705() using > context==NULL > One thing though; with your patch, gnutls_prf_rfc5705() responds to > context==NULL and context_size=-1 with an error due to the unsigned > check on > 65535. This does not seem helpful but it can be confusing -- > or lead to unnoticed weak keys (I got AAAAAAAAAAAAAAAAAAAAAA== but who > prints session keys??) But you should have checked the error code :) Nevertheless, I modified it to return error only when there are any data available. Reading again the RFC though, it makes me not agree with the following. > Ample warning about the distinction between "extra == NULL" (in > which case no context or length is added) and "extra_size == 0" > (zero bytes of context added, with a zero length preceding it) is > missing in the function documentation. I don't think that the case of non-null context with zero size is intended to be handled. What is my understanding of RFC5705 is that if no context is provided no length is put there. The case of having a zero length seems to be outside the scope. regards, Nikos From rick at openfortress.nl Mon Jul 20 20:38:31 2015 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 20 Jul 2015 20:38:31 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) In-Reply-To: References: <55ABF0CF.9070205@openfortress.nl> <55ACE9EE.1000709@openfortress.nl> Message-ID: <55AD4027.6070801@openfortress.nl> Hi Nikos, One thing though; with your patch, gnutls_prf_rfc5705() responds to context==NULL and context_size=-1 with an error due to the unsigned check on > 65535. This does not seem helpful but it can be confusing -- or lead to unnoticed weak keys (I got AAAAAAAAAAAAAAAAAAAAAA== but who prints session keys??) > > But you should have checked the error code :) Nevertheless, I modified > it to return error only when there are any data available. Great. You are right about return codes and yet... it's better not to count on it completely :) > Reading again the RFC though, it makes me not agree with the following. >> Ample warning about the distinction between "extra == NULL" (in >> which case no context or length is added) and "extra_size == 0" >> (zero bytes of context added, with a zero length preceding it) is >> missing in the function documentation. > > I don't think that the case of non-null context with zero size is > intended to be handled. Section 4 literally says "The context MAY be zero length." Since it refers the context, I am assuming they mean the case "If context is provided, it computes:". > What is my understanding of RFC5705 is that if > no context is provided no length is put there. Yes, no context length and of course no context bytes. > The case of having a > zero length seems to be outside the scope. > I'm sure I could dream up a pathological usecase ;-) but the quote above blocked my creativity. Thanks Nikos, -Rick From nmav at gnutls.org Mon Jul 20 21:38:00 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 20 Jul 2015 21:38:00 +0200 Subject: [gnutls-devel] gnutls_prf not compliant to RFC 5705 (or confusingly so) In-Reply-To: <55AD4027.6070801@openfortress.nl> References: <55ABF0CF.9070205@openfortress.nl> <55ACE9EE.1000709@openfortress.nl> <55AD4027.6070801@openfortress.nl> Message-ID: <1437421080.24392.1.camel@gnutls.org> On Mon, 2015-07-20 at 20:38 +0200, Rick van Rein wrote: > Hi Nikos, > > One thing though; with your patch, gnutls_prf_rfc5705() responds to > context==NULL and context_size=-1 with an error due to the unsigned > check on > 65535. This does not seem helpful but it can be confusing -- > or lead to unnoticed weak keys (I got AAAAAAAAAAAAAAAAAAAAAA== but who > prints session keys??) Should we need to handle that case? I mean the size_t is an unsigned type anyway, -1 is not an accepted value. > Section 4 literally says "The context MAY be zero length." Since it > refers the context, I am assuming they mean the case "If context is > provided, it computes:". Yes, I stumbled on that section too. Anyway I've made it handle that case and documented it. As it is a new API it will cause no issues to existing software. Thanks for bringing that up. Nikos From priyaranjan4169 at gmail.com Mon Jul 27 12:03:49 2015 From: priyaranjan4169 at gmail.com (Priyaranjan Nayak) Date: Mon, 27 Jul 2015 15:33:49 +0530 Subject: [gnutls-devel] DTLS-SRTP's send/recv API of gnutls Message-ID: Hi All, I am using gnutls-3.4.3 version in my project for dtls-srtp connection. Could you please tell me 1. What are the API needs to be call for protect/unprotect the data in case of dtls-srtp ? OR 1. Do I need to call gnutls_record_send ()/gnutls_record_recv () to send/recv the packet in dtls-srtp ? Thanks Priyaranjan -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaudius at qq.com Mon Jul 27 09:16:18 2015 From: klaudius at qq.com (=?utf-8?B?THVj?=) Date: Mon, 27 Jul 2015 15:16:18 +0800 Subject: [gnutls-devel] mod_gnutls-0.7 encontered a problem at the last step "make" Message-ID: Sir, I am trying to set up mod_gnutls on CentOS 6.5 64, and encontered a problem at the last step "make" My steps were recorded here: http://amon.org/how-to-setup-multiple-ssl-ca-for-one-ip.html the problem is: #wget https://mod.gnutls.org/downloads/mod_gnutls-0.7.tar.bz2 #tar -xjvf mod_gnutls-0.7.tar.bz2 #cd mod_gnutls-0.7 #./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/local/lib64/pkgconfig/ Configuration summary for mod_gnutls: * mod_gnutls version: 0.7 * Apache Modules directory: /usr/lib64/httpd/modules * GnuTLS Library version: 3.4.3 * SRP Authentication: no * MSVA Client Verification: no * Build documentation: no #make mod_gnutls.c:260: error: missing initializer mod_gnutls.c:260: error: (near initialization for 'mgs_config_cmds[27].func') make[1]: *** [libmod_gnutls_la-mod_gnutls.lo] Error 1 make[1]: Leaving directory `/root/mod_gnutls-0.7/src' make: *** [all-recursive] Error 1 What should I do to resolve it? Regards Luc -------------- next part -------------- An HTML attachment was scrubbed... URL: From eliz at gnu.org Tue Jul 28 19:25:50 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 28 Jul 2015 20:25:50 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: Message-ID: <837fpkxkgx.fsf@gnu.org> > From: Rustom Mody > Date: Tue, 28 Jul 2015 22:37:05 +0530 > Cc: Eli Zaretskii > > Start emacs with -Q > Run (package-initialize) > Run (add-to-list 'package-archives > '("marmalade" . "https://marmalade-repo.org/packages/") t) > Run M-x package-list-packages > > Get error > gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly > terminated. I think the real question here is why does GnuTLS regard this situation so important as to warrant a high-priority alert to the user. From rustompmody at gmail.com Tue Jul 28 19:07:05 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Tue, 28 Jul 2015 22:37:05 +0530 Subject: [gnutls-devel] TLS connection improperly terminated Message-ID: Hi I am not really a user of gnutls; just a user of user (viz a user of emacs) The emacs-dev (Eli Zaretskii) could not reproduce the bug I reported which pointed to gnutls so he suggested I submit this to you. The bug which I submitted there (emacs bug no. 21145 ) is reproduced here: Start emacs with -Q Run (package-initialize) Run (add-to-list 'package-archives '("marmalade" . "https://marmalade-repo.org/packages/") t) Run M-x package-list-packages Get error gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated. Some info from ldconfig -v|grep libgnutls libgnutls-deb0.so.28 -> libgnutls-deb0.so.28.41.0 /sbin/ldconfig.real: /lib/x86_64-linux-gnu/ld-2.21.so is the dynamic linker, ignoring libgnutls-openssl.so.27 -> libgnutls-openssl.so.27.0.2 libgnutls-deb0.so.28 -> libgnutls-deb0.so.28.41.0 Above is ubuntu 15.4 with emacs 24.4.1 With ubuntu 14.10 with emacs 24.3.1 error (warning) is gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange has been lowered to 256 bits and this may allow decryption of the session data From dkg at fifthhorseman.net Tue Jul 28 22:02:19 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Jul 2015 16:02:19 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <837fpkxkgx.fsf@gnu.org> References: <837fpkxkgx.fsf@gnu.org> Message-ID: <87zj2ggies.fsf@alice.fifthhorseman.net> On Tue 2015-07-28 13:25:50 -0400, Eli Zaretskii wrote: >> From: Rustom Mody >> Date: Tue, 28 Jul 2015 22:37:05 +0530 >> Cc: Eli Zaretskii >> >> Start emacs with -Q >> Run (package-initialize) >> Run (add-to-list 'package-archives >> '("marmalade" . "https://marmalade-repo.org/packages/") t) >> Run M-x package-list-packages >> >> Get error >> gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly >> terminated. > > I think the real question here is why does GnuTLS regard this > situation so important as to warrant a high-priority alert to the > user. AFAICT, the main issue is that the certificate chain offered by https://marmalade-repo.org is "transvalid" -- meaning it does not offer any intermediate certificates that would allow a user to chain its end-entity certificate to a known root. https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html see the qualys report for that server here: https://www.ssllabs.com/ssltest/analyze.html?d=marmalade-repo.org&latest The connection to this server fails, because it cannot be properly authenticated. it looks to me like GnuTLS is doing the right thing by reporting that the connection failed. Would you rather it do something else? --dkg From dkg at fifthhorseman.net Tue Jul 28 23:04:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 28 Jul 2015 17:04:27 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: Message-ID: <87mvyggfj8.fsf@alice.fifthhorseman.net> On Tue 2015-07-28 13:07:05 -0400, Rustom Mody wrote: > gnutls.c: [1] Note that the security level of the Diffie-Hellman key exchange > has been lowered to 256 bits and this may allow decryption of the session data In my testing of marmelade-repo.org's https server, i do not see a 256-bit finite-field DHE setup, i see a 1024-bit (FF)DHE setup: 0 dkg at alice:~$ gnutls-cli --priority NORMAL:-ECDHE-RSA --tofu marmalade-repo.org Processed 163 CA certificate(s). Resolving 'marmalade-repo.org'... Connecting to '80.69.77.43:443'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `OU=Domain Control Validated,OU=PositiveSSL,CN=marmalade-repo.org', issuer `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2015-07-12 00:00:00 UTC', expires `2018-07-11 23:59:59 UTC', SHA-1 fingerprint `6e080a477d14631d2edf839de582ac04d4363d09' Public Key ID: aba6d76ab3d363fa190d654160236eefd32a46dc Public key's random art: +--[ RSA 2048]----+ | . +oo | | . o . . | | o o | | . . o | | . .S | | o.E= | | . o= o | | O.== | | .*=X+. | +-----------------+ - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... - Description: (TLS1.2)-(DHE-RSA-1024)-(AES-256-GCM) - Session ID: 63:DA:A1:02:83:2A:E6:BC:E8:07:2C:7D:B3:30:00:E7:68:EA:33:6C:01:F6:6E:D0:35:27:7B:6D:1E:4E:FC:DA - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 319 bits - Peer's public key: 1023 bits GnuTLS's tighter limits are for (FF)DHE, not for ECDHE, and they do not reject this 1024-bit group today. The issue is the transvalid cert chain, as i mentioned in another e-mail. For ECDHE, this server uses a 256-bit curve, but that is far stronger than the (FF)DHE 1024-bit group, so it should not be an issue either. --dkg From rustompmody at gmail.com Wed Jul 29 00:41:36 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Wed, 29 Jul 2015 04:11:36 +0530 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <87zj2ggies.fsf@alice.fifthhorseman.net> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> Message-ID: On Wed, Jul 29, 2015 at 1:32 AM, Daniel Kahn Gillmor wrote: > On Tue 2015-07-28 13:25:50 -0400, Eli Zaretskii wrote: > >> From: Rustom Mody > >> Date: Tue, 28 Jul 2015 22:37:05 +0530 > >> Cc: Eli Zaretskii > >> > >> Start emacs with -Q > >> Run (package-initialize) > >> Run (add-to-list 'package-archives > >> '("marmalade" . "https://marmalade-repo.org/packages/") t) > >> Run M-x package-list-packages > >> > >> Get error > >> gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly > >> terminated. > > > > I think the real question here is why does GnuTLS regard this > > situation so important as to warrant a high-priority alert to the > > user. > > AFAICT, the main issue is that the certificate chain offered by > https://marmalade-repo.org is "transvalid" -- meaning it does not offer > any intermediate certificates that would allow a user to chain its > end-entity certificate to a known root. > > > https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html > > see the qualys report for that server here: > > https://www.ssllabs.com/ssltest/analyze.html?d=marmalade-repo.org&latest > > The connection to this server fails, because it cannot be properly > authenticated. it looks to me like GnuTLS is doing the right thing by > reporting that the connection failed. Would you rather it do something > else? > > --dkg > The intricacies of certificates (and security in general) are beyond me. However the point to be noted is that I get a list of packages alright. So I dont know what you mean by "connection failed" Is the list the full list? Ive no idea AFAIK the message looks (semi)bogus If list there should be no message (at least not this one) If message there should be no list -------------- next part -------------- An HTML attachment was scrubbed... URL: From rustompmody at gmail.com Wed Jul 29 19:13:24 2015 From: rustompmody at gmail.com (Rustom Mody) Date: Wed, 29 Jul 2015 22:43:24 +0530 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> Message-ID: On Wed, Jul 29, 2015 at 4:11 AM, Rustom Mody wrote: > > > On Wed, Jul 29, 2015 at 1:32 AM, Daniel Kahn Gillmor < > dkg at fifthhorseman.net> wrote: > >> On Tue 2015-07-28 13:25:50 -0400, Eli Zaretskii wrote: >> >> From: Rustom Mody >> >> Date: Tue, 28 Jul 2015 22:37:05 +0530 >> >> Cc: Eli Zaretskii >> >> >> >> Start emacs with -Q >> >> Run (package-initialize) >> >> Run (add-to-list 'package-archives >> >> '("marmalade" . "https://marmalade-repo.org/packages/") >> t) >> >> Run M-x package-list-packages >> >> >> >> Get error >> >> gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly >> >> terminated. >> > >> > I think the real question here is why does GnuTLS regard this >> > situation so important as to warrant a high-priority alert to the >> > user. >> >> AFAICT, the main issue is that the certificate chain offered by >> https://marmalade-repo.org is "transvalid" -- meaning it does not offer >> any intermediate certificates that would allow a user to chain its >> end-entity certificate to a known root. >> >> >> https://blog.hboeck.de/archives/847-Incomplete-Certificate-Chains-and-Transvalid-Certificates.html >> >> see the qualys report for that server here: >> >> >> https://www.ssllabs.com/ssltest/analyze.html?d=marmalade-repo.org&latest >> >> The connection to this server fails, because it cannot be properly >> authenticated. it looks to me like GnuTLS is doing the right thing by >> reporting that the connection failed. Would you rather it do something >> else? >> >> --dkg >> > > The intricacies of certificates (and security in general) are beyond me. > > However the point to be noted is that I get a list of packages alright. > So I dont know what you mean by "connection failed" > Is the list the full list? Ive no idea > AFAIK the message looks (semi)bogus > If list there should be no message (at least not this one) > If message there should be no list > > One more datapoint I changed the https in the (add-to-list ... ) to http Contacting host: marmalade-repo.org:80 gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated. Make back https Contacting host: elpa.gnu.org:80 [3 times] Contacting host: marmalade-repo.org:443 gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly terminated. So tls is called for http?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Wed Jul 29 19:58:27 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 13:58:27 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> Message-ID: <87si86g81o.fsf@alice.fifthhorseman.net> On Tue 2015-07-28 18:41:36 -0400, Rustom Mody wrote: > The intricacies of certificates (and security in general) are beyond me. The nuances of emacs packages are beyond me, so i guess we're even ;) > However the point to be noted is that I get a list of packages alright. > So I dont know what you mean by "connection failed" presumably the list of packages available at each repository is fetched over a TLS connection (if you used https). If the connection to the repository fails (due to TLS or other failures) this is what the warning is about. > Is the list the full list? Ive no idea that sounds like an issue for emacs folks, more than for gnutls folks, as long as gnutls is properly reporting the failure up to emacs. > AFAIK the message looks (semi)bogus > If list there should be no message (at least not this one) > If message there should be no list are you sure there are no other package sources available? --dkg From dkg at fifthhorseman.net Wed Jul 29 20:03:16 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 14:03:16 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> Message-ID: <87pp3ag7tn.fsf@alice.fifthhorseman.net> On Wed 2015-07-29 13:13:24 -0400, Rustom Mody wrote: > One more datapoint > I changed the https in the (add-to-list ... ) to http > Contacting host: marmalade-repo.org:80 > gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly > terminated. > > Make back https > > Contacting host: elpa.gnu.org:80 [3 times] > Contacting host: marmalade-repo.org:443 > gnutls.c: [0] (Emacs) fatal error: The TLS connection was non-properly > terminated. > > So tls is called for http?? This really seems like an emacs question, not a gnutls question. --dkg From eliz at gnu.org Wed Jul 29 20:13:25 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 29 Jul 2015 21:13:25 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <87si86g81o.fsf@alice.fifthhorseman.net> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> Message-ID: <83y4hyx262.fsf@gnu.org> > From: Daniel Kahn Gillmor > Cc: Eli Zaretskii , bugs at gnutls.org > Date: Wed, 29 Jul 2015 13:58:27 -0400 > > > However the point to be noted is that I get a list of packages alright. > > So I dont know what you mean by "connection failed" > > presumably the list of packages available at each repository is fetched > over a TLS connection (if you used https). If the connection to the > repository fails (due to TLS or other failures) this is what the warning > is about. The connection to marmalade doesn't fail. > > Is the list the full list? Ive no idea > > that sounds like an issue for emacs folks, more than for gnutls folks, > as long as gnutls is properly reporting the failure up to emacs. > > > AFAIK the message looks (semi)bogus > > If list there should be no message (at least not this one) > > If message there should be no list > > are you sure there are no other package sources available? Each package is shown with its source, and quite a few of them are from marmalade, so the connection to marmalade seems to have succeeded, and the data was probably successfully retrieved. From eliz at gnu.org Wed Jul 29 20:18:21 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 29 Jul 2015 21:18:21 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <83y4hyx262.fsf@gnu.org> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> Message-ID: <83wpxix1xu.fsf@gnu.org> > Date: Wed, 29 Jul 2015 21:13:25 +0300 > From: Eli Zaretskii > Cc: rustompmody at gmail.com, bugs at gnutls.org > > > From: Daniel Kahn Gillmor > > Cc: Eli Zaretskii , bugs at gnutls.org > > Date: Wed, 29 Jul 2015 13:58:27 -0400 > > > > > However the point to be noted is that I get a list of packages alright. > > > So I dont know what you mean by "connection failed" > > > > presumably the list of packages available at each repository is fetched > > over a TLS connection (if you used https). If the connection to the > > repository fails (due to TLS or other failures) this is what the warning > > is about. > > The connection to marmalade doesn't fail. > > > > Is the list the full list? Ive no idea > > > > that sounds like an issue for emacs folks, more than for gnutls folks, > > as long as gnutls is properly reporting the failure up to emacs. > > > > > AFAIK the message looks (semi)bogus > > > If list there should be no message (at least not this one) > > > If message there should be no list > > > > are you sure there are no other package sources available? > > Each package is shown with its source, and quite a few of them are > from marmalade, so the connection to marmalade seems to have > succeeded, and the data was probably successfully retrieved. Moreover, with almost exactly the same version of GnuTLS and the same version of Emacs, I succeed to fetch the list of packages from marmalade on my system, without any error messages. The only significant differences between my system and Rustom's are (1) the OS, and (2) the trusted certificates stored on the system. Maybe also the network configuration, although I'm not sure how that could come into play. HTH From dkg at fifthhorseman.net Wed Jul 29 20:41:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 14:41:28 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <83y4hyx262.fsf@gnu.org> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> Message-ID: <87d1zag61z.fsf@alice.fifthhorseman.net> On Wed 2015-07-29 14:13:25 -0400, Eli Zaretskii wrote: >> From: Daniel Kahn Gillmor >> Cc: Eli Zaretskii , bugs at gnutls.org >> Date: Wed, 29 Jul 2015 13:58:27 -0400 >> >> > However the point to be noted is that I get a list of packages alright. >> > So I dont know what you mean by "connection failed" >> >> presumably the list of packages available at each repository is fetched >> over a TLS connection (if you used https). If the connection to the >> repository fails (due to TLS or other failures) this is what the warning >> is about. > > The connection to marmalade doesn't fail. So this is a non-fatal warning that is reported back to emacs? how is emacs invoking gnutls here? > Each package is shown with its source, and quite a few of them are > from marmalade, so the connection to marmalade seems to have > succeeded, and the data was probably successfully retrieved. interesting, and confusing. I tend to agree with you from an application perspective that the warning without a connection abort doesn't seem to be particularly actionable (though maybe this discussion will encourage the marmalade ops to fix their certchain), and that it seems like the connection should probably fail closed instead of failing open. --dkg From eliz at gnu.org Wed Jul 29 20:56:48 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 29 Jul 2015 21:56:48 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <87d1zag61z.fsf@alice.fifthhorseman.net> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> <87d1zag61z.fsf@alice.fifthhorseman.net> Message-ID: <83vbd2x05r.fsf@gnu.org> > From: Daniel Kahn Gillmor > Cc: rustompmody at gmail.com, bugs at gnutls.org > Date: Wed, 29 Jul 2015 14:41:28 -0400 > > > The connection to marmalade doesn't fail. > > So this is a non-fatal warning that is reported back to emacs? how is > emacs invoking gnutls here? Not sure what you want to hear in response. As you well know, invoking GnuTLS involves an elaborate setup, which calls many different GnuTLS functions. The function that actually fails is gnutls_handshake, I think. Is that what you wanted to know? > > Each package is shown with its source, and quite a few of them are > > from marmalade, so the connection to marmalade seems to have > > succeeded, and the data was probably successfully retrieved. > > interesting, and confusing. I tend to agree with you from an > application perspective that the warning without a connection abort > doesn't seem to be particularly actionable (though maybe this discussion > will encourage the marmalade ops to fix their certchain), and that it > seems like the connection should probably fail closed instead of failing > open. That was our feeling as well, yes. From dkg at fifthhorseman.net Wed Jul 29 23:24:53 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 29 Jul 2015 17:24:53 -0400 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <83vbd2x05r.fsf@gnu.org> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> <87d1zag61z.fsf@alice.fifthhorseman.net> <83vbd2x05r.fsf@gnu.org> Message-ID: <873806fyhm.fsf@alice.fifthhorseman.net> On Wed 2015-07-29 14:56:48 -0400, Eli Zaretskii wrote: >> From: Daniel Kahn Gillmor >> Cc: rustompmody at gmail.com, bugs at gnutls.org >> Date: Wed, 29 Jul 2015 14:41:28 -0400 >> >> > The connection to marmalade doesn't fail. >> >> So this is a non-fatal warning that is reported back to emacs? how is >> emacs invoking gnutls here? > > Not sure what you want to hear in response. As you well know, > invoking GnuTLS involves an elaborate setup, which calls many > different GnuTLS functions. The function that actually fails is > gnutls_handshake, I think. You're saying that gnutls_handshake fails, but the application continues to use the network connection? > Is that what you wanted to know? > >> > Each package is shown with its source, and quite a few of them are >> > from marmalade, so the connection to marmalade seems to have >> > succeeded, and the data was probably successfully retrieved. >> >> interesting, and confusing. I tend to agree with you from an >> application perspective that the warning without a connection abort >> doesn't seem to be particularly actionable (though maybe this discussion >> will encourage the marmalade ops to fix their certchain), and that it >> seems like the connection should probably fail closed instead of failing >> open. > > That was our feeling as well, yes. I think the description of the situation is: GnuTLS reports a warning/error about a certificate validation to the application, and the application decides to continue with the connection anyway, which seems like it is probably insecure. Is that right? I see two approaches: the application can close the connection when it sees that warning/error, or GnuTLS can terminate the connection for the user (effectively changing its interface contract, which has implications for other users of the library). I can see (good) arguments for the latter, but the former might be easier to accomplish. --dkg From eliz at gnu.org Thu Jul 30 04:41:59 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 30 Jul 2015 05:41:59 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <873806fyhm.fsf@alice.fifthhorseman.net> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> <87d1zag61z.fsf@alice.fifthhorseman.net> <83vbd2x05r.fsf@gnu.org> <873806fyhm.fsf@alice.fifthhorseman.net> Message-ID: <83twsmwemg.fsf@gnu.org> > From: Daniel Kahn Gillmor > Cc: rustompmody at gmail.com, bugs at gnutls.org > Date: Wed, 29 Jul 2015 17:24:53 -0400 > > >> So this is a non-fatal warning that is reported back to emacs? how is > >> emacs invoking gnutls here? > > > > Not sure what you want to hear in response. As you well know, > > invoking GnuTLS involves an elaborate setup, which calls many > > different GnuTLS functions. The function that actually fails is > > gnutls_handshake, I think. > > You're saying that gnutls_handshake fails, but the application continues > to use the network connection? Maybe. As I mentioned, I cannot reproduce the problem on my machine, so I was guessing by looking at the sources. If someone who can reproduce the problem could turn on all the logs in Emacs's gnutls.c and show the results, we might have a better idea. > I think the description of the situation is: > > GnuTLS reports a warning/error about a certificate validation to the > application, and the application decides to continue with the connection > anyway, which seems like it is probably insecure. Is that right? > > I see two approaches: the application can close the connection when it > sees that warning/error, or GnuTLS can terminate the connection for the > user (effectively changing its interface contract, which has > implications for other users of the library). I can see (good) > arguments for the latter, but the former might be easier to accomplish. Please don't forget the fact that on my system I fetch the list from marmalade without any error messages. So I think we don't even understand sufficiently well why is the message issued. From nmav at gnutls.org Thu Jul 30 13:22:05 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Jul 2015 14:22:05 +0300 Subject: [gnutls-devel] [gnutls-help] DTLS-SRTP's send/recv API of gnutls In-Reply-To: References: Message-ID: Hi, There are no SRTP packet handling functions in gnutls now. However, I'm already considering adding ESP packet handling in gnutls, so it would make sense to consider adding SRTP as well. Martin what do you think? Could the SRTP functions that you use be ported in gnutls? regards, Nikos On Mon, Jul 27, 2015 at 1:03 PM, Priyaranjan Nayak wrote: > Hi All, > > I am using gnutls-3.4.3 version in my project for dtls-srtp connection. > Could you please tell me > > What are the API needs to be call for protect/unprotect the data in case of > dtls-srtp ? > > OR > > Do I need to call gnutls_record_send ()/gnutls_record_recv () to send/recv > the packet in dtls-srtp ? > > Thanks > Priyaranjan > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From martin at martin.st Thu Jul 30 14:10:10 2015 From: martin at martin.st (=?ISO-8859-15?Q?Martin_Storsj=F6?=) Date: Thu, 30 Jul 2015 15:10:10 +0300 (EEST) Subject: [gnutls-devel] [gnutls-help] DTLS-SRTP's send/recv API of gnutls In-Reply-To: References: Message-ID: Hi Nikos, On Thu, 30 Jul 2015, Nikos Mavrogiannopoulos wrote: > Hi, > There are no SRTP packet handling functions in gnutls now. However, > I'm already considering adding ESP packet handling in gnutls, so it > would make sense to consider adding SRTP as well. Martin what do you > think? Could the SRTP functions that you use be ported in gnutls? The SRTP routines I use would probably be pretty easy to adapt into gnutls: https://git.libav.org/?p=libav.git;a=blob;f=libavformat/srtp.h https://git.libav.org/?p=libav.git;a=blob;f=libavformat/srtp.c This shouldn't have much actual dependencies on the surrounding libraries; it only uses some generic AES encryption/decryption, HMAC, base64 and endian independent reading/writing of integers. Since I'm the only author of these files, I can relicense it to the license used by gnutls if you want to, to help integration. The only thing missing here is the glue for mapping the value returned by gnutls_srtp_get_selected_profile to strings to pass to ff_srtp_set_crypto, but that is pretty much trivial. // Martin From hecht at hlrs.de Thu Jul 30 14:32:06 2015 From: hecht at hlrs.de (Martin Hecht) Date: Thu, 30 Jul 2015 14:32:06 +0200 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <83twsmwemg.fsf@gnu.org> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> <87d1zag61z.fsf@alice.fifthhorseman.net> <83vbd2x05r.fsf@gnu.org> <873806fyhm.fsf@alice.fifthhorseman.net> <83twsmwemg.fsf@gnu.org> Message-ID: <55BA1946.1070402@hlrs.de> On 07/30/2015 04:41 AM, Eli Zaretskii wrote: >> From: Daniel Kahn Gillmor >> Cc: rustompmody at gmail.com, bugs at gnutls.org >> Date: Wed, 29 Jul 2015 17:24:53 -0400 >> >>>> So this is a non-fatal warning that is reported back to emacs? how is >>>> emacs invoking gnutls here? >>> Not sure what you want to hear in response. As you well know, >>> invoking GnuTLS involves an elaborate setup, which calls many >>> different GnuTLS functions. The function that actually fails is >>> gnutls_handshake, I think. >> You're saying that gnutls_handshake fails, but the application continues >> to use the network connection? > Maybe. As I mentioned, I cannot reproduce the problem on my machine, If it works for some people and is not reproducible for others, could it be that it fails due to a shaky network connection? This should be handled on the TCP layer, but if one side notices it and does retransmits and the session layer doesn't handle it properly - or more precisely, it is able to resume (otherwise the application wouldn't be able to use the connection afterwards), but somehow the hiccup is communicated up to the presentation and application layer (if not explicitly, but maybe by reaching some timeouts there?) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2232 bytes Desc: S/MIME Cryptographic Signature URL: From eliz at gnu.org Thu Jul 30 18:38:14 2015 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 30 Jul 2015 19:38:14 +0300 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: <55BA1946.1070402@hlrs.de> References: <837fpkxkgx.fsf@gnu.org> <87zj2ggies.fsf@alice.fifthhorseman.net> <87si86g81o.fsf@alice.fifthhorseman.net> <83y4hyx262.fsf@gnu.org> <87d1zag61z.fsf@alice.fifthhorseman.net> <83vbd2x05r.fsf@gnu.org> <873806fyhm.fsf@alice.fifthhorseman.net> <83twsmwemg.fsf@gnu.org> <55BA1946.1070402@hlrs.de> Message-ID: <83oaitwqh5.fsf@gnu.org> > Date: Thu, 30 Jul 2015 14:32:06 +0200 > From: Martin Hecht > CC: bugs at gnutls.org > > If it works for some people and is not reproducible for others, could it > be that it fails due to a shaky network connection? It could be, but since the OP sees that consistently, I'd have hard time explaining that by shaky connections. From home_pw at msn.com Thu Jul 30 18:55:41 2015 From: home_pw at msn.com (Peter Williams) Date: Thu, 30 Jul 2015 09:55:41 -0700 Subject: [gnutls-devel] TLS connection improperly terminated Message-ID: I dont like the trends. A packet handler for ipsec and srtp should not be "fitted into" a tls /dtls protocol machine, and never forget the lengths to which folks will install buggy protovol and ciphersuite version and error negotiation handshakes/signals into commercial standards *to facilitate cryptosystem discovery and compromise*. Remember, its only a month ago since the uk-gchq academics were saying how little was achieved by doing power signals analysis on typical PC based crypto systems, at merely 3ft separation - *only the next room, had any "validity, as a breakthrough*. Sent from my Windows Phone ________________________________ From: Eli Zaretskii Sent: ?7/?30/?2015 9:39 AM To: Martin Hecht Cc: bugs at gnutls.org Subject: Re: [gnutls-devel] TLS connection improperly terminated > Date: Thu, 30 Jul 2015 14:32:06 +0200 > From: Martin Hecht > CC: bugs at gnutls.org > > If it works for some people and is not reproducible for others, could it > be that it fails due to a shaky network connection? It could be, but since the OP sees that consistently, I'd have hard time explaining that by shaky connections. _______________________________________________ Gnutls-devel mailing list Gnutls-devel at lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecht at hlrs.de Fri Jul 31 11:06:20 2015 From: hecht at hlrs.de (Martin Hecht) Date: Fri, 31 Jul 2015 11:06:20 +0200 Subject: [gnutls-devel] TLS connection improperly terminated In-Reply-To: References: Message-ID: <55BB3A8C.70501@hlrs.de> On 07/30/2015 06:55 PM, Peter Williams wrote: > I dont like the trends. A packet handler for ipsec and srtp should not be "fitted into" a tls /dtls protocol machine, ... I guess you wanted to reply to the mail by Martin Storsj? with subject "DTLS-SRTP's send/recv API of gnutls" instead of this thread -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2232 bytes Desc: S/MIME Cryptographic Signature URL: