From alessandro.carminati at gmail.com Sun Feb 15 15:54:58 2015 From: alessandro.carminati at gmail.com (Alessandro Carminati) Date: Sun, 15 Feb 2015 15:54:58 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake Message-ID: Hello, Recent Google updates in its services brought me here. I'm quite new in gnutls, therefore I want to apologize with everyone if I ask for something anyone should know. Due to Google Talk xmpp shutdown, I'm trying to use a new xmpp services without any significant success. My application uses iksemel which uses gnutls for transport, and it keeps crashing on setting up a tls connection to the server. Error seems to be in the function "handshake" located in iksemel src/stream.c file. It seems that when iksemel handshake function invokes gnutls_handshake, it spawns an GNUTLS_E_PULL_ERROR. Looking at when this event occurs, I determinated that when in _gnutls_stream_read, pull_func is invoked it terminates with an error which is nor EAGAIN nor EINTR. Can you please help me in understand why this event is occuring? Because I do not have any high level understanding of what GNUTLS is doing at this level, I do not understand which is the high level condition that brings me to this error. Thank you Alessandro Carminati -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelbriand at free.fr Sun Feb 15 17:54:38 2015 From: michelbriand at free.fr (Michel Briand) Date: Sun, 15 Feb 2015 17:54:38 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake In-Reply-To: References: Message-ID: <20150215175438.1c77d083@eridu.kheb.dyndns.org> Alessandro Carminati - Sun, 15 Feb 2015 15:54:58 +0100 >Hello, > >Recent Google updates in its services brought me here. >I'm quite new in gnutls, therefore I want to apologize with everyone >if I ask for something anyone should know. > >Due to Google Talk xmpp shutdown, I'm trying to use a new xmpp services >without any significant success. >My application uses iksemel which uses gnutls for transport, and it >keeps crashing on setting up a tls connection to the server. >Error seems to be in the function "handshake" located in iksemel >src/stream.c file. >It seems that when iksemel handshake function invokes >gnutls_handshake, it spawns an GNUTLS_E_PULL_ERROR. >Looking at when this event occurs, I determinated that when in >_gnutls_stream_read, pull_func is invoked it terminates with an error >which is nor EAGAIN nor EINTR. >Can you please help me in understand why this event is occuring? >Because I do not have any high level understanding of what GNUTLS is >doing at this level, I do not understand which is the high level >condition that brings me to this error. > >Thank you >Alessandro Carminati Hello, please help us with a direct link to the source code you tell about (or an excerpt if it is possible. Michel From alessandro.carminati at gmail.com Sun Feb 15 19:06:06 2015 From: alessandro.carminati at gmail.com (Alessandro Carminati) Date: Sun, 15 Feb 2015 19:06:06 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake Message-ID: Hello, thank you for answered my help request. The following is the iksemel function handshake where I issue is spawned. static int handshake (struct stream_data *data) { const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, 0 }; const int kx_priority[] = { GNUTLS_KX_RSA, 0 }; const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_ARCFOUR, 0}; const int comp_priority[] = { GNUTLS_COMP_ZLIB, GNUTLS_COMP_NULL, 0 }; const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0 }; int ret; if (gnutls_global_init () != 0) return IKS_NOMEM; if (gnutls_certificate_allocate_credentials (&data->cred) < 0) return IKS_NOMEM; if (gnutls_init (&data->sess, GNUTLS_CLIENT) != 0) { gnutls_certificate_free_credentials (data->cred); return IKS_NOMEM; } gnutls_protocol_set_priority (data->sess, protocol_priority); gnutls_cipher_set_priority(data->sess, cipher_priority); gnutls_compression_set_priority(data->sess, comp_priority); gnutls_kx_set_priority(data->sess, kx_priority); gnutls_mac_set_priority(data->sess, mac_priority); gnutls_credentials_set (data->sess, GNUTLS_CRD_CERTIFICATE, data->cred); gnutls_transport_set_push_function (data->sess, (gnutls_push_func) tls_push); gnutls_transport_set_pull_function (data->sess, (gnutls_pull_func) tls_pull); gnutls_transport_set_ptr (data->sess, data->prs); ret = gnutls_handshake (data->sess); //*****************here gnutls_handshake returns GNUTLS_E_PULL_ERROR if (ret != 0) { gnutls_deinit (data->sess); gnutls_certificate_free_credentials (data->cred); return IKS_NET_TLSFAIL; } data->flags &= (~SF_TRY_SECURE); data->flags |= SF_SECURE; iks_send_header (data->prs, data->server); return IKS_OK; } The followings are the gnutls functions involved in this issue: static ssize_t _gnutls_stream_read(gnutls_session_t session, mbuffer_st ** bufel, size_t size, gnutls_pull_func pull_func, unsigned int *ms) { size_t left; ssize_t i = 0; size_t max_size = max_record_recv_size(session); uint8_t *ptr; gnutls_transport_ptr_t fd = session->internals.transport_recv_ptr; int ret; struct timespec t1, t2; unsigned int diff; session->internals.direction = 0; *bufel = _mbuffer_alloc_align16(MAX(max_size, size), get_total_headers(session)); if (!*bufel) { gnutls_assert(); return GNUTLS_E_MEMORY_ERROR; } ptr = (*bufel)->msg.data; left = size; while (left > 0) { if (ms && *ms > 0) { ret = _gnutls_io_check_recv(session, *ms); if (ret < 0) { gnutls_assert(); goto cleanup; } gettime(&t1); } reset_errno(session); i = pull_func(fd, &ptr[size - left], left); if (i < 0) { int err = get_errno(session); _gnutls_read_log("READ: %d returned from %p, errno=%d gerrno=%d\n",(int) i, fd, errno,session->internals.errnum); if (err == EAGAIN || err == EINTR) { if (size - left > 0) { _gnutls_read_log("READ: returning %d bytes from %p\n",(int) (size - left), fd); goto finish; } ret = errno_to_gerr(err, 0); goto cleanup; } else { gnutls_assert(); ret = GNUTLS_E_PULL_ERROR2; // I changed this error code just to be sure the problem was here, before my change it was GNUTLS_E_PULL_ERROR goto cleanup; } } else { _gnutls_read_log("READ: Got %d bytes from %p\n",(int) i, fd); if (i == 0) break; /* EOF */ } left -= i; (*bufel)->msg.size += i; if (ms && *ms > 0) { gettime(&t2); diff = timespec_sub_ms(&t2, &t1); if (diff < *ms) gettime(&t2); diff = timespec_sub_ms(&t2, &t1); if (diff < *ms) *ms -= diff; else { ret = gnutls_assert_val(GNUTLS_E_TIMEDOUT); goto cleanup; } } } finish: _gnutls_read_log("READ: read %d bytes from %p\n",(int) (size - left), fd); if (size - left == 0) _mbuffer_xfree(bufel); return (size - left); cleanup: _mbuffer_xfree(bufel); return ret; } static ssize_t pull_func(gnutls_transport_ptr_t p, void *data, size_t size) { priv_data_st *priv = p; struct sockaddr_in cli_addr; socklen_t cli_addr_size; char buffer[64]; int ret; cli_addr_size = sizeof(cli_addr); ret = recvfrom(priv->fd, data, size, 0, (struct sockaddr *) &cli_addr, &cli_addr_size); if (ret == -1) return ret; if (cli_addr_size == priv->cli_addr_size && memcmp(&cli_addr, priv->cli_addr, sizeof(cli_addr)) == 0) return ret; printf("Denied connection from %s\n", human_addr((struct sockaddr *) &cli_addr, sizeof(cli_addr), buffer, sizeof(buffer))); gnutls_transport_set_errno(priv->session, EAGAIN); return -1; } My problem is I do not have an high level view of what gnutls is going to do, so I can't figure out what the cause can be. Please help me to understand. Alessandro Carminati -------------- next part -------------- An HTML attachment was scrubbed... URL: From michelbriand at free.fr Sun Feb 15 21:42:59 2015 From: michelbriand at free.fr (Michel Briand) Date: Sun, 15 Feb 2015 21:42:59 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake In-Reply-To: References: Message-ID: <20150215214259.6c196a25@eridu.kheb.dyndns.org> Alessandro, is this library (iksemel) well tested and supported ? You should ask for help its maintainer first. Clue : the pull_func() shall handle EINTR and EAGAIN. Michel From nmav at gnutls.org Sun Feb 15 22:33:05 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Feb 2015 22:33:05 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake In-Reply-To: References: Message-ID: <1424035985.13878.1.camel@gnutls.org> On Sun, 2015-02-15 at 19:06 +0100, Alessandro Carminati wrote: > Hello, > > thank you for answered my help request. > > The following is the iksemel function handshake where I issue is > spawned. > > static int handshake (struct stream_data *data) > { > const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, > 0 }; > const int kx_priority[] = { GNUTLS_KX_RSA, 0 }; > const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC, > GNUTLS_CIPHER_ARCFOUR, 0}; > const int comp_priority[] = { GNUTLS_COMP_ZLIB, > GNUTLS_COMP_NULL, 0 }; > const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, No doubt this doesn't work any more. It's a very old gnutls API, and these settings disable anything "new" like AES, and also disables forward secrecy. It is very likely that the selected combination of ciphers is considered insecure by the server. The best would be to convert this code to use the recommended way to set ciphers, i.e., call: gnutls_set_default_priority(session); As in: http://www.gnutls.org/manual/gnutls.html#Simple-client-example-with-X_002e509-certificate-support regards, Nikos From alessandro.carminati at gmail.com Sun Feb 15 22:33:24 2015 From: alessandro.carminati at gmail.com (Alessandro Carminati) Date: Sun, 15 Feb 2015 22:33:24 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake Message-ID: First function handshake is indeed a part of the xmpp parser iksemel library. But the next two function _gnutls_stream_read and pull_func are part of gnutls. iksemel seems some how unmanteined, and I'm not asking gnutls-help to deal with it. I just included it to show that when the iksemel invokes gnutls it spawn an error. I'd like someone could help me understand why when the iksemel handshake invokes the gnutls_handshake it returns GNUTLS_E_PULL_ERROR. Or to say it better, what this error means. Looking through the functions gnutls_handshake -> _gnutls_stream_read -> pull_func, I understood, if I'm not wrong, that the pull_func may fail returning EAGAIN, EINTR, or something else. [...] i = pull_func(fd, &ptr[size - left], left); if (i < 0) { int err = get_errno(session); [...] if (err == EAGAIN || err == EINTR) { [...] It seems to me that in my situation, it fails in latter scenario. My problem is that I can't figure out what this means. Any help would be appreciated. Alessandro Carminati -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Sun Feb 15 22:54:13 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Feb 2015 22:54:13 +0100 Subject: [gnutls-help] GNUTLS_E_PULL_ERROR in gnutls_handshake In-Reply-To: References: <1424035985.13878.1.camel@gnutls.org> Message-ID: <1424037253.13878.3.camel@gnutls.org> On Sun, 2015-02-15 at 22:42 +0100, Alessandro Carminati wrote: > It seems to me that this will result in an hard work. At least for me. > This was the answer I was looking for. Hi, Whether it is the answer you were looking for or not, this is the answer to your question. The code is outdated and that's the reason it fails to connect to the server. As far as I understand from your description the server is terminating the connection during handshake (the GNUTLS_E_PULL_ERROR), and the reason is most likely the outdated parameters the client sends. You can simulate your client with gnutls-cli and verify that with your server. Nevertheless, I don't see where is the hard work in using the new API. regards, Nikos From aperry at snowmoose.com Wed Feb 18 19:31:08 2015 From: aperry at snowmoose.com (Alan Perry) Date: Wed, 18 Feb 2015 10:31:08 -0800 Subject: [gnutls-help] GnuTLS and Nettle Message-ID: <54E4DA6C.50701@snowmoose.com> Hi, I have heard that GnuTLS will be using Nettle 3.x in the future. Any idea when might this happen? alan From alanp at snowmoose.com Wed Feb 18 22:00:23 2015 From: alanp at snowmoose.com (Alan Perry) Date: Wed, 18 Feb 2015 13:00:23 -0800 Subject: [gnutls-help] GMP version for GnuTLS Message-ID: <54E4FD67.502@snowmoose.com> Does GnuTLS 3.[234].x have a dependency on any particular version(s) of GMP? alan From nmav at gnutls.org Wed Feb 18 22:46:57 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Feb 2015 22:46:57 +0100 Subject: [gnutls-help] GnuTLS and Nettle In-Reply-To: <54E4DA6C.50701@snowmoose.com> References: <54E4DA6C.50701@snowmoose.com> Message-ID: <1424296017.3853.3.camel@gnutls.org> On Wed, 2015-02-18 at 10:31 -0800, Alan Perry wrote: > Hi, > > I have heard that GnuTLS will be using Nettle 3.x in the future. Any > idea when might this happen? My plan is to release gnutls 3.4.0 once nettle 3.1 is out, and it will depend on it. As far as I understand nettle 3.1 should be out soon. regards, Nikos From nmav at gnutls.org Wed Feb 18 22:47:45 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Feb 2015 22:47:45 +0100 Subject: [gnutls-help] GMP version for GnuTLS In-Reply-To: <54E4FD67.502@snowmoose.com> References: <54E4FD67.502@snowmoose.com> Message-ID: <1424296065.3853.4.camel@gnutls.org> On Wed, 2015-02-18 at 13:00 -0800, Alan Perry wrote: > Does GnuTLS 3.[234].x have a dependency on any particular version(s) of GMP? No. Gnutls' usage of gmp is very basic. We just depend on whichever version nettle depends on. regards, Nikos From alanp at snowmoose.com Wed Feb 18 23:08:15 2015 From: alanp at snowmoose.com (Alan Perry) Date: Wed, 18 Feb 2015 14:08:15 -0800 Subject: [gnutls-help] GnuTLS and Nettle In-Reply-To: <1424296017.3853.3.camel@gnutls.org> References: <54E4DA6C.50701@snowmoose.com> <1424296017.3853.3.camel@gnutls.org> Message-ID: Thanks (for this and the GMP answer). alan > On Feb 18, 2015, at 1:46 PM, Nikos Mavrogiannopoulos wrote: > >> On Wed, 2015-02-18 at 10:31 -0800, Alan Perry wrote: >> Hi, >> >> I have heard that GnuTLS will be using Nettle 3.x in the future. Any >> idea when might this happen? > > My plan is to release gnutls 3.4.0 once nettle 3.1 is out, and it will > depend on it. As far as I understand nettle 3.1 should be out soon. > > regards, > Nikos > > > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From jonetsu at teksavvy.com Thu Feb 19 11:18:14 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Thu, 19 Feb 2015 05:18:14 -0500 Subject: [gnutls-help] FIPS and conditional tests Message-ID: <20150219051814.25517478@mevla> Hello, In FIPS mode, will Gnu TLS perform the so-called conditional tests automatically before each algorithm use ? Is there a 'continuous' DRBG test in FIPS mode ? Regards. From nmav at gnutls.org Fri Feb 20 10:02:36 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Feb 2015 10:02:36 +0100 Subject: [gnutls-help] FIPS and conditional tests In-Reply-To: <20150219051814.25517478@mevla> References: <20150219051814.25517478@mevla> Message-ID: On Thu, Feb 19, 2015 at 11:18 AM, jonetsu at teksavvy.com wrote: > Hello, > In FIPS mode, will Gnu TLS perform the so-called conditional tests > automatically before each algorithm use ? Which tests do you refer to? In FIPS mode you test the algorithms on library initialization not before each algorithm use. > Is there a 'continuous' > DRBG test in FIPS mode ? Yes. That's very easy to verify in the source code. regards, Nikos From mattroisang at gmail.com Fri Feb 20 21:56:56 2015 From: mattroisang at gmail.com (Mat Troi) Date: Fri, 20 Feb 2015 12:56:56 -0800 Subject: [gnutls-help] GnuTLS Self-Test Question Message-ID: Hi, I am trying to run GnuTLS and I have 6 errors: Hostname correctly matches (1) Hostname correctly matches (1) Hostname correctly matches (1) Hostname correctly does not match (0) Self test `./hostname-check' finished with 1 errors FAIL: hostname-check .... .... Adding CA certificate...done CA Certificate: subject `O=#130b43416365727420496e632e,OU=#1315687474703a2f2f7777772e4341636572742e6f7267,CN=#131343416365727420436c617373203320526f6f74', issuer `O=#1307526f6f74204341,OU=#1315687474703a2f2f7777772e6361636572742e6f7267,CN=#131943412043657274205369676e696e6720417574686f72697479,EMAIL=#1612737570706f7274406361636572742e6f7267', RSA key 4096 bits, signed using RSA-MD5 (broken!), activated `2005-10-14 07:36:55 UTC', expires `2033-03-28 07:36:55 UTC', SHA-1 fingerprint `db4c4269073fe9c2a37d890a5c1b18c4184e2a2d' Verifying...(null): verify_status: 1026 expected: 0 Cleanup...done Exit status.. FAIL: chainverify .... .... crq_key_id |<2>| ASSERT: /builds/adlai/userland-gnutls/components/gnutls/gnutls-2.8.6/lib/x509/crq.c:2343 Key[RSA] generation ok: 0 Key ids are identical. OK. Key[DSA] generation ok: 0 Key ids are identical. OK. Self test `./crq_key_id' finished with 4 errors FAIL: crq_key_id gnutls_x509_privkey_sign_hash gnutls_x509_crt_get_verify_algorithm loop 0 loop 1 Self test `./x509sign-verify' finished with 2 errors FAIL: x509sign-verify ... ... client: Handshake failed GNUTLS ERROR: A TLS packet with unexpected length was received. server: ready. Listening to port '5556'. Self test `./x509self' finished with 1 errors server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 37430 Self test `./x509self' finished with 1 errors FAIL: x509self .... .... client: Handshake failed GNUTLS ERROR: A TLS packet with unexpected length was received. server: ready. Listening to port '5556'. Self test `./x509dn' finished with 1 errors server: client failed with exit status 1 server: ready. Listening to port '5556'. Launched, generating DH parameters... server: connection from 127.0.0.1, port 46399 Self test `./x509dn' finished with 2 errors FAIL: x509dn This is for running self test 2.8.6 gnuTLS. Has anyone seen this problem or know how to solve? Thanks, Mat Troi -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosslagerwall at gmail.com Tue Feb 24 00:55:01 2015 From: rosslagerwall at gmail.com (Ross Lagerwall) Date: Mon, 23 Feb 2015 23:55:01 +0000 Subject: [gnutls-help] Repeated session resumption with TLS tickets Message-ID: <20150223235501.GA21081@hobo.lan> Hi, glib-networking (which uses gnutls) has a session cache such that after a connection handshake completes, it uses gnutls_session_get_data2 to retrieve and keep the session data. When another connection begins, it uses gnutls_session_set_data to reuse the data. However, this does not work properly with TLS tickets. After a session is resumed, the TLS tickets get stored in "resumed session data" which is not subsequently packed into the TLS session data again. Because of this, the third connection to a particular server is not properly resumed because the session data is missing the TLS tickets. I can change the code to only cache the session data if the session was not resumed, but I'd like to know if this is the correct thing to do or if gnutls should instead always store the TLS tickets in the session data? Thanks for your help :-) -- Ross Lagerwall From nmav at gnutls.org Tue Feb 24 10:26:04 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 24 Feb 2015 10:26:04 +0100 Subject: [gnutls-help] Repeated session resumption with TLS tickets In-Reply-To: <20150223235501.GA21081@hobo.lan> References: <20150223235501.GA21081@hobo.lan> Message-ID: On Tue, Feb 24, 2015 at 12:55 AM, Ross Lagerwall wrote: > Hi, > glib-networking (which uses gnutls) has a session cache such that after > a connection handshake completes, it uses gnutls_session_get_data2 to > retrieve and keep the session data. When another connection begins, it > uses gnutls_session_set_data to reuse the data. > However, this does not work properly with TLS tickets. After a session is > resumed, the TLS tickets get stored in "resumed session data" which is > not subsequently packed into the TLS session data again. Because of > this, the third connection to a particular server is not properly resumed > because the session data is missing the TLS tickets. > I can change the code to only cache the session data if the session was > not resumed, but I'd like to know if this is the correct thing to do or > if gnutls should instead always store the TLS tickets in the session > data? This was the intention. The data should be saved when in non-resumed sessions only. I'll try to make that clean in the documentation, if you have any suggestions on that matter, they are welcome. regards, Nikos From rosslagerwall at gmail.com Tue Feb 24 10:30:41 2015 From: rosslagerwall at gmail.com (Ross Lagerwall) Date: Tue, 24 Feb 2015 09:30:41 +0000 Subject: [gnutls-help] Repeated session resumption with TLS tickets In-Reply-To: References: <20150223235501.GA21081@hobo.lan> Message-ID: On Tue, Feb 24, 2015 at 9:26 AM, Nikos Mavrogiannopoulos wrote: > On Tue, Feb 24, 2015 at 12:55 AM, Ross Lagerwall > wrote: >> Hi, >> glib-networking (which uses gnutls) has a session cache such that after >> a connection handshake completes, it uses gnutls_session_get_data2 to >> retrieve and keep the session data. When another connection begins, it >> uses gnutls_session_set_data to reuse the data. >> However, this does not work properly with TLS tickets. After a session is >> resumed, the TLS tickets get stored in "resumed session data" which is >> not subsequently packed into the TLS session data again. Because of >> this, the third connection to a particular server is not properly resumed >> because the session data is missing the TLS tickets. >> I can change the code to only cache the session data if the session was >> not resumed, but I'd like to know if this is the correct thing to do or >> if gnutls should instead always store the TLS tickets in the session >> data? > > This was the intention. The data should be saved when in non-resumed > sessions only. I'll try to make that clean in the documentation, if > you have any suggestions on that matter, they are welcome. > Thanks for clearing that up. I would suggest something like: "gnutls_session_get_data2 should be used to cache session data only when a session is created, i.e. when gnutls_session_is_resumed returns false." From jonetsu at teksavvy.com Wed Feb 25 03:45:46 2015 From: jonetsu at teksavvy.com (jonetsu at teksavvy.com) Date: Tue, 24 Feb 2015 21:45:46 -0500 Subject: [gnutls-help] FIPS and conditional tests In-Reply-To: References: <20150219051814.25517478@mevla> Message-ID: <20150224214546.71674836@mevla> On Fri, 20 Feb 2015 10:02:36 +0100 Nikos Mavrogiannopoulos wrote: > On Thu, Feb 19, 2015 at 11:18 AM, jonetsu at teksavvy.com > wrote: > > Hello, > > In FIPS mode, will Gnu TLS perform the so-called conditional tests > > automatically before each algorithm use ? > > Which tests do you refer to? In FIPS mode you test the algorithms on > library initialization not before each algorithm use. There must be pairwise consistency test on each generation of a key pair. These are also known as conditional tests. Does GnuTLs perform these ? Thanks. From nmav at gnutls.org Wed Feb 25 22:57:46 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Feb 2015 22:57:46 +0100 Subject: [gnutls-help] gnutls 3.3.13 Message-ID: <1424901466.2020.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.13. This is a bug-fix release on the current stable branch. Among other issues it adds a certificate algorithm consistency check in X.509 certificates. That's is a low severity issue affecting all previous versions, and although there no known attacks, it is recommended to upgrade to this version. * Version 3.3.13 (released 2015-02-25) ** libgnutls: Enable AESNI in GCM on x86 ** libgnutls: Fixes in DTLS message handling ** libgnutls: Check certificate algorithm consistency, i.e., check whether the signatureAlgorithm field matches the signature field inside TBSCertificate. ** gnutls-cli: Fixes in OCSP verification. ** 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.13.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.13.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 nhrdls at gmail.com Fri Feb 27 21:43:14 2015 From: nhrdls at gmail.com (Niranjan Rao) Date: Fri, 27 Feb 2015 12:43:14 -0800 Subject: [gnutls-help] Connection failing to a site Message-ID: <54F0D6E2.5040005@gmail.com> Greetings, On Ubuntu 12.04. When trying to connect to site www.uasecho.com using webkit, I get error SSL handshake failed. I tried running gnutls-cli and get following output. gnutls-cli -V www.uasecho.com Resolving 'www.uasecho.com'... Connecting to '198.27.57.107:443'... *** Fatal error: A TLS packet with unexpected length was received. *** Handshake has failed GnuTLS error: A TLS packet with unexpected length was received. Version Info: $gnutls-cli -v gnutls-cli (GnuTLS) 2.12.14 Packaged by Debian (2.12.14-5ubuntu3.8) Is there anything I can do to resolve this error? Regards, Niranjan From nmav at gnutls.org Sat Feb 28 08:31:02 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 28 Feb 2015 08:31:02 +0100 Subject: [gnutls-help] Connection failing to a site In-Reply-To: <54F0D6E2.5040005@gmail.com> References: <54F0D6E2.5040005@gmail.com> Message-ID: <1425108662.2087.0.camel@gnutls.org> On Fri, 2015-02-27 at 12:43 -0800, Niranjan Rao wrote: > Greetings, > > On Ubuntu 12.04. > > When trying to connect to site www.uasecho.com using webkit, I get error > SSL handshake failed. I tried running gnutls-cli and get following output. > > gnutls-cli -V www.uasecho.com > Resolving 'www.uasecho.com'... > Connecting to '198.27.57.107:443'... > *** Fatal error: A TLS packet with unexpected length was received. > *** Handshake has failed > GnuTLS error: A TLS packet with unexpected length was received. There is something with the server. It works if you disable TLS 1.2. However, the best it to use a supported version of gnutls: http://www.gnutls.org/download.html regards, Nikos