From nmav at gnutls.org Thu Dec 1 08:41:54 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 1 Dec 2016 08:41:54 +0100 Subject: [gnutls-devel] Wrong return value from gnutls_x509_crl_verify In-Reply-To: <1142791462.69621.1480534020474.JavaMail.zimbra@savoirfairelinux.com> References: <1142791462.69621.1480534020474.JavaMail.zimbra@savoirfairelinux.com> Message-ID: Nice catch Adrien. However, given that this is a quite old function I think it may be better to also document the old behavior as well. I have submitted a merge request at: https://gitlab.com/gnutls/gnutls/merge_requests/166 regards, Nikos On Wed, Nov 30, 2016 at 8:27 PM, Adrien B?raud wrote: > While using gnutls_x509_crl_verify I noticed it returned 1 for a valid CRL. > The documentation only mention 0 on success and a negative code on failure. > > It turned out the value comes from > _gnutls_x509_verify_data > which takes its value from > pubkey_verify_data > which returns 1 on success. > > Attached is a patch to fix the issue. > > best regards, > Adrien B?raud > Savoir-faire Linux > > diff --git a/lib/x509/verify.c b/lib/x509/verify.c > index ecd2369..d4966d0 100644 > --- a/lib/x509/verify.c > +++ b/lib/x509/verify.c > @@ -1477,13 +1477,13 @@ gnutls_x509_crl_verify(gnutls_x509_crl_t crl, > /* error. ignore it */ > if (verify) > *verify |= GNUTLS_CERT_SIGNATURE_FAILURE; > - result = 0; > } else if (result < 0) { > gnutls_assert(); > if (verify) > *verify |= GNUTLS_CERT_INVALID; > goto cleanup; > } > + result = 0; > } > > { > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From James.Bottomley at HansenPartnership.com Sat Dec 3 00:28:08 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 02 Dec 2016 15:28:08 -0800 Subject: [gnutls-devel] [PATCH] Fix inability to find libtspi (trousers) on openSUSE Message-ID: <1480721288.2944.4.camel@HansenPartnership.com> For distro reasons, the path on openSUSE is /lib[64]/libtspi.so.1 which the current code doesn't find. Fix this by having it search all viable system library locations (/lib /lib64 /usr/lib and /usr/lib/lib64) Signed-off-by: James Bottomley --- configure.ac | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/configure.ac b/configure.ac index 954829e..0be0818 100644 --- a/configure.ac +++ b/configure.ac @@ -643,16 +643,24 @@ fi AM_CONDITIONAL(ENABLE_TROUSERS, test "$with_tpm" != "no") -if test -f "/usr/lib64/libtspi.so.1";then -default_trousers_lib="/usr/lib64/libtspi.so.1" -else -default_trousers_lib="/usr/lib/libtspi.so.1" -fi +for l in /usr/lib /usr/lib64 /lib /lib64; do + if test -f "${l}/libtspi.so.1";then + default_trousers_lib="${l}/libtspi.so.1" + fi +done AC_ARG_WITH(trousers-lib, AS_HELP_STRING([--with-trousers-lib=LIB], [set the location of the trousers library]), ac_trousers_lib=$withval, ac_trousers_lib=$default_trousers_lib) +if test "$with_tpm" != "no" -a -z "$ac_trousers_lib"; then + AC_MSG_ERROR([[ + *** + *** unable to find trousers library, please specify with --with-trousers-lib= + *** + ]]) +fi + AC_DEFINE_UNQUOTED([TROUSERS_LIB], ["$ac_trousers_lib"], [the location of the trousers library]) AC_SUBST(TROUSERS_LIB) From ametzler at bebt.de Sat Dec 3 14:29:51 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 3 Dec 2016 14:29:51 +0100 Subject: [gnutls-devel] [patch] prevent unwanted linkage to -lhogweed Message-ID: <20161203132951.bvxrbupqknwo2cbo@argenau.bebt.de> Hello, I was wondering why the GnuTLS C++ and openssl wrapper libraries ended up being linked against -lhogweed iff --disable-libdane was specified. Found the reason. 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-Prevent-unwanted-linkage-to-lhogweed.patch Type: text/x-diff Size: 1143 bytes Desc: not available URL: From James.Bottomley at HansenPartnership.com Sat Dec 3 23:31:06 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 03 Dec 2016 14:31:06 -0800 Subject: [gnutls-devel] [PATCH 0/2] Fix TPM key handling Message-ID: <1480804266.2376.16.camel@HansenPartnership.com> It looks like TPM keys requiring authorization have never worked in gnutls, partly because of a coding error which is fixed in the first patch and partly because of an apparent misunderstanding about the way trousers works, which is fixed in the second. It's amusing to note that the concerns about the dictionary attack lockout in the second patch are real: I managed to lock up my own TPM while debugging the code and, thanks to Nuvoton, I discovered that the DA lockout survives clearing the TPM, meaning I was left with a TPM that was locked out but had no owner authority, meaning no viable way of resetting the DA lockout. Fortunately, it agreed to let me back in the next day. James --- James Bottomley (2): tpm: must clear pkey each time we go round the import loop tpm: fix handling of keys requiring authorization lib/tpm.c | 73 +++++++++++++++++++++++++++++++++++++++------------------------ 1 file changed, 45 insertions(+), 28 deletions(-) -- 2.6.6 From James.Bottomley at HansenPartnership.com Sat Dec 3 23:32:21 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 03 Dec 2016 14:32:21 -0800 Subject: [gnutls-devel] [PATCH 1/2] tpm: must clear pkey each time we go round the import loop In-Reply-To: <1480804266.2376.16.camel@HansenPartnership.com> References: <1480804266.2376.16.camel@HansenPartnership.com> Message-ID: <1480804341.2376.17.camel@HansenPartnership.com> There's a coding bug in the do .. while loop in import_tpm_key_cb() On entry, the pkey is initialised but blank (meaning set to zero), but as soon as import_tpm_key() is called, the pkey structure will become initialised. This means that the assert of an uninitialised pkey in gnutls_privkey_import_ext2() fails if we go around the loop again. Fix this by manually clearing the pkey on each loop. Signed-off-by: James Bottomley --- lib/tpm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/tpm.c b/lib/tpm.c index 23e4479..506019e 100644 --- a/lib/tpm.c +++ b/lib/tpm.c @@ -458,6 +458,7 @@ import_tpm_key_cb(gnutls_privkey_t pkey, const gnutls_datum_t * fdata, int ret, ret2; do { + memset(pkey, 0, sizeof(*pkey)); ret = import_tpm_key(pkey, fdata, format, uuid, storage, srk_password, key_password); -- 2.6.6 From James.Bottomley at HansenPartnership.com Sat Dec 3 23:36:40 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 03 Dec 2016 14:36:40 -0800 Subject: [gnutls-devel] [PATCH 2/2] tpm: fix handling of keys requiring authorization In-Reply-To: <1480804266.2376.16.camel@HansenPartnership.com> References: <1480804266.2376.16.camel@HansenPartnership.com> Message-ID: <1480804600.2376.19.camel@HansenPartnership.com> There are several problems with the key handling in the tpm code. The first, and most serious, is that we should make sure we understand the authorization requirements of a key *before* using it. The reason for this is that the TPM has a dictionary attack defence and is programmed to lock up after a certain number of authorization failures (which can be very small). If we try first without authorization, we may lock up the TPM. The fix for this is to check whether authorization is required and supply it before using the key. Secondly, if the key does require authorization but no password is supplied we should return immediately, since we know the TPM will give us an authorization error anyway. Thirdly, we should unconditionally read the policy of the key rather than checking if a policy exists: Policies are tied to key objects, so if there is an old policy in s->tpm_key_policy, but we're creating a new key, the key it belonged to will be closed, meaning the policy will be invalid. Fix this by always setting the policy each time we get a new key object. Signed-off-by: James Bottomley --- lib/tpm.c | 72 ++++++++++++++++++++++++++++++++++++++------------------------- 1 file changed, 44 insertions(+), 28 deletions(-) diff --git a/lib/tpm.c b/lib/tpm.c index 506019e..ebf8f01 100644 --- a/lib/tpm.c +++ b/lib/tpm.c @@ -71,6 +71,7 @@ typedef TSS_RESULT (*Tspi_DecodeBER_TssBlob_func)(UINT32, BYTE*, UINT32*, UINT32 typedef TSS_RESULT (*Tspi_Context_LoadKeyByBlob_func)(TSS_HCONTEXT, TSS_HKEY, UINT32, BYTE*, TSS_HKEY*); typedef TSS_RESULT (*Tspi_Policy_AssignToObject_func)(TSS_HPOLICY, TSS_HOBJECT); typedef TSS_RESULT (*Tspi_GetAttribData_func)(TSS_HOBJECT, TSS_FLAG, TSS_FLAG, UINT32*, BYTE**); +typedef TSS_RESULT (*Tspi_GetAttribUint32_func)(TSS_HOBJECT, TSS_FLAG, TSS_FLAG, UINT32*); typedef TSS_RESULT (*Tspi_Context_GetTpmObject_func)(TSS_HCONTEXT, TSS_HTPM*); typedef TSS_RESULT (*Tspi_TPM_StirRandom_func)(TSS_HTPM, UINT32, BYTE*); typedef TSS_RESULT (*Tspi_SetAttribUint32_func)(TSS_HOBJECT, TSS_FLAG, TSS_FLAG, UINT32); @@ -96,6 +97,7 @@ static Tspi_DecodeBER_TssBlob_func pTspi_DecodeBER_TssBlob; static Tspi_Context_LoadKeyByBlob_func pTspi_Context_LoadKeyByBlob; static Tspi_Policy_AssignToObject_func pTspi_Policy_AssignToObject; static Tspi_GetAttribData_func pTspi_GetAttribData; +static Tspi_GetAttribUint32_func pTspi_GetAttribUint32; static Tspi_Context_GetTpmObject_func pTspi_Context_GetTpmObject; static Tspi_TPM_StirRandom_func pTspi_TPM_StirRandom; static Tspi_SetAttribUint32_func pTspi_SetAttribUint32; @@ -144,6 +146,7 @@ static int check_init(void) _DLSYM(tpm_dl,Tspi_Context_LoadKeyByBlob); _DLSYM(tpm_dl,Tspi_Policy_AssignToObject); _DLSYM(tpm_dl,Tspi_GetAttribData); + _DLSYM(tpm_dl,Tspi_GetAttribUint32); _DLSYM(tpm_dl,Tspi_Context_GetTpmObject); _DLSYM(tpm_dl,Tspi_TPM_StirRandom); _DLSYM(tpm_dl,Tspi_SetAttribUint32); @@ -581,6 +584,7 @@ import_tpm_key(gnutls_privkey_t pkey, struct tpm_ctx_st *s; gnutls_datum_t tmp_sig; char *key_password = NULL; + uint32_t authusage; s = gnutls_malloc(sizeof(*s)); if (s == NULL) { @@ -630,39 +634,37 @@ import_tpm_key(gnutls_privkey_t pkey, goto out_session; } - ret = - gnutls_privkey_import_ext2(pkey, GNUTLS_PK_RSA, s, - tpm_sign_fn, NULL, tpm_deinit_fn, - 0); - if (ret < 0) { + err = pTspi_GetAttribUint32(s->tpm_key, TSS_TSPATTRIB_KEY_INFO, + TSS_TSPATTRIB_KEYINFO_AUTHUSAGE, + &authusage); + if (err) { gnutls_assert(); + ret = tss_err(err); goto out_session; } - ret = - gnutls_privkey_sign_data(pkey, GNUTLS_DIG_SHA1, 0, &nulldata, - &tmp_sig); - if (ret == GNUTLS_E_TPM_KEY_PASSWORD_ERROR) { - if (!s->tpm_key_policy) { - err = pTspi_Context_CreateObject(s->tpm_ctx, - TSS_OBJECT_TYPE_POLICY, - TSS_POLICY_USAGE, - &s-> - tpm_key_policy); - if (err) { - gnutls_assert(); - ret = tss_err(err); - goto out_key; - } + if (authusage) { + if (!_key_password) { + ret = GNUTLS_E_TPM_KEY_PASSWORD_ERROR; + goto out_session; + } + + err = pTspi_Context_CreateObject(s->tpm_ctx, + TSS_OBJECT_TYPE_POLICY, + TSS_POLICY_USAGE, + &s->tpm_key_policy); + if (err) { + gnutls_assert(); + ret = tss_err(err); + goto out_key; + } - err = - pTspi_Policy_AssignToObject(s->tpm_key_policy, + err = pTspi_Policy_AssignToObject(s->tpm_key_policy, s->tpm_key); - if (err) { - gnutls_assert(); - ret = tss_err(err); - goto out_key_policy; - } + if (err) { + gnutls_assert(); + ret = tss_err(err); + goto out_key_policy; } err = myTspi_Policy_SetSecret(s->tpm_key_policy, @@ -674,7 +676,21 @@ import_tpm_key(gnutls_privkey_t pkey, ret = tss_err_key(err); goto out_key_policy; } - } else if (ret < 0) { + } + + ret = + gnutls_privkey_import_ext2(pkey, GNUTLS_PK_RSA, s, + tpm_sign_fn, NULL, tpm_deinit_fn, + 0); + if (ret < 0) { + gnutls_assert(); + goto out_session; + } + + ret = + gnutls_privkey_sign_data(pkey, GNUTLS_DIG_SHA1, 0, &nulldata, + &tmp_sig); + if (ret < 0) { gnutls_assert(); goto out_session; } -- 2.6.6 From nmav at gnutls.org Sun Dec 4 09:37:55 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Dec 2016 09:37:55 +0100 Subject: [gnutls-devel] [PATCH] Fix inability to find libtspi (trousers) on openSUSE In-Reply-To: <1480721288.2944.4.camel@HansenPartnership.com> References: <1480721288.2944.4.camel@HansenPartnership.com> Message-ID: <1480840675.2175.0.camel@gnutls.org> On Fri, 2016-12-02 at 15:28 -0800, James Bottomley wrote: > For distro reasons, the path on openSUSE is /lib[64]/libtspi.so.1 > which the current code doesn't find.??Fix this by having it search > all > viable system library locations (/lib /lib64 /usr/lib and > /usr/lib/lib64) > Thank you. Applied. From nmav at gnutls.org Sun Dec 4 09:44:17 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Dec 2016 09:44:17 +0100 Subject: [gnutls-devel] [patch] prevent unwanted linkage to -lhogweed In-Reply-To: <20161203132951.bvxrbupqknwo2cbo@argenau.bebt.de> References: <20161203132951.bvxrbupqknwo2cbo@argenau.bebt.de> Message-ID: <1480841057.2175.2.camel@gnutls.org> On Sat, 2016-12-03 at 14:29 +0100, Andreas Metzler wrote: > Hello, > > I was wondering why the GnuTLS C++ and openssl wrapper libraries > ended > up being linked against -lhogweed iff --disable-libdane was > specified. > Found the reason. Thank you, applied. From nmav at gnutls.org Sun Dec 4 10:08:00 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 04 Dec 2016 10:08:00 +0100 Subject: [gnutls-devel] [PATCH 0/2] Fix TPM key handling In-Reply-To: <1480804266.2376.16.camel@HansenPartnership.com> References: <1480804266.2376.16.camel@HansenPartnership.com> Message-ID: <1480842480.2175.4.camel@gnutls.org> On Sat, 2016-12-03 at 14:31 -0800, James Bottomley wrote: > It looks like TPM keys requiring authorization have never worked in > gnutls, partly because of a coding error which is fixed in the first > patch and partly because of an apparent misunderstanding about the > way > trousers works, which is fixed in the second. > > It's amusing to note that the concerns about the dictionary attack > lockout in the second patch are real: I managed to lock up my own TPM > while debugging the code and, thanks to Nuvoton, I discovered that > the > DA lockout survives clearing the TPM, meaning I was left with a TPM > that was locked out but had no owner authority, meaning no viable way > of resetting the DA lockout.??Fortunately, it agreed to let me back > in > the next day. Thank you. I have applied a different fix on the first issue, i.e., to ensure that import_tpm_key clears the key on failure (while leaving any PIN info intact). The second I've applied as is. Note that I have not yet tested the fixes (unfortunately my test suite on TPM is manual, and since tpm-emulator no longer runs on modern systems testing of TPM functionality is not the easiest thing). I've put the changes on a merge request at: https://gitlab.com/gnutls/gnutls/merge_requests/171 regards, Nikos PS. If you know some mock tspi library, or have some idea testing TPM functionality without a real TPM, I'm really interested. That's a thing missing from our CI. From James.Bottomley at HansenPartnership.com Sun Dec 4 18:03:33 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 04 Dec 2016 09:03:33 -0800 Subject: [gnutls-devel] [PATCH 0/2] Fix TPM key handling In-Reply-To: <1480842480.2175.4.camel@gnutls.org> References: <1480804266.2376.16.camel@HansenPartnership.com> <1480842480.2175.4.camel@gnutls.org> Message-ID: <1480871013.2472.17.camel@HansenPartnership.com> On Sun, 2016-12-04 at 10:08 +0100, Nikos Mavrogiannopoulos wrote: > On Sat, 2016-12-03 at 14:31 -0800, James Bottomley wrote: > > It looks like TPM keys requiring authorization have never worked in > > gnutls, partly because of a coding error which is fixed in the > > first patch and partly because of an apparent misunderstanding > > about the way trousers works, which is fixed in the second. > > > > It's amusing to note that the concerns about the dictionary attack > > lockout in the second patch are real: I managed to lock up my own > > TPM while debugging the code and, thanks to Nuvoton, I discovered > > that the DA lockout survives clearing the TPM, meaning I was left > > with a TPM that was locked out but had no owner authority, meaning > > no viable way of resetting the DA lockout. Fortunately, it agreed > > to let me back in the next day. > > Thank you. I have applied a different fix on the first issue, i.e., > to ensure that import_tpm_key clears the key on failure (while > leaving any PIN info intact). The second I've applied as is. That's fine ... clearing the whole thing felt like a bit of a hack. > Note that I have not yet tested the fixes (unfortunately my test > suite on TPM is manual, and since tpm-emulator no longer runs on > modern systems testing of TPM functionality is not the easiest > thing). After my TPM lockout, I convinced myself I need to know how to make an emulated TPM work. It looks like there is a functional 1.2 one: https://github.com/stefanberger/libtpms But I need to figure out how to integrate it easily. I also need to find a 2.0 one .. > I've put the changes on a merge request at: > https://gitlab.com/gnutls/gnutls/merge_requests/171 Thanks. > regards, > Nikos > > PS. If you know some mock tspi library, or have some idea testing TPM > functionality without a real TPM, I'm really interested. That's a > thing missing from our CI. It's high up on my list of things to look at. James From nmav at gnutls.org Thu Dec 8 07:57:52 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Dec 2016 07:57:52 +0100 Subject: [gnutls-devel] gnutls 3.4.17 Message-ID: <1481180272.2177.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.4.17. This is a bug fix release of the current stable branch. * Version 3.4.17 (released 2016-12-8) ** libgnutls: Introduced time and constraints checks in the end certificate???in the gnutls_x509_crt_verify_data2() and gnutls_pkcs7_verify_direct()?functions. ** libgnutls: Set limits on the maximum number of alerts handled. That is,?applications using gnutls could be tricked into an busy loop if? the?peer sends continuously alert messages. Applications which set a maximum?handshake time (via gnutls_handshake_set_timeout) will eventually recover?but others may remain in a busy loops? indefinitely. This is related but?not identical to CVE-2016-8610, due to the difference in alert handling?of the libraries (gnutls delegates that handling to applications). ** libgnutls: Enhanced the PKCS#7 parser to allow decoding old ???(pre-rfc5652) structures with arbitrary encapsulated content. ** libgnutls: Backported cipher priorities order from 3.5.x branch. That?adds CHACHA20-POLY1305 ciphersuite to SECURE priority strings. ** certtool: When exporting a CRQ in DER format ensure no text data are ???intermixed. Patch by Dmitry Eremin-Solenikov. ** API and ABI modifications: gnutls_pkcs7_get_embedded_data_oid: 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.4/gnutls-3.4.17.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.17.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 Dec 8 08:04:07 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Dec 2016 08:04:07 +0100 Subject: [gnutls-devel] gnutls 3.5.7 Message-ID: <1481180647.2177.3.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.7. This is the last release in the 3.5.x branch introducing major changes. The next releases after 3.5.7 will be marked as stable and replace the 3.4.x branch. New features will enter at a new 3.6.x branch. * Version 3.5.7 (released 2016-12-8) ** libgnutls: Include CHACHA20-POLY1305 ciphersuites in the SECURE128 ???and SECURE256 priority strings. ** libgnutls: Require libtasn1 4.9; this ensures gnutls will correctly ???operate with OIDs which have elements that exceed 2^32. ** libgnutls: The DN decoding functions output the traditional DN format?rather than the strict RFC4514 compliant textual DN. This reverts the?3.5.6 introduced change, and allows applications which depended on the?previous format to continue to function. Introduced new functions which?output the strict format by default, and can revert to the old one using a flag. ** libgnutls: Improved TPM key handling. Check authorization? requirements?prior to using a key and fix issue on loop for PIN input. Patches by?James Bottomley. ** libgnutls: In all functions accepting UTF-8 passwords, ensure that ???passwords are normalized according to RFC7613. When invalid UTF-8 ???passwords are detected, they are only tolerated for decryption. ???This introduces a libunistring dependency on GnuTLS. A version of ???libunistring is included in the library for the platforms that do ???not ship it; it can be used with the '--with-included-unistring' ???option to configure script. ** libgnutls: When setting a subject alternative name in a certificate ???which is in UTF-8 format, it will transparently be converted to IDNA form?prior to storing. ** libgnutls: GNUTLS_CRT_PRINT_ONELINE flag on gnutls_x509_crt_print() ???will print the SHA256 key-ID instead of a certificate fingerprint. ** libgnutls: enhance the PKCS#7 verification capabilities. In the case ???signers that are not discoverable using the trust list or input, use ???the stored list as pool to generate a trusted chain to the signer. ** libgnutls: Improved MTU calculation precision for the CBC ciphersuites?under DTLS. ** libgnutls: [added missing news entry since 3.5.0] ???No longer tolerate certificate key usage violations for ???TLS signature verification, and decryption. That is GnuTLS will fail ???to connect to servers which incorrectly use a restricted to signing certificate?for decryption, or vice-versa. This reverts the lax behavior introduced?in 3.1.0, due to several such broken servers being available. The %COMPAT?priority keyword can be used to work- around connecting on these servers. ** certtool: When exporting a CRQ in DER format ensure no text data are ???intermixed. Patch by Dmitry Eremin-Solenikov. ** certtool: Include the SHA-256 variant of key ID in --certificate- info?options. ** p11tool: Introduced the --initialize-pin and --initialize-so-pin ???options. ** API and ABI modifications: gnutls_utf8_password_normalize: Added gnutls_ocsp_resp_get_responder2: Added gnutls_x509_crt_get_issuer_dn3: Added gnutls_x509_crt_get_dn3: Added gnutls_x509_rdn_get2: Added gnutls_x509_dn_get_str2: Added gnutls_x509_crl_get_issuer_dn3: Added gnutls_x509_crq_get_dn3: 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.7.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.7.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 alon.barlev at gmail.com Thu Dec 8 14:31:09 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 8 Dec 2016 15:31:09 +0200 Subject: [gnutls-devel] gnutls 3.5.7 fails tests without libidn Message-ID: On 8 December 2016 at 09:04, Nikos Mavrogiannopoulos wrote: > > ** libgnutls: When setting a subject alternative name in a certificate > which is in UTF-8 format, it will transparently be converted to IDNA > form prior to storing. Hi, I guess this because of the above change... only guessing as it is something in lib/str-unicode with libidn conditional, as tests fails without libidn available. I believe these should work to some extent also if libidn is not available, actually fail (not return invalid byte count), or at least skipped during tests. Thanks! Alon --- $ ./crq_apis out.size=814 saved_crq.size=818 crq_apis: /var/tmp/portage/net-libs/gnutls-3.5.7/work/gnutls-3.5.7/tests/crq_apis.c:452: doit: Assertion `out.size == saved_crq.size' failed. Aborted $ ./crt_apis doit:189: gnutls_x509_crt_set_subject_alt_name: An unimplemented or disabled feature has been requested., -1250 From nmav at gnutls.org Thu Dec 8 16:02:50 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 8 Dec 2016 16:02:50 +0100 Subject: [gnutls-devel] gnutls 3.5.7 fails tests without libidn In-Reply-To: References: Message-ID: Thanks for reporting that. The following two (untested) patches should address the issue: https://gitlab.com/gnutls/gnutls/commit/ddca30ed625d9f5f7efb628e4467ff7ab5a65701 https://gitlab.com/gnutls/gnutls/commit/e40393e5685743e185ea284337b6a0ed5d756a0f Note that compiling without libidn, enables broken functionality (i.e., allows the library to send invalid values over the net just because it cannot properly convert them). Is there a reason for using that option? regards, Nikos On Thu, Dec 8, 2016 at 2:31 PM, Alon Bar-Lev wrote: > On 8 December 2016 at 09:04, Nikos Mavrogiannopoulos wrote: >> >> ** libgnutls: When setting a subject alternative name in a certificate >> which is in UTF-8 format, it will transparently be converted to IDNA >> form prior to storing. > > Hi, > > I guess this because of the above change... only guessing as it is > something in lib/str-unicode with libidn conditional, as tests fails > without libidn available. > > I believe these should work to some extent also if libidn is not > available, actually fail (not return invalid byte count), or at least > skipped during tests. > > Thanks! > Alon > > --- > > $ ./crq_apis > out.size=814 saved_crq.size=818 > crq_apis: /var/tmp/portage/net-libs/gnutls-3.5.7/work/gnutls-3.5.7/tests/crq_apis.c:452: > doit: Assertion `out.size == saved_crq.size' failed. > Aborted > > $ ./crt_apis > doit:189: gnutls_x509_crt_set_subject_alt_name: An unimplemented or > disabled feature has been requested., -1250 From alon.barlev at gmail.com Thu Dec 8 16:37:10 2016 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Thu, 8 Dec 2016 17:37:10 +0200 Subject: [gnutls-devel] gnutls 3.5.7 fails tests without libidn In-Reply-To: References: Message-ID: On 8 December 2016 at 17:02, Nikos Mavrogiannopoulos wrote: > > Thanks for reporting that. The following two (untested) patches should > address the issue: > https://gitlab.com/gnutls/gnutls/commit/ddca30ed625d9f5f7efb628e4467ff7ab5a65701 > https://gitlab.com/gnutls/gnutls/commit/e40393e5685743e185ea284337b6a0ed5d756a0f Confirmed, thanks! > Note that compiling without libidn, enables broken functionality > (i.e., allows the library to send invalid values over the net just > because it cannot properly convert them). Is there a reason for using > that option? It is your decision actually :) Is libidn mandatory or optional for gnutls? Currently it is optional as far as I can see. > > regards, > Nikos > > On Thu, Dec 8, 2016 at 2:31 PM, Alon Bar-Lev wrote: > > On 8 December 2016 at 09:04, Nikos Mavrogiannopoulos wrote: > >> > >> ** libgnutls: When setting a subject alternative name in a certificate > >> which is in UTF-8 format, it will transparently be converted to IDNA > >> form prior to storing. > > > > Hi, > > > > I guess this because of the above change... only guessing as it is > > something in lib/str-unicode with libidn conditional, as tests fails > > without libidn available. > > > > I believe these should work to some extent also if libidn is not > > available, actually fail (not return invalid byte count), or at least > > skipped during tests. > > > > Thanks! > > Alon > > > > --- > > > > $ ./crq_apis > > out.size=814 saved_crq.size=818 > > crq_apis: /var/tmp/portage/net-libs/gnutls-3.5.7/work/gnutls-3.5.7/tests/crq_apis.c:452: > > doit: Assertion `out.size == saved_crq.size' failed. > > Aborted > > > > $ ./crt_apis > > doit:189: gnutls_x509_crt_set_subject_alt_name: An unimplemented or > > disabled feature has been requested., -1250 From tim.ruehsen at gmx.de Tue Dec 20 15:07:34 2016 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 20 Dec 2016 15:07:34 +0100 Subject: [gnutls-devel] gnutls_priority_set() with 'empty' priority argument Message-ID: <3437788.lNkCXYDjbZ@blitz-lx> Hi, Nikos, after your patch on the wget mailing list I checked wget2 code. In short: ########## static gnutls_priority_t _priority_cache; if (priorities) /* priority string from somewhere */ gnutls_priority_init(&_priority_cache, priorities, NULL); /* ... later ... */ gnutls_priority_set(session, _priority_cache); ########## So, by default we give an 'empty' gnutls_priority_t var to gnutls_priority_set(). Q: is that correct resp. is that the same as gnutls_set_default_priority(session) ? If not, should we call gnutls_priority_init(&_priority_cache, "NORMAL", NULL); when no 'priorities' string is given ? Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Dec 21 07:50:52 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Dec 2016 07:50:52 +0100 Subject: [gnutls-devel] gnutls_priority_set() with 'empty' priority argument In-Reply-To: <3437788.lNkCXYDjbZ@blitz-lx> References: <3437788.lNkCXYDjbZ@blitz-lx> Message-ID: On Tue, Dec 20, 2016 at 3:07 PM, Tim Ruehsen wrote: > Hi, > > Nikos, after your patch on the wget mailing list I checked wget2 code. > > In short: > ########## > static gnutls_priority_t > _priority_cache; > > if (priorities) /* priority string from somewhere */ > gnutls_priority_init(&_priority_cache, priorities, NULL); > > /* ... later ... */ > gnutls_priority_set(session, _priority_cache); > ########## > > So, by default we give an 'empty' gnutls_priority_t var to > gnutls_priority_set(). > > Q: is that correct resp. is that the same as > gnutls_set_default_priority(session) ? I don't think so. The behavior is most likely undefined. Do you check the error code of gnutls_priority_check()? > If not, should we call > gnutls_priority_init(&_priority_cache, "NORMAL", NULL); > when no 'priorities' string is given ? To simulate the set_default() you can call: gnutls_priority_init(&_priority_cache, NULL, NULL); I realized that this is not clearly documented. regards, Nikos From tim.ruehsen at gmx.de Wed Dec 21 12:46:37 2016 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 21 Dec 2016 12:46:37 +0100 Subject: [gnutls-devel] gnutls_priority_set() with 'empty' priority argument In-Reply-To: References: <3437788.lNkCXYDjbZ@blitz-lx> Message-ID: <2409661.RynRLmB0NF@blitz-lx> On Wednesday, December 21, 2016 7:50:52 AM CET Nikos Mavrogiannopoulos wrote: > On Tue, Dec 20, 2016 at 3:07 PM, Tim Ruehsen wrote: > > Hi, > > > > Nikos, after your patch on the wget mailing list I checked wget2 code. > > > > In short: > > ########## > > static gnutls_priority_t > > > > _priority_cache; > > > > if (priorities) /* priority string from somewhere */ > > > > gnutls_priority_init(&_priority_cache, priorities, NULL); > > > > /* ... later ... */ > > gnutls_priority_set(session, _priority_cache); > > ########## > > > > So, by default we give an 'empty' gnutls_priority_t var to > > gnutls_priority_set(). > > > > Q: is that correct resp. is that the same as > > gnutls_set_default_priority(session) ? > > I don't think so. The behavior is most likely undefined. Do you check > the error code of gnutls_priority_check()? (gnutls_priority_set) I didn't but do now, no error. > > If not, should we call > > > > gnutls_priority_init(&_priority_cache, "NORMAL", NULL); > > > > when no 'priorities' string is given ? > > To simulate the set_default() you can call: > gnutls_priority_init(&_priority_cache, NULL, NULL); I took a look into the GnuTLS source, NULL is mapped to "NORMAL". But this might change, depending on documentation. Thanks for your answer, changed to code in wget2 slightly. Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Wed Dec 21 13:57:11 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Dec 2016 13:57:11 +0100 Subject: [gnutls-devel] gnutls_priority_set() with 'empty' priority argument In-Reply-To: <2409661.RynRLmB0NF@blitz-lx> References: <3437788.lNkCXYDjbZ@blitz-lx> <2409661.RynRLmB0NF@blitz-lx> Message-ID: <1482325031.2761.1.camel@gnutls.org> On Wed, 2016-12-21 at 12:46 +0100, Tim Ruehsen wrote: > On Wednesday, December 21, 2016 7:50:52 AM CET Nikos > Mavrogiannopoulos wrote: > > On Tue, Dec 20, 2016 at 3:07 PM, Tim Ruehsen > > wrote: > > > Hi, > > > > > > Nikos, after your patch on the wget mailing list I checked wget2 > > > code. > > > > > > In short: > > > ########## > > > static gnutls_priority_t > > > > > > ????????_priority_cache; > > > > > > if (priorities) /* priority string from somewhere */ > > > > > > ????????gnutls_priority_init(&_priority_cache, priorities, NULL); > > > > > > /* ... later ... */ > > > gnutls_priority_set(session, _priority_cache); > > > ########## > > > > > > So, by default we give an 'empty' gnutls_priority_t var to > > > gnutls_priority_set(). > > > > > > Q: is that correct resp. is that the same as > > > gnutls_set_default_priority(session) ? > > > > I don't think so. The behavior is most likely undefined. Do you > > check > > the error code of gnutls_priority_check()? > > (gnutls_priority_set) I didn't but do now, no error. > > > > If not, should we call > > > > > > ????????gnutls_priority_init(&_priority_cache, "NORMAL", NULL); > > > > > > when no 'priorities' string is given ? > > > > To simulate the set_default() you can call: > > gnutls_priority_init(&_priority_cache, NULL, NULL); > > I took a look into the GnuTLS source, NULL is mapped to "NORMAL". > But this might change, depending on documentation. Right this is the default. In Fedora we patch that value to the system default (taken on run-time from system-priority-file). I've just added a configuration option to allow changing the default without patching the source: https://gitlab.com/gnutls/gnutls/merge_requests/198 regards, Nikos From James.Bottomley at HansenPartnership.com Fri Dec 23 19:06:03 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 23 Dec 2016 10:06:03 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys Message-ID: <1482516363.2501.34.camel@HansenPartnership.com> The reason this comes about is because we already have a standard form for TPM 1.2 keys here: http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm However, since I'm working on TPM2 enabling for openssl and gnutls, I need to come up with a new key format because TPM2 requires some extra parameters and the original TSS KEY BLOB, being a single ASN1_OCTET_STRING isn't expandable. As a digression, the extra parameters that TPM2 needs are: 1. A public key blob. ?In TPM12 the key complex was a joint public/private part. ?In TPM2, the public and private key structures have variable length and are supplied separately. 2. a boolean for emptyAuth. ?In TPM12 there's a way to tell if a structure has no authorization. ?In TPM2 there's no such thing as no authorization, but there's a conventional empty authorization to replace it but no way of querying whether any given key is using it, so we need to know explicitly whether to prompt for a password or not. 3. There are different forms a TPM private key could be in. ?One is symmetrically encrypted with a TPM private key, which makes it loadable, meaning it must be produced on the TPM itself and the other is asymmetrically encrypted meaning it can be produced away from the TPM but must be imported before being loaded. I think there's value in having a universal structure for the key representations, so I'm proposing an ASN1 representation that will work for both TPM1.2 and TPM2 keys. I'd also like it to be self describing, so I think we should use an OID as the initial parameter of the sequence. With that, I think the format that works is TPMKey ::= SEQUENCE { type OBJECT IDENTIFIER version [0] IMPLICIT INTEGER OPTIONAL emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL parent [2] IMPLICIT INTEGER OPTIONAL publicKey [3] IMPLICIT OCTET STRING OPTIONAL privateKey OCTET STRING } Where TPM12 keys would have a TPM12Key type and use no optional fields (meaning only privateKey) and TPM2 keys would have type TPM2LoadableKey or TPM2ImportableKey type and then make use of all the optional fields (except version). Version is there for future expansion, but is unused in the initial incarnation. I'm torn on where to get the OIDs from. Since this is a TPM key, it might make sense to use the TCG OID (2.23.133) and just add something they haven't already used, like 10 for key formats, or we could go with a pkcs OID (1.2.840.113549.1) If we can agree on this, we can update David's document and make it a formal RFC. Thoughts? James From James.Bottomley at HansenPartnership.com Fri Dec 23 21:22:35 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 23 Dec 2016 12:22:35 -0800 Subject: [gnutls-devel] [openssl-dev] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <20161223.211218.817856866219152234.levitte@openssl.org> References: <1482516363.2501.34.camel@HansenPartnership.com> <20161223.211218.817856866219152234.levitte@openssl.org> Message-ID: <1482524555.2501.59.camel@HansenPartnership.com> On Fri, 2016-12-23 at 21:12 +0100, Richard Levitte wrote: > In message <1482516363.2501.34.camel at HansenPartnership.com> on Fri, > 23 Dec 2016 10:06:03 -0800, James Bottomley < > James.Bottomley at HansenPartnership.com> said: > > James.Bottomley> The reason this comes about is because we already > have a standard form > James.Bottomley> for TPM 1.2 keys here: > James.Bottomley> > James.Bottomley> http://david.woodhou.se/draft-woodhouse-cert-best-pr > actice.html#ident-tpm > James.Bottomley> > James.Bottomley> However, since I'm working on TPM2 enabling for > openssl and gnutls, I > James.Bottomley> need to come up with a new key format because TPM2 > requires some extra > James.Bottomley> parameters and the original TSS KEY BLOB, being a > single > James.Bottomley> ASN1_OCTET_STRING isn't expandable. > James.Bottomley> > James.Bottomley> As a digression, the extra parameters that TPM2 > needs are: > James.Bottomley> > James.Bottomley> 1. A public key blob. In TPM12 the key complex > was a joint > James.Bottomley> public/private part. In TPM2, the public and > private key structures > James.Bottomley> have variable length and are supplied > separately. > James.Bottomley> 2. a boolean for emptyAuth. In TPM12 there's a > way to tell if a > James.Bottomley> structure has no authorization. In TPM2 > there's no such thing as no > James.Bottomley> authorization, but there's a conventional > empty authorization to > James.Bottomley> replace it but no way of querying whether any > given key is using it, > James.Bottomley> so we need to know explicitly whether to > prompt for a password or > James.Bottomley> not. > James.Bottomley> 3. There are different forms a TPM private key > could be in. One is > James.Bottomley> symmetrically encrypted with a TPM private > key, which makes it > James.Bottomley> loadable, meaning it must be produced on the > TPM itself and the > James.Bottomley> other is asymmetrically encrypted meaning it > can be produced away > James.Bottomley> from the TPM but must be imported before being > loaded. > James.Bottomley> > James.Bottomley> I think there's value in having a universal > structure for the key > James.Bottomley> representations, so I'm proposing an ASN1 > representation that will work > James.Bottomley> for both TPM1.2 and TPM2 keys. I'd also like it to > be self describing, > James.Bottomley> so I think we should use an OID as the initial > parameter of the > James.Bottomley> sequence. With that, I think the format that works > is > James.Bottomley> > James.Bottomley> TPMKey ::= SEQUENCE { > James.Bottomley> type OBJECT IDENTIFIER > James.Bottomley> version [0] IMPLICIT INTEGER OPTIONAL > James.Bottomley> emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL > James.Bottomley> parent [2] IMPLICIT INTEGER OPTIONAL > James.Bottomley> publicKey [3] IMPLICIT OCTET STRING > OPTIONAL > James.Bottomley> privateKey OCTET STRING > James.Bottomley> } > James.Bottomley> > James.Bottomley> Where TPM12 keys would have a TPM12Key type and use > no optional fields > James.Bottomley> (meaning only privateKey) and TPM2 keys would have > type TPM2LoadableKey > James.Bottomley> or TPM2ImportableKey type and then make use of all > the optional fields > James.Bottomley> (except version). > James.Bottomley> > James.Bottomley> Version is there for future expansion, but is unused > in the initial > James.Bottomley> incarnation. > James.Bottomley> > James.Bottomley> I'm torn on where to get the OIDs from. Since this > is a TPM key, it > James.Bottomley> might make sense to use the TCG OID (2.23.133) and > just add something > James.Bottomley> they haven't already used, like 10 for key formats, > or we could go with > James.Bottomley> a pkcs OID (1.2.840.113549.1) > James.Bottomley> > James.Bottomley> If we can agree on this, we can update David's > document and make it a > James.Bottomley> formal RFC. > James.Bottomley> > James.Bottomley> Thoughts? > > First reaction is +1, at least for actually making a universally > parsable description. Thanks. After playing more I think I'd like to make the tags explicit rather than implicit so I can see the contents easily with asn1parse (and we're not in any way pressed for space, which is the usual reason for implicit tags). > One detail that escapes me, though, is why you don't use version for, > well, TPM versions? So, something like this? > > TCG OBJECT IDENTIFIER ::= > { joint-iso-itu-t(2) international-organizations(23) TCG(133) > } Because what OID to use is part of the discussion. Perhaps I wasn't clear about what I want: the OID needs to identify what the structure describes, so one OID for each of the three key types, so it would have a prefix either in the TCG or pkcs space (or something else if that's what we agree), then three OID postfixes. > TPMKey ::= SEQUENCE { > type OBJECT IDENTIFIER -- always TCG > version [0] INTEGER { v1_2(0), v2(1) } DEFAULT v1_2 Version, I'm envisaging is for expansion of the structure in a compatible way. For TPM2 keys, I think we're going to need additional policy descriptors eventually when people start using a policy to authorise instead of an authorisation value. We'd use the version number to indicate a future expanded structure. So the OID identifies the object structure and version is for versioning the actual structure. James > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL -- v2 only > parent [2] IMPLICIT INTEGER OPTIONAL -- v2 only > publicKey [3] IMPLICIT OCTET STRING OPTIONAL -- v2 only > privateKey OCTET STRING > } > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > From nmav at gnutls.org Sat Dec 24 14:25:00 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 Dec 2016 14:25:00 +0100 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <1482516363.2501.34.camel@HansenPartnership.com> References: <1482516363.2501.34.camel@HansenPartnership.com> Message-ID: On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley wrote: > The reason this comes about is because we already have a standard form > for TPM 1.2 keys here: > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ident-tpm > However, since I'm working on TPM2 enabling for openssl and gnutls, I > need to come up with a new key format because TPM2 requires some extra > parameters and the original TSS KEY BLOB, being a single > ASN1_OCTET_STRING isn't expandable. [...] > I'm torn on where to get the OIDs from. Since this is a TPM key, it > might make sense to use the TCG OID (2.23.133) and just add something > they haven't already used, like 10 for key formats, or we could go with > a pkcs OID (1.2.840.113549.1) OIDs under some umbrella normally need to be registered within the organization they belong to. If you cannot find a suitable organization to get these OIDs from I'll check whether we can get something under redhat's OIDs. > If we can agree on this, we can update David's document and make it a > formal RFC. Shouldn't version be first? However, I'm not sure how expandable is ASN.1 using version fields (I've seen no structure being able to be re-used using a different version). An alternative approach would to allow for future extensions, i.e., something like the PKIX Extension field, which is an OID+data. regards, Nikos From James.Bottomley at HansenPartnership.com Sat Dec 24 17:13:50 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 24 Dec 2016 08:13:50 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: References: <1482516363.2501.34.camel@HansenPartnership.com> Message-ID: <1482596030.2316.4.camel@HansenPartnership.com> On Sat, 2016-12-24 at 14:25 +0100, Nikos Mavrogiannopoulos wrote: > On Fri, Dec 23, 2016 at 7:06 PM, James Bottomley > wrote: > > The reason this comes about is because we already have a standard > > form for TPM 1.2 keys here: > > http://david.woodhou.se/draft-woodhouse-cert-best-practice.html#ide > > nt-tpm > > However, since I'm working on TPM2 enabling for openssl and gnutls, > > I need to come up with a new key format because TPM2 requires some > > extra parameters and the original TSS KEY BLOB, being a single > > ASN1_OCTET_STRING isn't expandable. > [...] > > I'm torn on where to get the OIDs from. Since this is a TPM key, > > it might make sense to use the TCG OID (2.23.133) and just add > > something they haven't already used, like 10 for key formats, or we > > could go with a pkcs OID (1.2.840.113549.1) > > OIDs under some umbrella normally need to be registered within the > organization they belong to. If you cannot find a suitable > organization to get these OIDs from I'll check whether we can get > something under redhat's OIDs. I think, since it's a key format, the two above are the potential ones. It would be TCG if they want to take it into their standard, otherwise PKCS is RSA Inc. > > If we can agree on this, we can update David's document and make it > > a formal RFC. > > Shouldn't version be first? I put OID first because that's what makes the structure self describing. You simply need to look for the SEQUENCE OBJECT OID prefix. We can easily register our own, of course as well. If version goes first, you have a variable prefix. > However, I'm not sure how expandable is ASN.1 using version fields > (I've seen no structure being able to be re-used using a different > version). An alternative approach would to allow for future > extensions, i.e., something like the PKIX Extension field, which is > an OID+data. As long as the expansion fields are optional, it works nicely. X509 and X509v3 are examples of version expanded ASN.1 James From nmav at gnutls.org Sun Dec 25 10:18:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Dec 2016 10:18:29 +0100 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <1482596030.2316.4.camel@HansenPartnership.com> References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> Message-ID: On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley wrote: > I think, since it's a key format, the two above are the potential ones. > It would be TCG if they want to take it into their standard, otherwise > PKCS is RSA Inc. I wouldn't expect RSA inc to be involved into this as part of PKCS. They are dead long time ago and have moved to IETF. >> However, I'm not sure how expandable is ASN.1 using version fields >> (I've seen no structure being able to be re-used using a different >> version). An alternative approach would to allow for future >> extensions, i.e., something like the PKIX Extension field, which is >> an OID+data. > > As long as the expansion fields are optional, it works nicely. X509 > and X509v3 are examples of version expanded ASN.1 Only if they are defined in the structure early. Otherwise the early versions of the implementations wouldn't cope with extensions. To make it early extendable you'd have to use something lilke TPMKey ::= SEQUENCE { type OBJECT IDENTIFIER version [0] IMPLICIT INTEGER OPTIONAL emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL parent [2] IMPLICIT INTEGER OPTIONAL publicKey [3] IMPLICIT OCTET STRING OPTIONAL privateKey OCTET STRING extensions [4] EXPLICIT Extensions OPTIONAL } regards, Nikos From James.Bottomley at HansenPartnership.com Sun Dec 25 19:44:51 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 25 Dec 2016 10:44:51 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> Message-ID: <1482691491.3394.8.camel@HansenPartnership.com> On Sun, 2016-12-25 at 10:18 +0100, Nikos Mavrogiannopoulos wrote: > On Sat, Dec 24, 2016 at 5:13 PM, James Bottomley > wrote: > > > I think, since it's a key format, the two above are the potential > > ones. It would be TCG if they want to take it into their standard, > > otherwise PKCS is RSA Inc. > > I wouldn't expect RSA inc to be involved into this as part of PKCS. > They are dead long time ago and have moved to IETF. I think I should give TCG first crack at wanting to own the OID. The IETF ones are easy: once you codify it in an RFC, the oid registry auto extracts it. > > > However, I'm not sure how expandable is ASN.1 using version > > > fields (I've seen no structure being able to be re-used using a > > > different version). An alternative approach would to allow for > > > future extensions, i.e., something like the PKIX Extension field, > > > which is an OID+data. > > > > As long as the expansion fields are optional, it works nicely. > > X509 and X509v3 are examples of version expanded ASN.1 > > Only if they are defined in the structure early. Otherwise the early > versions of the implementations wouldn't cope with extensions. To > make it early extendable you'd have to use something lilke > > TPMKey ::= SEQUENCE { > type OBJECT IDENTIFIER > version [0] IMPLICIT INTEGER OPTIONAL > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL > parent [2] IMPLICIT INTEGER OPTIONAL > publicKey [3] IMPLICIT OCTET STRING OPTIONAL > privateKey OCTET STRING > extensions [4] EXPLICIT Extensions OPTIONAL > } Actually, that's the utility of ASN.1, once you use tagging, you don't have to do this. The structure above is identical to: TPMKey ::= SEQUENCE { type OBJECT IDENTIFIER version [0] IMPLICIT INTEGER OPTIONAL emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL parent [2] IMPLICIT INTEGER OPTIONAL publicKey [3] IMPLICIT OCTET STRING OPTIONAL privateKey OCTET STRING } If tag 4 isn't present because optional tags are not coded when not present, so you can expand any ASN.1 structure as long as you have a clue from the version number that you should be looking for the optional extras. The point being I don't have to specify the expansion now, I can wait until we need it. I'm pretty certain the next expansion is actually SEQUENCE OF TPM2Policy but I'm still playing with the format. James From nmav at gnutls.org Sun Dec 25 22:08:44 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 25 Dec 2016 22:08:44 +0100 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <1482691491.3394.8.camel@HansenPartnership.com> References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> Message-ID: On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley wrote: >> TPMKey ::= SEQUENCE { >> type OBJECT IDENTIFIER >> version [0] IMPLICIT INTEGER OPTIONAL >> emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL >> parent [2] IMPLICIT INTEGER OPTIONAL >> publicKey [3] IMPLICIT OCTET STRING OPTIONAL >> privateKey OCTET STRING >> extensions [4] EXPLICIT Extensions OPTIONAL >> } > > Actually, that's the utility of ASN.1, once you use tagging, you don't > have to do this. The structure above is identical to: > > TPMKey ::= SEQUENCE { > type OBJECT IDENTIFIER > version [0] IMPLICIT INTEGER OPTIONAL > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL > parent [2] IMPLICIT INTEGER OPTIONAL > publicKey [3] IMPLICIT OCTET STRING OPTIONAL > privateKey OCTET STRING > } > > If tag 4 isn't present because optional tags are not coded when not > present, so you can expand any ASN.1 structure as long as you have a > clue from the version number that you should be looking for the > optional extras. The point being I don't have to specify the expansion > now, I can wait until we need it. How would that work for example if you want to add an additional field with information on the type of the key for example (key usage)? You would add the tag 4 as you say, and then all the previous parsers written with the initial description will fail parsing the new structure. X.509 (==PKIX) is only expandable via the extensions field which is already defined. If you add a field to it, no parser would be able to read the certificate. regards, Nikos From James.Bottomley at HansenPartnership.com Mon Dec 26 00:47:32 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sun, 25 Dec 2016 15:47:32 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> Message-ID: <1482709652.3394.15.camel@HansenPartnership.com> On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote: > On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley > wrote: > > > TPMKey ::= SEQUENCE { > > > type OBJECT IDENTIFIER > > > version [0] IMPLICIT INTEGER OPTIONAL > > > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL > > > parent [2] IMPLICIT INTEGER OPTIONAL > > > publicKey [3] IMPLICIT OCTET STRING OPTIONAL > > > privateKey OCTET STRING > > > extensions [4] EXPLICIT Extensions OPTIONAL > > > } > > > > Actually, that's the utility of ASN.1, once you use tagging, you > > don't have to do this. The structure above is identical to: > > > > TPMKey ::= SEQUENCE { > > type OBJECT IDENTIFIER > > version [0] IMPLICIT INTEGER OPTIONAL > > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL > > parent [2] IMPLICIT INTEGER OPTIONAL > > publicKey [3] IMPLICIT OCTET STRING OPTIONAL > > privateKey OCTET STRING > > } > > > > If tag 4 isn't present because optional tags are not coded when not > > present, so you can expand any ASN.1 structure as long as you have > > a clue from the version number that you should be looking for the > > optional extras. The point being I don't have to specify the > > expansion now, I can wait until we need it. > > How would that work for example if you want to add an additional > field with information on the type of the key for example (key > usage)? You would add the tag 4 as you say, and then all the previous > parsers written with the initial description will fail parsing the > new structure. X.509 (==PKIX) is only expandable via the extensions > field which is already defined. If you add a field to it, no parser > would be able to read the certificate. Um, well, you only want backwards compatibility, you don't really want forward compatibility. Assuming something extends the structure and adds version v2, why would it matter that an old v1 application can't read a v2 structure because it doesn't understand the tag 4? Even if it could it can't make use of the extra fields and something nasty will happen. What you want is that the new v2 application can parse both the v2 structure and the old v1 one, but it's advantageous that a v1 application fails with a v2 structure because it prevents cockups. James From n.mavrogiannopoulos at gmail.com Mon Dec 26 08:18:02 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogianopoulos) Date: Mon, 26 Dec 2016 08:18:02 +0100 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <1482709652.3394.15.camel@HansenPartnership.com> References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> <1482709652.3394.15.camel@HansenPartnership.com> Message-ID: I'd like both backwards and forward compatibility actually, exactly like x509. If an informational field is added like the key usage that I mentioned, I doubt you'd like all the previous consumers incompatible. For other extensions which make the structure totally incompatible you can use the critical flag. Anyway even the original struct is OK, it is exactly like any other key structs we have. On December 26, 2016 12:47:32 AM GMT+01:00, James Bottomley wrote: >On Sun, 2016-12-25 at 22:08 +0100, Nikos Mavrogiannopoulos wrote: >> On Sun, Dec 25, 2016 at 7:44 PM, James Bottomley >> wrote: >> > > TPMKey ::= SEQUENCE { >> > > type OBJECT IDENTIFIER >> > > version [0] IMPLICIT INTEGER OPTIONAL >> > > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL >> > > parent [2] IMPLICIT INTEGER OPTIONAL >> > > publicKey [3] IMPLICIT OCTET STRING OPTIONAL >> > > privateKey OCTET STRING >> > > extensions [4] EXPLICIT Extensions OPTIONAL >> > > } >> > >> > Actually, that's the utility of ASN.1, once you use tagging, you >> > don't have to do this. The structure above is identical to: >> > >> > TPMKey ::= SEQUENCE { >> > type OBJECT IDENTIFIER >> > version [0] IMPLICIT INTEGER OPTIONAL >> > emptyAuth [1] IMPLICIT BOOLEAN OPTIONAL >> > parent [2] IMPLICIT INTEGER OPTIONAL >> > publicKey [3] IMPLICIT OCTET STRING OPTIONAL >> > privateKey OCTET STRING >> > } >> > >> > If tag 4 isn't present because optional tags are not coded when not >> > present, so you can expand any ASN.1 structure as long as you have >> > a clue from the version number that you should be looking for the >> > optional extras. The point being I don't have to specify the >> > expansion now, I can wait until we need it. >> >> How would that work for example if you want to add an additional >> field with information on the type of the key for example (key >> usage)? You would add the tag 4 as you say, and then all the previous > >> parsers written with the initial description will fail parsing the >> new structure. X.509 (==PKIX) is only expandable via the extensions >> field which is already defined. If you add a field to it, no parser >> would be able to read the certificate. > >Um, well, you only want backwards compatibility, you don't really want >forward compatibility. Assuming something extends the structure and >adds version v2, why would it matter that an old v1 application can't >read a v2 structure because it doesn't understand the tag 4? Even if >it could it can't make use of the extra fields and something nasty will >happen. What you want is that the new v2 application can parse both >the v2 structure and the old v1 one, but it's advantageous that a v1 >application fails with a v2 structure because it prevents cockups. > >James -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.Bottomley at HansenPartnership.com Mon Dec 26 19:13:40 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Mon, 26 Dec 2016 10:13:40 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> <1482709652.3394.15.camel@HansenPartnership.com> Message-ID: <1482776020.2430.19.camel@HansenPartnership.com> On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote: > I'd like both backwards and forward compatibility actually, exactly > like x509. If an informational field is added like the key usage that > I mentioned, I doubt you'd like all the previous consumers > incompatible. OK, so there's a fundamental difference between a v3 X509 certificate and a TPM key: An X509 certificate is a signature over a set of v1 TBS data, a public key and a bundle of attributes. To verify the certificate or extract the key, you don't need to know what the attributes are, so you can still "use" the certificate in that form. However, you can't get the v1 tool to obey the v3 constraints on the certificate because it doesn't understand them. The ASN.1 description of a TPM key contains the actual binary representation of the key plus a set of information which explains to the consuming code how to use the key. Since I can't think of a way of making use of the key without understanding all of the information about how to use it, I think it is beneficial that v1 consumers don't try to use v2 key information because the resulting failure will excite the TPM's dictionary attack protection. I gave an example of one such extension: policy authorisations, but they're definitely of the "if you don't understand these, you can't use the key" variety. Perhaps if you can give an example of a potentially compatible extensions it would help me to see your point and give us a means of moving forwards. Thanks, James > For other extensions which make the structure totally incompatible > you can use the critical flag. Anyway even the original struct is OK, > it is exactly like any other key structs we have. From n.mavrogiannopoulos at gmail.com Mon Dec 26 21:13:03 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogianopoulos) Date: Mon, 26 Dec 2016 21:13:03 +0100 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <1482776020.2430.19.camel@HansenPartnership.com> References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> <1482709652.3394.15.camel@HansenPartnership.com> <1482776020.2430.19.camel@HansenPartnership.com> Message-ID: <671CBF50-E114-4FD1-995A-523C7B63F8D5@gmail.com> My comment was on the claim of extendability of the format which as I explained it is simply not true. As for example I already gave the key usage extension. I am fine however with a non extendable format as you proposed. On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley wrote: >On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote: >> I'd like both backwards and forward compatibility actually, exactly >> like x509. If an informational field is added like the key usage that >> I mentioned, I doubt you'd like all the previous consumers >> incompatible. > >OK, so there's a fundamental difference between a v3 X509 certificate >and a TPM key: An X509 certificate is a signature over a set of v1 TBS >data, a public key and a bundle of attributes. To verify the >certificate or extract the key, you don't need to know what the >attributes are, so you can still "use" the certificate in that form. > However, you can't get the v1 tool to obey the v3 constraints on the >certificate because it doesn't understand them. > >The ASN.1 description of a TPM key contains the actual binary >representation of the key plus a set of information which explains to >the consuming code how to use the key. Since I can't think of a way of >making use of the key without understanding all of the information >about how to use it, I think it is beneficial that v1 consumers don't >try to use v2 key information because the resulting failure will excite >the TPM's dictionary attack protection. > >I gave an example of one such extension: policy authorisations, but >they're definitely of the "if you don't understand these, you can't use >the key" variety. Perhaps if you can give an example of a potentially >compatible extensions it would help me to see your point and give us a >means of moving forwards. > >Thanks, > >James > >> For other extensions which make the structure totally incompatible >> you can use the critical flag. Anyway even the original struct is OK, >> it is exactly like any other key structs we have. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From James.Bottomley at HansenPartnership.com Fri Dec 30 00:57:17 2016 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Thu, 29 Dec 2016 15:57:17 -0800 Subject: [gnutls-devel] Proposal for the ASN.1 form of TPM1.2 and TPM2 keys In-Reply-To: <671CBF50-E114-4FD1-995A-523C7B63F8D5@gmail.com> References: <1482516363.2501.34.camel@HansenPartnership.com> <1482596030.2316.4.camel@HansenPartnership.com> <1482691491.3394.8.camel@HansenPartnership.com> <1482709652.3394.15.camel@HansenPartnership.com> <1482776020.2430.19.camel@HansenPartnership.com> <671CBF50-E114-4FD1-995A-523C7B63F8D5@gmail.com> Message-ID: <1483055837.2561.51.camel@HansenPartnership.com> On Mon, 2016-12-26 at 21:13 +0100, Nikos Mavrogianopoulos wrote: > My comment was on the claim of extendability of the format which as I > explained it is simply not true. As for example I already gave the > key usage extension. I am fine however with a non extendable format > as you proposed. OK, so I think the version is now superfluous, since if anything gets added it can be recognised by the tag and things not ready to parse that tag can reject it. That makes the final form TPMKey ::= SEQUENCE { type OBJECT IDENTIFIER emptyAuth [0] EXPLICIT BOOLEAN OPTIONAL parent [1] EXPLICIT INTEGER OPTIONAL pubkey [2] EXPLICIT OCTET STRING OPTIONAL privkey OCTET STRING } I'll code the v2 patch using this form. James > On December 26, 2016 7:13:40 PM GMT+01:00, James Bottomley < > James.Bottomley at HansenPartnership.com> wrote: > > On Mon, 2016-12-26 at 08:18 +0100, Nikos Mavrogianopoulos wrote: > > > I'd like both backwards and forward compatibility actually, > > > exactly > > > like x509. If an informational field is added like the key usage > > > that > > > I mentioned, I doubt you'd like all the previous consumers > > > incompatible. > > > > OK, so there's a fundamental difference between a v3 X509 > > certificate > > and a TPM key: An X509 certificate is a signature over a set of v1 > > TBS > > data, a public key and a bundle of attributes. To verify the > > certificate or extract the key, you don't need to know what the > > attributes are, so you can still "use" the certificate in that > > form. > > However, you can't get the v1 tool to obey the v3 constraints on > > the > > certificate because it doesn't understand them. > > > > The ASN.1 description of a TPM key contains the actual binary > > representation of the key plus a set of information which explains > > to > > the consuming code how to use the key. Since I can't think of a > > way of > > making use of the key without understanding all of the information > > about how to use it, I think it is beneficial that v1 consumers > > don't > > try to use v2 key information because the resulting failure will > > excite > > the TPM's dictionary attack protection. > > > > I gave an example of one such extension: policy authorisations, but > > they're definitely of the "if you don't understand these, you can't > > use > > the key" variety. Perhaps if you can give an example of a > > potentially > > compatible extensions it would help me to see your point and give > > us a > > means of moving forwards. > > > > Thanks, > > > > James > > > > > For other extensions which make the structure totally > > > incompatible > > > you can use the critical flag. Anyway even the original struct is > > > OK, > > > it is exactly like any other key structs we have. > From ametzler at bebt.de Sat Dec 31 13:13:18 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 31 Dec 2016 13:13:18 +0100 Subject: [gnutls-devel] gnutls_record_send after incomplete gnutls_handshake sends data unencrypted Message-ID: <20161231121318.faexsjlb4n5kzamg@argenau.bebt.de> Hello, find attached bug-report http://bugs.debian.org/849807 as reported by Bernhard R. Link. The related bug against sssd-ldap is cu Andreas ----- Forwarded message from "Bernhard R. Link" ----- Package: libgnutls30 Version: 3.5.7-3 Severity: normal Tags: security This bug report is not about wrong behavior if libgnutls is called correctly but rather about dangerous behaviour if the caller is using libgnutls incorrectly. If a handshake has not yet completed (the caller ignoring gnutls_handshake return code or the caller having a bug in the handling of GNUTLS_E_AGAIN) then telling libgnutls to send data causes it to send it unencrypted. Unless there are cases where might be useful, I think a security relevelant library like libgnutls should rather catch this mistake and avoid sending stuff unencrypted. Here's an example: cat <<'EOF' > example.c #define _GNU_SOURCE #include #include #include #include #include #include #include static ssize_t sim_write(gnutls_transport_ptr_t session, const void *data, size_t len) { bool found = memmem(data, len, "SECRET", 6) != NULL; printf("Would have written %d bytes%s.\n", (int)len, found?" containing unencrypted plain-text secret":""); fflush(stdout); return len; } static ssize_t sim_read(gnutls_transport_ptr_t session, void *data, size_t len) { /* simulate non-blocking io with no incoming data arrived yet */ gnutls_transport_set_errno(session, EAGAIN); fflush(stdout); return -1; } int main() { gnutls_certificate_credentials_t xcred; gnutls_session_t session; int r; r = gnutls_global_init(); assert (r == GNUTLS_E_SUCCESS); r = gnutls_certificate_allocate_credentials(&xcred); assert (r == GNUTLS_E_SUCCESS); r = gnutls_init(&session, GNUTLS_CLIENT); assert (r == GNUTLS_E_SUCCESS); r = gnutls_set_default_priority(session); assert (r == GNUTLS_E_SUCCESS); r = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, xcred); assert (r == GNUTLS_E_SUCCESS); gnutls_session_set_verify_cert(session, "server", 0); gnutls_transport_set_ptr(session, session); gnutls_transport_set_push_function(session, sim_write); gnutls_transport_set_pull_function(session, sim_read); r = gnutls_handshake(session); assert (r == GNUTLS_E_AGAIN); /* ignoring the return code and doing the sending: */ r = gnutls_record_send(session, "SECRET\n", 7); printf("gnutls_record_send returned %d\n", r); return 0; } EOF gcc -Wall -O2 -g example.c -lgnutls && ./a.out It outputs: Would have written 238 bytes. Would have written 12 bytes containing unencrypted plain-text secret. gnutls_record_send returned 7 i.e. the data is send unencrypted (looking at the output one sees a CLIENT_HELO followed by an APPLICATION_DATA packet with unencrypted content). One example where this happens is libldap, which runs into this if gotten an non-blocking fd (as currently sssd does, see #849756), causing sssd-ldap to corrently sending passwords unencrypted. Bernhard R. Link -- ----- End forwarded message -----