From tim.ruehsen at gmx.de Fri Sep 2 09:50:26 2016 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 02 Sep 2016 09:50:26 +0200 Subject: [gnutls-devel] Speedup idea... In-Reply-To: <1472389725.1988.2.camel@gnutls.org> References: <7742688.hTZLG4inon@blitz-lx> <2649316.ZQDDIFLkro@blitz-lx> <1472389725.1988.2.camel@gnutls.org> Message-ID: <3641842.asGhDUBRWj@blitz-lx> On Sunday, August 28, 2016 3:08:45 PM CEST Nikos Mavrogiannopoulos wrote: > On Wed, 2016-08-03 at 10:19 +0200, Tim Ruehsen wrote: > > > This violates the rule that the credentials must be read only after > > > being > > > set on a session, but on client side they are only used during > > > verification. An alternative approach is to verify the peers > > > certificates > > > using a trust list. > > > > My goal is to only load that CA cert(s) that really have to be > > checked > > against. I need to create a hash from the server certs which 'point' > > to the CA > > cert files on disk, like OpenSSL already does. Well, we talked about > > that in > > the past and you pointed me to p11kit... but in fact, I so far do not > > really > > have a 'big picture' - the p11kit docs are mostly technical details, > > no > > understandable explanation what 's it all about. > > I just realized, do you really need all of that? You can cache > verification outputs and that would be much more performant than any > optimization we discussed. You could for example save the > certificate/hostname pair once verified for limited time and rely on > that verification result instead. Pretty much similar to the trust on > first use, but here you will only be adding to the trusted store once > successfully verified, and for limited time. Thanks for the suggestion. Of course I could - but than we have to add that code to any application that uses GnuTLS. IMO, such a solution is just a temporary work around until it is 'fixed' in the library. A bigger solution would be to have a (local) infrastructure service/daemon that provides these and other kinds of shared information to any process. Right now every network application has it's own code for caching (OCSP, HSTS, HPKP, Session data, Cookies, ...) and static data (PSL, HSTS Preload, ...). Something like a pimped-up DNS :-)) Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From n.mavrogiannopoulos at gmail.com Fri Sep 2 17:07:51 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 2 Sep 2016 17:07:51 +0200 Subject: [gnutls-devel] moving the CI to gitlab.com shared runners Message-ID: Hi, With the following merge request [0] the majority of the tests is modified to run on the gitlab.com's shared runners set. This has certain advantages: 1. No need to setup and administer specific runner systems 2. It is much easier to include a test for other systems such as debian/ubuntu (few more lines in gitlab-ci.yml) Currently only the freebsd CI test is kept with a specific runner system hosted by Red Hat. I encourage you to submit tests for other systems that you believe gnutls should compile and run on. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/merge_requests/57 From stbuehler at lighttpd.net Fri Sep 2 18:31:45 2016 From: stbuehler at lighttpd.net (Stefan =?UTF-8?B?QsO8aGxlcg==?=) Date: Fri, 2 Sep 2016 18:31:45 +0200 Subject: [gnutls-devel] OCSP certificate check In-Reply-To: References: <20160827160031.08b8f476@chromobil-cert.local> <1472310323.2467.1.camel@gmail.com> <20160902171804.0d5e4512@chromobil-cert.local> Message-ID: <20160902183145.7409a4dd@chromobil-cert.local> Hi, some days ago I discovered that the OCSP certificate check doesn't actually verify the serial length and might succeed when it shouldn't: https://gitlab.com/gnutls/gnutls/blob/9bb4ca9ec8ed504429d582ac3de28aaf8d88b1e8/lib/x509/ocsp.c#L1322 `rserial.size != cserial.size` is never true, as `cserial.size` was initialized with `rserial.size`, and none of them gets changed; `t` is actually changed by `gnutls_x509_crt_get_serial` and should get checked; otherwise it might compare whatever bytes `gnutls_malloc` left at the end. Nikos fixed it in: https://gitlab.com/gnutls/gnutls/commit/964632f37dfdfb914ebc5e49db4fa29af35b1de9 My reading is that this could allow someone to use a OCSP respose for a different certificate (but from the same CA) to continue using a revoked certificate, if the serial from the revoked certificate is a prefix of the other one, and the additional bytes happen to be equal on the system doing the verification. e.g. if the revoked serial is AB:CD:EF I might try to get an OCSP respone for AB:CD:EF:00 (hoping that gnutls_malloc returns a buffer with a zero at the 4th position during verification). Any other interpretations? Should this get a CVE? regards, Stefan From nmav at gnutls.org Sat Sep 3 10:48:13 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 03 Sep 2016 10:48:13 +0200 Subject: [gnutls-devel] Speedup idea... In-Reply-To: <3641842.asGhDUBRWj@blitz-lx> References: <7742688.hTZLG4inon@blitz-lx> <2649316.ZQDDIFLkro@blitz-lx> <1472389725.1988.2.camel@gnutls.org> <3641842.asGhDUBRWj@blitz-lx> Message-ID: <1472892493.1997.3.camel@gnutls.org> On Fri, 2016-09-02 at 09:50 +0200, Tim Ruehsen wrote: > > > understandable explanation what 's it all about. > > I just realized, do you really need all of that? You can cache > > verification outputs and that would be much more performant than > > any > > optimization we discussed. You could for example save the > > certificate/hostname pair once verified for limited time and rely > > on > > that verification result instead. Pretty much similar to the trust > > on > > first use, but here you will only be adding to the trusted store > > once > > successfully verified, and for limited time. > Thanks for the suggestion. > > Of course I could - but than we have to add that code to any > application that? > uses GnuTLS. IMO, such a solution is just a temporary work around > until it is? > 'fixed' in the library. Well, trust on first use is already supported in the library. If there are improvements on that API to make it work as a caching layer, I'd be glad to help with that. > A bigger solution would be to have a (local) infrastructure > service/daemon? > that provides these and other kinds of shared information to any > process.? > Right now every network application has it's own code for caching > (OCSP, HSTS,? > HPKP, Session data, Cookies, ...) and static data (PSL, HSTS Preload, > ...). > Something like a pimped-up DNS :-)) That's certainly interesting. Providing these as an OS service would certainly help. However, I think we are pretty far from such holistic solution. regards, Nikos From nmav at gnutls.org Sat Sep 3 10:58:13 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 03 Sep 2016 10:58:13 +0200 Subject: [gnutls-devel] OCSP certificate check In-Reply-To: <20160902183145.7409a4dd@chromobil-cert.local> References: <20160827160031.08b8f476@chromobil-cert.local> <1472310323.2467.1.camel@gmail.com> <20160902171804.0d5e4512@chromobil-cert.local> <20160902183145.7409a4dd@chromobil-cert.local> Message-ID: <1472893093.1997.10.camel@gnutls.org> On Fri, 2016-09-02 at 18:31 +0200, Stefan B?hler wrote: > Hi, > > some days ago I discovered that the OCSP certificate check doesn't > actually verify the serial length and might succeed when it > shouldn't: > > https://gitlab.com/gnutls/gnutls/blob/9bb4ca9ec8ed504429d582ac3de28aa > f8d88b1e8/lib/x509/ocsp.c#L1322 > > `rserial.size != cserial.size` is never true, as `cserial.size` > was initialized with `rserial.size`, and none of them gets > changed; `t` is actually changed by `gnutls_x509_crt_get_serial` > and should get checked; otherwise it might compare whatever bytes > `gnutls_malloc` left at the end.?? > Nikos fixed it in: > https://gitlab.com/gnutls/gnutls/commit/964632f37dfdfb914ebc5e49db4fa > 29af35b1de9? > > My reading is that this could allow someone to use a OCSP respose for > a > different certificate (but from the same CA) to continue using a > revoked certificate, if the serial from the revoked certificate is a > prefix of the other one, and the additional bytes happen to be equal > on the system doing the verification. > e.g. if the revoked serial is AB:CD:EF I might try to get an > OCSP respone for AB:CD:EF:00 (hoping that gnutls_malloc returns a > buffer with a zero at the 4th position during verification). Right. That's indeed an issue, but since the requirements to exploit that are not under the control of the attacker (but rather the CA), my initial assessment was that this has low impact. However given that most OCSP servers return valid replies for unknown serials, it makes sense to assign it a GNUTLS-SA on the security page and link to your description. regards, Nikos From n.mavrogiannopoulos at gmail.com Mon Sep 5 16:29:25 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 5 Sep 2016 16:29:25 +0200 Subject: [gnutls-devel] TLS 1.3 in gnutls Message-ID: Hi, I've tried to make a rough sketch of the requirements needed to support TLS 1.3 in gnutls. I've split the task in sub-tasks on [0]. Some need to be handled in gnutls and some need to be handled in nettle. Do you think I've missed something, or there are tasks that can be further split? About the nettle additions, is there anyone already working or willing to work on these? On the gnutls part is there anyone already working or willing to work on the missing parts? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/milestones/8 From nisse at lysator.liu.se Mon Sep 5 18:15:18 2016 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Mon, 05 Sep 2016 18:15:18 +0200 Subject: [gnutls-devel] TLS 1.3 in gnutls In-Reply-To: (Nikos Mavrogiannopoulos's message of "Mon, 5 Sep 2016 16:29:25 +0200") References: Message-ID: Nikos Mavrogiannopoulos writes: > [0]. https://gitlab.com/gnutls/gnutls/milestones/8 Nettle additions: * HKDF (RFC 5869): Should be reasonably straight forward. Any use besides TLS 1.3? * RSA-PSS. I take it's mandatory? I had the impression that pss was almost dead (specified more than a decade ago, and very rarely used, hard to do constant time). We'll have to support it, I guess. Andy Lawrence expressed some interest on the Nettle list last December, but I don't know what's happened since. If I quote Peter Gutmann on the secsh mailing list: : However, PSS has seen so little interest from both the crypto : community and implementers that we can't really say much about it. For : example for some years the NIST test vectors for RSA-PSS were completely wrong : (every single test except the SHA-224 ones failed), and no-one noticed. : : I'll just let that sink in for a second. The published test vectors from a : major, effectively global in reach, standards body for RSA-PSS were wrong, and : no-one noticed. How much attention do you think that indicates PSS has got in : practice? * x448. Should be able to reuse some of the curve25519 code, but not all. for curve25519, multiplying a point by a scalar is doen using a Montgomery ladder (see curve25519-mul.c), and I'd expect it to be reasonably straight forward to generalize to x448. On the other hand, multiplying the fixed generator by a scalar is done on the corresponding (twisted) edwards curve, using Pippenger's algorithm, and then transformed back by a change of coordinates, see below. * ed448. This curve has slightly different structure from ed25519 (not twisted). Current point add code for ed25519 is suboptimal, it uses formulas for non-twisted curve with appropriate only sign changes, and it could save a mod mul by taking better advantage of the twist. So ed448 needs its own point addition code. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From n.mavrogiannopoulos at gmail.com Mon Sep 5 18:46:17 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 05 Sep 2016 18:46:17 +0200 Subject: [gnutls-devel] TLS 1.3 in gnutls In-Reply-To: References: Message-ID: <1473093977.4738.11.camel@gmail.com> On Mon, 2016-09-05 at 18:15 +0200, Niels M?ller wrote: > Nikos Mavrogiannopoulos writes: > > > > > [0]. https://gitlab.com/gnutls/gnutls/milestones/8 > Nettle additions: > > * HKDF (RFC 5869): Should be reasonably straight forward. Any use > ? besides TLS 1.3? I'm not aware of any other, but I didn't really searched. I expect that since it is well-specified and standardized by TLS 1.3, it will be used by other protocols, but that's more of a speculation.? > * RSA-PSS. I take it's mandatory? I had the impression that pss was > ? almost dead (specified more than a decade ago, and very rarely > used, > ? hard to do constant time). We'll have to support it, I guess. The latest draft has fallback to PKCS#1 1.5. It however states: "A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256." so having it is a "must". The constant time point is worrying. > Andy Lawrence expressed some interest on the Nettle list last > December, but I don't know what's happened since. Andy do you have any update on that? > ? If I quote Peter Gutmann on the secsh mailing list: > > ???: However, PSS has seen so little interest from both the crypto > ???: community and implementers that we can't really say much about > it.??For > ???: example for some years the NIST test vectors for RSA-PSS were > completely wrong > ???: (every single test except the SHA-224 ones failed), and no-one > noticed. > ???:? > ???: I'll just let that sink in for a second.??The published test > vectors from a > ???: major, effectively global in reach, standards body for RSA-PSS > were wrong, and > ???: no-one noticed.??How much attention do you think that indicates > PSS has got in > ???: practice? PKCS#1 1.5 worked well for signing. There were no real-world attacks known so I guess there was no incentive to switch to PSS. I only saw PSS signatures in some certificates issues by governments for inclusion in passports. > * x448. Should be able to reuse some of the curve25519 code, but not > ? all. for curve25519, multiplying a point by a scalar is doen using > a > ? Montgomery ladder (see curve25519-mul.c), and I'd expect it to be > ? reasonably straight forward to generalize to x448. On the other > hand, > ? multiplying the fixed generator by a scalar is done on the > ? corresponding (twisted) edwards curve, using Pippenger's algorithm, > ? and then transformed back by a change of coordinates, see below. > * ed448. This curve has slightly different structure from ed25519 > (not > ? twisted). Current point add code for ed25519 is suboptimal, it uses > ? formulas for non-twisted curve with appropriate only sign changes, > and > ? it could save a mod mul by taking better advantage of the twist. So > ? ed448 needs its own point addition code. These are of lower priority. We already have x25519 and the ECDSA curves, so there is something to start with. regards, Nikos From nmav at gnutls.org Thu Sep 8 07:49:37 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Sep 2016 07:49:37 +0200 Subject: [gnutls-devel] gnutls 3.5.4 Message-ID: <1473313777.792.2.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.4. This is a minor enhancements and bugfix release for the 3.5.x branch. * Version 3.5.4 (released 2016-09-08) ** libgnutls: Corrected the comparison of the serial size in OCSP ? ?response. Previously the OCSP certificate check wouldn't verify the ? ?serial length and could succeed in cases it shouldn't? ? ?(GNUTLS-SA-2016-3). Reported by Stefan Buehler. ** libgnutls: Added support for IP name constraints. Patch by Martin ? ?Ukrop. ** libgnutls: Added support for PKCS#8 file decryption using ? ?DES-CBC-MD5. This is added to allow decryption of PKCS #8 private ? ?keys from openssl prior to 1.1.0. ** libgnutls: Added support for decrypting PKCS#8 files which use? ? ?HMAC-SHA256 as PRF. This allow decrypting PKCS #8 private keys ? ?generated with openssl 1.1.0. ** libgnutls: Added support for internationalized passwords in PKCS#12 ? ?files. Previous versions would only encrypt or decrypt using ? ?passwords from the ASCII set. ** libgnutls: Addressed issue with PKCS#11 signature generation on ? ?ECDSA keys. The signature is now written as unsigned integers into ? ?the DSASignatureValue structure. Previously signed integers could be ? ?written depending on what the underlying module would produce. ? ?Addresses #122. ** gnutls-cli: Fixed starttls regression from 3.5.3. ** API and ABI modifications: GNUTLS_E_MALFORMED_CIDR: Added gnutls_x509_cidr_to_rfc5280: Added gnutls_oid_to_mac: 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.4.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.4.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 Sep 8 07:59:24 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 08 Sep 2016 07:59:24 +0200 Subject: [gnutls-devel] gnutls 3.4.15 Message-ID: <1473314364.792.5.camel@gnutls.org> Hello,? ?I've just released gnutls 3.4.15. This is a bug fix release of the current stable branch. * Version 3.4.15 (released 2016-09-08) ** libgnutls: Corrected the comparison of the serial size in OCSP ? ?response. Previously the OCSP certificate check wouldn't verify the ? ?serial length and could succeed in cases it shouldn't ? ?(GNUTLS-SA-2016-3). Reported by Stefan Buehler. ** libgnutls: Fixes in gnutls_x509_crt_list_import2, which was ???ignoring flags if all certificates in the list fit within the ???initially allocated memory. ** libgnutls: Corrected issue which made ? ?gnutls_certificate_get_x509_crt() to return invalid pointers when ? ?returned more than a single certificate. Report and fix by Stefan ? ?S?rensen. ** libgnutls: Fix gnutls_pkcs12_simple_parse to always extract the ? ?complete chain. Report and fix by Stefan S?rensen. ** libgnutls: Added support for decrypting PKCS#8 files which use the ? ?HMAC-SHA256 as PRF. ** libgnutls: Addressed issue with PKCS#11 signature generation on ? ?ECDSA keys. The signature is now written as unsigned integers into ? ?the DSASignatureValue structure. Previously signed integers could be ? ?written depending on what the underlying module would produce. ? ?Addresses #122. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.15.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.15.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 ametzler at bebt.de Sun Sep 11 16:06:29 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 11 Sep 2016 16:06:29 +0200 Subject: [gnutls-devel] [patch] typo fixes Message-ID: <20160911140629.t4azltxaj63kcgb6@argenau.bebt.de> Helo, find attached another trivial patch, fixing typoes found by lintian. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Typo-fixes-found-by-lintian.patch Type: text/x-diff Size: 1435 bytes Desc: not available URL: From nmav at gnutls.org Mon Sep 12 08:42:01 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 12 Sep 2016 08:42:01 +0200 Subject: [gnutls-devel] [patch] typo fixes In-Reply-To: <20160911140629.t4azltxaj63kcgb6@argenau.bebt.de> References: <20160911140629.t4azltxaj63kcgb6@argenau.bebt.de> Message-ID: On Sun, Sep 11, 2016 at 4:06 PM, Andreas Metzler wrote: > Helo, > find attached another trivial patch, fixing typoes found by lintian. Applied. Thank you. From tony.reix at atos.net Wed Sep 14 18:35:33 2016 From: tony.reix at atos.net (REIX, Tony) Date: Wed, 14 Sep 2016 16:35:33 +0000 Subject: [gnutls-devel] Failing tests on AIX In-Reply-To: <57D97BE0.3080800@atos.net> References: <57D97BE0.3080800@atos.net> Message-ID: <57D97BF1.6000406@atos.net> Hi, I'm porting version 3.4.15 of gnuTLS on AIX 6.1 and I have several tests failing, like the following ones. I'd like to get some advice about where I can find information about analyzing the failure. Any suggestion is welcome ! Or should I open a defect at: https://gitlab.com/gnutls/gnutls/issues ? Thanks/Regards, Tony mini-record-2 : ch_handler:436: Child died with sigsegv client:164: client (NONE:+VERS-TLS1.2:-CIPHER-ALL:+RSA:+AES-128-CBC:+AES-256-CBC:+SHA256:+SIGN-ALL:+COMP-NULL:+ANON-ECDH:+CURVE-ALL): Handshake has failed (The TLS connection was non-properly terminated.) mini-loss-time ch_handler:289: Child died with status -1 client:171: client: Handshake failed with unexpected reason: Error in the push function. mini-record ch_handler:436: Child died with sigsegv client:164: client (NONE:+VERS-TLS1.2:-CIPHER-ALL:+RSA:+AES-128-CBC:+AES-256-CBC:+SHA256:+SIGN-ALL:+COMP-NULL:+ANON-ECDH:+CURVE-ALL): Handshake has failed (The TLS connection was non-properly terminated.) ch_handler:443: Child died with sigsegv client:164: client (NONE:+VERS-TLS1.2:-CIPHER-ALL:+RSA:+AES-128-GCM:+MAC-ALL:+SIGN-ALL:+COMP-NULL:+ANON-ECDH:+CURVE-ALL): Handshake has failed (The TLS connection was non-properly terminated.) ch_handler:403: Child died with sigsegv client:206: client: Handshake failed mini-record-retvals ch_handler:443: Child died with sigsegv client:164: client (NONE:+VERS-TLS1.2:-CIPHER-ALL:+RSA:+AES-128-GCM:+MAC-ALL:+SIGN-ALL:+COMP-NULL:+ANON-ECDH:+CURVE-ALL): Handshake has failed (The TLS connection was non-properly terminated.) mini-server-name ch_handler:320: Child died with sigsegv client:151: client: Handshake failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at bebt.de Fri Sep 16 19:28:30 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 16 Sep 2016 19:28:30 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> Message-ID: <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> On 2016-08-28 Nikos Mavrogiannopoulos wrote: > On Fri, Aug 26, 2016 at 7:18 PM, Andreas Metzler wrote: > > Hello, > > > > this is https://bugs.debian.org/835342 reported by [...] > Something is wrong there. I don't see any changes in gnutls code that > could result to it. Could the user bisect since 3.5.2 and try to > figure out the change that causes that issue? Is there a reproducer? [...] Hello, yes, there is a reproducer, and we now have git bisect: -------------------------------------------------------------- Hey there, After struggling a bit with the process of "bisecting", I think I got something :). You can view git bisect log here http://pastebin.com/sj1ZbbqA c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 is the first bad commit commit c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 Author: Nikos Mavrogiannopoulos Date: Mon Aug 1 10:48:46 2016 +0200 nettle: use rsa_*_key_prepare Previously we calculated the size of the key directly, but by using the rsa_*_key_prepare we benefit from any checks that may be introduced in the future. Specifically any checks for invalid public keys (e.g., keys that may crash the underlying gmp functions). :040000 040000 29a2377df28240d7688082ac12318baacdd1bb7c 23aa890386085677a878268578e9a2c27d396c80 Mlib It seems the commit "b0d560b" reverts "c801a15", and commit 186dc9c breaks it again. I hope that helps. -------------------------------------------------------------- cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From n.mavrogiannopoulos at gmail.com Sat Sep 17 11:49:10 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 17 Sep 2016 11:49:10 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> Message-ID: <1474105750.1994.6.camel@gmail.com> On Fri, 2016-09-16 at 19:28 +0200, Andreas Metzler wrote: > On 2016-08-28 Nikos Mavrogiannopoulos wrote: > > > > On Fri, Aug 26, 2016 at 7:18 PM, Andreas Metzler > > wrote: > > > > > > Hello, > > > > > > this is https://bugs.debian.org/835342 reported by > [...] > > > > Something is wrong there. I don't see any changes in gnutls code > > that > > could result to it. Could the user bisect since 3.5.2 and try to > > figure out the change that causes that issue? Is there a > > reproducer? > [...] > > Hello, > yes, there is a reproducer, and we now have git bisect: > -------------------------------------------------------------- > > Hey there, > After struggling a bit with the process of "bisecting", I think I got > something :). > You can view git bisect log here http://pastebin.com/sj1ZbbqA > > c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 is the first bad commit > commit c801a15bca9ea8f3f7abd4be48bebd36c54eeba2 > Author: Nikos Mavrogiannopoulos > Date:???Mon Aug 1 10:48:46 2016 +0200 > > ????nettle: use rsa_*_key_prepare > > ????Previously we calculated the size of the key directly, but > ????by using the rsa_*_key_prepare we benefit from any checks that > ????may be introduced in the future. Specifically any checks for > invalid > ????public keys (e.g., keys that may crash the underlying gmp > functions). Thank you. Could I have a capture of the session? My speculation is that the user is under man-in-the-middle attack and the presented RSA public key in the certificate is rejected by rsa_public_key_prepare(). If that is run with nettle 3.2, then only check is whether the N is < 96 bits which is way too small even for an attacker. Later versions (in git) have an additional check for N being even. A capture and the nettle version used will shed some light on the issue. regards, Nikos From n.mavrogiannopoulos at gmail.com Sat Sep 17 11:51:48 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 17 Sep 2016 11:51:48 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474105750.1994.6.camel@gmail.com> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> Message-ID: On Sat, Sep 17, 2016 at 11:49 AM, Nikos Mavrogiannopoulos wrote: >> Date: Mon Aug 1 10:48:46 2016 +0200 >> >> nettle: use rsa_*_key_prepare >> >> Previously we calculated the size of the key directly, but >> by using the rsa_*_key_prepare we benefit from any checks that >> may be introduced in the future. Specifically any checks for >> invalid >> public keys (e.g., keys that may crash the underlying gmp >> functions). > Thank you. Could I have a capture of the session? My speculation is > that the user is under man-in-the-middle attack and the presented RSA > public key in the certificate is rejected by rsa_public_key_prepare(). > If that is run with nettle 3.2, then only check is whether the N is < > 96 bits which is way too small even for an attacker. Later versions (in > git) have an additional check for N being even. A capture and the > nettle version used will shed some light on the issue. In the following merge request I've introduced separate error codes to easier detect such invalid cases: https://gitlab.com/gnutls/gnutls/merge_requests/84 regards, Nikos From ametzler at bebt.de Sat Sep 17 12:48:40 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 17 Sep 2016 12:48:40 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474105750.1994.6.camel@gmail.com> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> Message-ID: <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> On 2016-09-17 Nikos Mavrogiannopoulos wrote: [...] > Thank you. Could I have a capture of the session? My speculation is > that the user is under man-in-the-middle attack and the presented RSA > public key in the certificate is rejected by rsa_public_key_prepare(). > If that is run with nettle 3.2, then only check is whether the N is < > 96 bits which is way too small even for an attacker. Later versions (in > git) have an additional check for N being even. A capture and the > nettle version used will shed some light on the issue. Could you perhaps provide Marcelo with step-by-step instructions on how to generate the session capture? Nettle version is 3.2. thanks, cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From n.mavrogiannopoulos at gmail.com Sat Sep 17 18:07:47 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 17 Sep 2016 18:07:47 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> Message-ID: <1474128467.2008.7.camel@gmail.com> On Sat, 2016-09-17 at 12:48 +0200, Andreas Metzler wrote: > On 2016-09-17 Nikos Mavrogiannopoulos > wrote: > [...] > > > > Thank you. Could I have a capture of the session? My speculation is > > that the user is under man-in-the-middle attack and the presented > > RSA > > public key in the certificate is rejected by > > rsa_public_key_prepare(). > > If that is run with nettle 3.2, then only check is whether the N is > > < > > 96 bits which is way too small even for an attacker. Later versions > > (in > > git) have an additional check for N being even. A capture and the > > nettle version used will shed some light on the issue. > Could you perhaps provide Marcelo with step-by-step instructions on > how > to generate the session capture? I'd run wireshark -i eth0 (replace eth0 with the ethernet interface name), and click start capture. Then on another terminal run the command that makes the TLS connection fail. Then click capture -> Stop, In "apply display filter", type ssl, then File -> Export specified packets and send the saved pcap file. regards, Nikos From nmav at gnutls.org Mon Sep 19 11:36:33 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Sep 2016 11:36:33 +0200 Subject: [gnutls-devel] OCSP certificate check In-Reply-To: <20160902183145.7409a4dd@chromobil-cert.local> References: <20160827160031.08b8f476@chromobil-cert.local> <1472310323.2467.1.camel@gmail.com> <20160902171804.0d5e4512@chromobil-cert.local> <20160902183145.7409a4dd@chromobil-cert.local> Message-ID: On Fri, Sep 2, 2016 at 6:31 PM, Stefan B?hler wrote: > Hi, > some days ago I discovered that the OCSP certificate check doesn't > actually verify the serial length and might succeed when it shouldn't: > https://gitlab.com/gnutls/gnutls/blob/9bb4ca9ec8ed504429d582ac3de28aaf8d88b1e8/lib/x509/ocsp.c#L1322 > `rserial.size != cserial.size` is never true, as `cserial.size` > was initialized with `rserial.size`, and none of them gets > changed; `t` is actually changed by `gnutls_x509_crt_get_serial` > and should get checked; otherwise it might compare whatever bytes > `gnutls_malloc` left at the end. [...] > Any other interpretations? Should this get a CVE? It has been assigned CVE-2016-7444. http://seclists.org/oss-sec/2016/q3/549 From n.mavrogiannopoulos at gmail.com Mon Sep 19 15:01:06 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 19 Sep 2016 15:01:06 +0200 Subject: [gnutls-devel] self-test failure in gnutls-3.5.4 on NetBSD-7.99.38/amd64 In-Reply-To: <20160919122942.2ymaw523f4jzllga@danbala> References: <20160919122942.2ymaw523f4jzllga@danbala> Message-ID: On Mon, Sep 19, 2016 at 2:29 PM, Thomas Klausner wrote: > Hi! > > When running the self-tests for gnutls-3.5.4 on NetBSD-7.99.38/amd64, > there is one self-test failure: > > FAIL: mini-server-name > server:262: server: did not received expected name Could you provide an investigation of the failure? If you run the test with the -v option it should provide more debugging information. At this commit you can find a modification which will pinpoint which of the tests run failed: https://gitlab.com/gnutls/gnutls/commit/f14ec7e98cd5fcc846b08c9ddee4ed55e2d08474 > 5 more are SKIPped. > Two other tests depend on /bin/bash, which does not exist on NetBSD by > default (of course you can install /usr/pkg/bin/bash from pkgsrc): > FAIL: fastopen.sh > SKIP: starttls.sh > Can they perhaps be converted to be runnable with any POSIX shell? I don't plan to, but if you have a patch, I'd be happy to apply to. However, as these scripts are only used for checking gnutls, I think requiring bash for the testing phase is not much unreasonable. Is the test failure reason the fact that bash is not available? regards, Nikos From n.mavrogiannopoulos at gmail.com Mon Sep 19 15:37:58 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 19 Sep 2016 15:37:58 +0200 Subject: [gnutls-devel] self-test failure in gnutls-3.5.4 on NetBSD-7.99.38/amd64 In-Reply-To: <20160919132910.pjyunwn27rio4iqj@danbala> References: <20160919122942.2ymaw523f4jzllga@danbala> <20160919132910.pjyunwn27rio4iqj@danbala> Message-ID: On Mon, Sep 19, 2016 at 3:29 PM, Thomas Klausner wrote: > On Mon, Sep 19, 2016 at 03:01:06PM +0200, Nikos Mavrogiannopoulos wrote: >> Could you provide an investigation of the failure? If you run the test >> with the -v option it should provide more debugging information. >> At this commit you can find a modification which will pinpoint which >> of the tests run failed: >> https://gitlab.com/gnutls/gnutls/commit/f14ec7e98cd5fcc846b08c9ddee4ed55e2d08474 > I've applied that patch (which made mini-session-verify-function.o > fail to build) which supplied more information on the test failure: > server:262: invalid-utf8: did not received expected name Could it be that you are compiling without libidn? In that case you may want to apply: https://gitlab.com/gnutls/gnutls/commit/480c9f572c511230699a1d35d3053515058584c2 regards, Nikos From ametzler at bebt.de Mon Sep 19 18:53:04 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 19 Sep 2016 18:53:04 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474128467.2008.7.camel@gmail.com> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> Message-ID: <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> On 2016-09-17 Nikos Mavrogiannopoulos wrote: > On Sat, 2016-09-17 at 12:48 +0200, Andreas Metzler wrote: >> Could you perhaps provide Marcelo with step-by-step instructions on how >> to generate the session capture? > I'd run wireshark -i eth0 (replace eth0 with the ethernet interface [...] Thanks. Marcelo has uploaded the capture files: | This link has two files: | | pcap_gnutls.pcapng (Fail, libgnutls30:amd64 3.5.4-2) | pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64 3.5.2-3) | | https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Tue Sep 20 08:56:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 20 Sep 2016 08:56:19 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> Message-ID: <1474354579.2112.5.camel@gnutls.org> On Mon, 2016-09-19 at 18:53 +0200, Andreas Metzler wrote: > On 2016-09-17 Nikos Mavrogiannopoulos > wrote: > > > > On Sat, 2016-09-17 at 12:48 +0200, Andreas Metzler wrote: > > > > > > Could you perhaps provide Marcelo with step-by-step instructions > > > on how > > > to generate the session capture? > > > > I'd run wireshark -i eth0 (replace eth0 with the ethernet interface > [...] > > Thanks. Marcelo has uploaded the capture files: > > This link has two files: > > > > pcap_gnutls.pcapng (Fail, libgnutls30:amd64??3.5.4-2) > > pcap_gnutls_v352.pcapng (Working version, libgnutls30:amd64??3.5.2- > > 3) > > https://drive.google.com/drive/folders/0B3_AQUiHn1qMcEVjdVpNeHBJUHc I do not see anything wrong in the capture. I even created a small program to replay the connection locally (I have a debian installation on x86_64 with the same packages available), and the connection continued past the failure point on that system. I'm searching in the dark here, but the following info could help: 1. run gnutls-cli www.server-that-fails?-d 9 2. run valgrind gnutls-cli www.server-that-fails 3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed && ./a.out", and also run valgrind ./a.out -------------- next part -------------- A non-text attachment was scrubbed... Name: sim.c Type: text/x-csrc Size: 1459 bytes Desc: not available URL: From nmav at gnutls.org Tue Sep 20 14:25:32 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 20 Sep 2016 14:25:32 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474354579.2112.5.camel@gnutls.org> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> Message-ID: On Tue, Sep 20, 2016 at 8:56 AM, Nikos Mavrogiannopoulos wrote: > I do not see anything wrong in the capture. I even created a small > program to replay the connection locally (I have a debian installation > on x86_64 with the same packages available), and the connection > continued past the failure point on that system. > > I'm searching in the dark here, but the following info could help: > 1. run gnutls-cli www.server-that-fails -d 9 > 2. run valgrind gnutls-cli www.server-that-fails > 3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed && > ./a.out", and also run valgrind ./a.out One 4th item suggested by Niels Moeller: 4. run ldd /usr/bin/gnutls-cli # (that way we can see whether the client is linked to the expected nettle library) regards, Nikos From nmav at gnutls.org Tue Sep 20 20:21:52 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 20 Sep 2016 20:21:52 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> Message-ID: On Tue, Sep 20, 2016 at 2:25 PM, Nikos Mavrogiannopoulos wrote: > On Tue, Sep 20, 2016 at 8:56 AM, Nikos Mavrogiannopoulos > wrote: >> I do not see anything wrong in the capture. I even created a small >> program to replay the connection locally (I have a debian installation >> on x86_64 with the same packages available), and the connection >> continued past the failure point on that system. >> >> I'm searching in the dark here, but the following info could help: >> 1. run gnutls-cli www.server-that-fails -d 9 >> 2. run valgrind gnutls-cli www.server-that-fails >> 3. compile the attached program as "gcc -O2 -g sim.c -lgmp -lhogweed && >> ./a.out", and also run valgrind ./a.out Following up on that, if gnutls-cli doesn't work, try the commands above with curl, but before run "export GNUTLS_DEBUG_LEVEL=9". That will provide debugging output. Then the same under valgrind, i.e., "valgrind curl ..." (in that case please do not set the GNUTLS_DEBUG_LEVEL to simplify logs) About the program, unfortunately gnupg's pipermail scrubs attachments, so I'm re-attaching it. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: sim.c Type: text/x-csrc Size: 1459 bytes Desc: not available URL: From stbuehler at lighttpd.net Tue Sep 20 23:36:46 2016 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Tue, 20 Sep 2016 23:36:46 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> Message-ID: <01bd5333-5b59-f1c8-6ab7-185ddc8341c8@stbuehler.de> Hi, I can reproduce the problem by simply responding with the same data as shown in the PCAP file. (I'll try to describe it at the bottom). It fails to verify the signature in the server key exchange: (gdb) bt #0 _nettle_rsa_verify (key=key at entry=0x7fffffffa7b0, m=m at entry=0x7fffffffa710, s=s at entry=0xad6f90) at rsa-verify.c:59 #1 0x00007ffff678cc7b in nettle_rsa_pkcs1_verify (key=key at entry=0x7fffffffa7b0, length=, digest_info=0xadf890 "010\r\006\t`\206H\001e\003\004\002\001\005", s=0xad6f90) at rsa-pkcs1-verify.c:53 #2 0x00007ffff7b7c211 in _wrap_nettle_pk_verify (algo=, vdata=0x7fffffffa840, signature=, pk_params=0xadf5f8) at pk.c:750 #3 0x00007ffff7ad2dbd in _pkcs1_rsa_verify_sig (me=me at entry=0x7ffff7dd2d10 , text=text at entry=0x0, prehash=, signature=0x7fffffffab20, params=) at pubkey.c:1827 #4 0x00007ffff7ad56a2 in pubkey_verify_hashed_data (pk=GNUTLS_PK_RSA, hash_algo=0x7ffff7dd2d10 , hash=0x7fffffffa960, signature=0x7fffffffab20, issuer_params=0xadf5f8) at pubkey.c:1908 #5 0x00007ffff7ac5cac in verify_tls_hash (session=session at entry=0xac7710, ver=ver at entry=0x7ffff7dd30c0 , cert=cert at entry=0x7fffffffab30, hash_concat=hash_concat at entry=0x7fffffffa9e0, signature=signature at entry=0x7fffffffab20, sha1pos=sha1pos at entry=0, sign_algo=GNUTLS_SIGN_RSA_SHA256, pk_algo=GNUTLS_PK_RSA) at tls-sig.c:266 #6 0x00007ffff7ac63f7 in _gnutls_handshake_verify_data (session=session at entry=0xac7710, cert=cert at entry=0x7fffffffab30, params=params at entry=0x7fffffffaba0, signature=signature at entry=0x7fffffffab20, sign_algo=sign_algo at entry=GNUTLS_SIGN_RSA_SHA256) at tls-sig.c:360 #7 0x00007ffff7b4594a in _gnutls_proc_dhe_signature (session=session at entry=0xac7710, data=, data at entry=0xad9535 "\004\001\001", _data_size=_data_size at entry=260, vparams=vparams at entry=0x7fffffffaba0) at cert.c:2207 #8 0x00007ffff7b4e32d in proc_ecdhe_server_kx (session=0xac7710, data=0xad94f0 "\003", _data_size=329) at ecdhe.c:310 #9 0x00007ffff7ab5454 in _gnutls_recv_server_kx_message (session=session at entry=0xac7710) at kx.c:506 #10 0x00007ffff7ab0908 in handshake_client (session=0xac7710) at handshake.c:2845 #11 gnutls_handshake (session=0xac7710) at handshake.c:2597 #12 0x0000000000409c0d in do_handshake (socket=socket at entry=0x7fffffffc160) at cli.c:1673 #13 0x000000000040c917 in socket_open (hd=hd at entry=0x7fffffffc160, hostname=, service=service at entry=0x618d60 "9090", app_proto=, flags=, msg=msg at entry=0x41066b "Connecting to", rdata=) at socket.c:493 #14 0x000000000040732c in main (argc=, argv=) at cli.c:1222 "mpz_powm(m1, s, key->e, key->n);" seems to return a different result in each run (m, s and key stay the same); the first 4 "words" in m1 don't match m and are "random" (the other words match the expected result). (gdb) x/32xg m._mp_d 0xac9710: 0x804beb2263eecc36 0x6504286b7a368e8c 0xac9720: 0xb1a9862f7b773403 0xec5c042715893b74 0xac9730: 0x0304020105000420 0x0d06096086480165 0xac9740: 0xffffffff00303130 0xffffffffffffffff 0xac9750: 0xffffffffffffffff 0xffffffffffffffff 0xac9760: 0xffffffffffffffff 0xffffffffffffffff 0xac9770: 0xffffffffffffffff 0xffffffffffffffff 0xac9780: 0xffffffffffffffff 0xffffffffffffffff 0xac9790: 0xffffffffffffffff 0xffffffffffffffff 0xac97a0: 0xffffffffffffffff 0xffffffffffffffff 0xac97b0: 0xffffffffffffffff 0xffffffffffffffff 0xac97c0: 0xffffffffffffffff 0xffffffffffffffff 0xac97d0: 0xffffffffffffffff 0xffffffffffffffff 0xac97e0: 0xffffffffffffffff 0xffffffffffffffff 0xac97f0: 0xffffffffffffffff 0xffffffffffffffff 0xac9800: 0xffffffffffffffff 0x0001ffffffffffff (gdb) x/32xg m1._mp_d 0xaddd00: 0x8b1c70bfdd2f162b 0x1a4525131c2f0f68 0xaddd10: 0x1d73f063c3e85044 0x9d6de468135ddd4e 0xaddd20: 0x0304020105000420 0x0d06096086480165 0xaddd30: 0xffffffff00303130 0xffffffffffffffff 0xaddd40: 0xffffffffffffffff 0xffffffffffffffff 0xaddd50: 0xffffffffffffffff 0xffffffffffffffff 0xaddd60: 0xffffffffffffffff 0xffffffffffffffff 0xaddd70: 0xffffffffffffffff 0xffffffffffffffff 0xaddd80: 0xffffffffffffffff 0xffffffffffffffff 0xaddd90: 0xffffffffffffffff 0xffffffffffffffff 0xaddda0: 0xffffffffffffffff 0xffffffffffffffff 0xadddb0: 0xffffffffffffffff 0xffffffffffffffff 0xadddc0: 0xffffffffffffffff 0xffffffffffffffff 0xadddd0: 0xffffffffffffffff 0xffffffffffffffff 0xaddde0: 0xffffffffffffffff 0xffffffffffffffff 0xadddf0: 0xffffffffffffffff 0x0001ffffffffffff I don't see how this relates to the bisected commit, but maybe someone else does. Reproduce using: - a go program replaying the server part of the connection (also "supporting" http connect for curl) - "gnutls-cli -d3 duckduckgo.com" (with "127.0.0.1 duckduckgo.com" in /etc/hosts) - or "curl -x http://127.0.0.1:9090 https://duckduckgo.com" gnutls-cli -d3 output (skipping the "initial asserts"): [...] Resolving 'duckduckgo.com:9090'... Connecting to '127.0.0.1:9090'... |<3>| ASSERT: constate.c[_gnutls_epoch_get]:600 |<3>| ASSERT: buffers.c[get_last_packet]:1159 |<3>| ASSERT: buffers.c[get_last_packet]:1159 |<3>| ASSERT: buffers.c[get_last_packet]:1159 - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 - subject `C=US,ST=Pennsylvania,L=Paoli,O=Duck Duck Go\, Inc.,CN=*.duckduckgo.com', issuer `C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA', serial 0x07622fe9d08fe56097dc5943b673cb02, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-05-25 00:00:00 UTC', expires `2017-07-26 12:00:00 UTC', SHA-1 fingerprint `cdb31f6fe0974565227249bb1ad08b1747b5ec61' Public Key ID: 5c1d8e326fef9f3f52c84838b50e91bca7436c23 Public key's random art: +--[ RSA 2048]----+ | . . . | | + = . | | + B + | | E # + | | S @ o . | | + + o . | | . . . | | . . o | | ..+.o| +-----------------+ - Certificate[1] info: |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 - subject `C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA', issuer `C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA', serial 0x01fda3eb6eca75c888438b724bcfbc91, RSA key 2048 bits, signed using RSA-SHA256, activated `2013-03-08 12:00:00 UTC', expires `2023-03-08 12:00:00 UTC', SHA-1 fingerprint `1fb86b1168ec743154062e8c9cc5b171a4b7ccb4' |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 |<3>| ASSERT: ocsp.c[find_signercert]:1888 |<3>| ASSERT: common.c[_gnutls_x509_der_encode]:860 |<3>| ASSERT: ocsp.c[find_signercert]:1942 |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 |<3>| ASSERT: ocsp.c[gnutls_ocsp_resp_verify]:2200 |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 |<3>| ASSERT: ocsp.c[find_signercert]:1888 |<3>| ASSERT: common.c[_gnutls_x509_der_encode]:860 |<3>| ASSERT: ocsp.c[find_signercert]:1942 |<3>| ASSERT: ocsp.c[gnutls_ocsp_resp_get_single]:1541 |<3>| ASSERT: common.c[x509_read_value]:693 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: common.c[x509_read_value]:693 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 |<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 |<3>| ASSERT: mpi.c[_gnutls_x509_read_uint]:246 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 |<3>| ASSERT: common.c[x509_read_value]:693 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 |<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 |<3>| ASSERT: common.c[x509_read_value]:693 - Status: The certificate is trusted. |<3>| ASSERT: buffers.c[get_last_packet]:1159 |<2>| received curve SECP256R1 |<3>| ASSERT: pk.c[_wrap_nettle_pk_verify]:756 |<3>| ASSERT: pubkey.c[pubkey_verify_hashed_data]:1911 |<3>| ASSERT: tls-sig.c[verify_tls_hash]:270 |<3>| ASSERT: tls-sig.c[_gnutls_handshake_verify_data]:365 |<3>| ASSERT: cert.c[_gnutls_proc_dhe_signature]:2213 |<3>| ASSERT: kx.c[_gnutls_recv_server_kx_message]:513 |<3>| ASSERT: handshake.c[handshake_client]:2847 *** Fatal error: Public key signature verification has failed. *** handshake has failed: Public key signature verification has failed. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-test-responder.go Type: text/x-go Size: 22739 bytes Desc: not available URL: From stbuehler at lighttpd.net Wed Sep 21 00:07:11 2016 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Wed, 21 Sep 2016 00:07:11 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <01bd5333-5b59-f1c8-6ab7-185ddc8341c8@stbuehler.de> References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <01bd5333-5b59-f1c8-6ab7-185ddc8341c8@stbuehler.de> Message-ID: Hi, Sorry. My fault - the server key exchange fails of course due to the mismatching client random, which is included in the key exchange signature... Also I confused m and m1, so the power function always returned the same data, just the hash didn't match it. It's obviously already too late :) Sorry again. I hope the go program still is useful; just need a way to fix the client random to the original value. On 09/20/2016 11:36 PM, Stefan B?hler wrote: > Hi, > > I can reproduce the problem by simply responding with the same data as > shown in the PCAP file. (I'll try to describe it at the bottom). > > It fails to verify the signature in the server key exchange: > > (gdb) bt > #0 _nettle_rsa_verify (key=key at entry=0x7fffffffa7b0, m=m at entry=0x7fffffffa710, s=s at entry=0xad6f90) at rsa-verify.c:59 > #1 0x00007ffff678cc7b in nettle_rsa_pkcs1_verify (key=key at entry=0x7fffffffa7b0, length=, digest_info=0xadf890 "010\r\006\t`\206H\001e\003\004\002\001\005", s=0xad6f90) at rsa-pkcs1-verify.c:53 > #2 0x00007ffff7b7c211 in _wrap_nettle_pk_verify (algo=, vdata=0x7fffffffa840, signature=, pk_params=0xadf5f8) at pk.c:750 > #3 0x00007ffff7ad2dbd in _pkcs1_rsa_verify_sig (me=me at entry=0x7ffff7dd2d10 , text=text at entry=0x0, prehash=, signature=0x7fffffffab20, params=) at pubkey.c:1827 > #4 0x00007ffff7ad56a2 in pubkey_verify_hashed_data (pk=GNUTLS_PK_RSA, hash_algo=0x7ffff7dd2d10 , hash=0x7fffffffa960, signature=0x7fffffffab20, issuer_params=0xadf5f8) at pubkey.c:1908 > #5 0x00007ffff7ac5cac in verify_tls_hash (session=session at entry=0xac7710, ver=ver at entry=0x7ffff7dd30c0 , cert=cert at entry=0x7fffffffab30, hash_concat=hash_concat at entry=0x7fffffffa9e0, > signature=signature at entry=0x7fffffffab20, sha1pos=sha1pos at entry=0, sign_algo=GNUTLS_SIGN_RSA_SHA256, pk_algo=GNUTLS_PK_RSA) at tls-sig.c:266 > #6 0x00007ffff7ac63f7 in _gnutls_handshake_verify_data (session=session at entry=0xac7710, cert=cert at entry=0x7fffffffab30, params=params at entry=0x7fffffffaba0, signature=signature at entry=0x7fffffffab20, > sign_algo=sign_algo at entry=GNUTLS_SIGN_RSA_SHA256) at tls-sig.c:360 > #7 0x00007ffff7b4594a in _gnutls_proc_dhe_signature (session=session at entry=0xac7710, data=, data at entry=0xad9535 "\004\001\001", _data_size=_data_size at entry=260, vparams=vparams at entry=0x7fffffffaba0) at cert.c:2207 > #8 0x00007ffff7b4e32d in proc_ecdhe_server_kx (session=0xac7710, data=0xad94f0 "\003", _data_size=329) at ecdhe.c:310 > #9 0x00007ffff7ab5454 in _gnutls_recv_server_kx_message (session=session at entry=0xac7710) at kx.c:506 > #10 0x00007ffff7ab0908 in handshake_client (session=0xac7710) at handshake.c:2845 > #11 gnutls_handshake (session=0xac7710) at handshake.c:2597 > #12 0x0000000000409c0d in do_handshake (socket=socket at entry=0x7fffffffc160) at cli.c:1673 > #13 0x000000000040c917 in socket_open (hd=hd at entry=0x7fffffffc160, hostname=, service=service at entry=0x618d60 "9090", app_proto=, flags=, msg=msg at entry=0x41066b "Connecting to", > rdata=) at socket.c:493 > #14 0x000000000040732c in main (argc=, argv=) at cli.c:1222 > > "mpz_powm(m1, s, key->e, key->n);" seems to return a different result > in each run (m, s and key stay the same); the first 4 "words" in > m1 don't match m and are "random" (the other words match the expected > result). > > (gdb) x/32xg m._mp_d > 0xac9710: 0x804beb2263eecc36 0x6504286b7a368e8c > 0xac9720: 0xb1a9862f7b773403 0xec5c042715893b74 > 0xac9730: 0x0304020105000420 0x0d06096086480165 > 0xac9740: 0xffffffff00303130 0xffffffffffffffff > 0xac9750: 0xffffffffffffffff 0xffffffffffffffff > 0xac9760: 0xffffffffffffffff 0xffffffffffffffff > 0xac9770: 0xffffffffffffffff 0xffffffffffffffff > 0xac9780: 0xffffffffffffffff 0xffffffffffffffff > 0xac9790: 0xffffffffffffffff 0xffffffffffffffff > 0xac97a0: 0xffffffffffffffff 0xffffffffffffffff > 0xac97b0: 0xffffffffffffffff 0xffffffffffffffff > 0xac97c0: 0xffffffffffffffff 0xffffffffffffffff > 0xac97d0: 0xffffffffffffffff 0xffffffffffffffff > 0xac97e0: 0xffffffffffffffff 0xffffffffffffffff > 0xac97f0: 0xffffffffffffffff 0xffffffffffffffff > 0xac9800: 0xffffffffffffffff 0x0001ffffffffffff > (gdb) x/32xg m1._mp_d > 0xaddd00: 0x8b1c70bfdd2f162b 0x1a4525131c2f0f68 > 0xaddd10: 0x1d73f063c3e85044 0x9d6de468135ddd4e > 0xaddd20: 0x0304020105000420 0x0d06096086480165 > 0xaddd30: 0xffffffff00303130 0xffffffffffffffff > 0xaddd40: 0xffffffffffffffff 0xffffffffffffffff > 0xaddd50: 0xffffffffffffffff 0xffffffffffffffff > 0xaddd60: 0xffffffffffffffff 0xffffffffffffffff > 0xaddd70: 0xffffffffffffffff 0xffffffffffffffff > 0xaddd80: 0xffffffffffffffff 0xffffffffffffffff > 0xaddd90: 0xffffffffffffffff 0xffffffffffffffff > 0xaddda0: 0xffffffffffffffff 0xffffffffffffffff > 0xadddb0: 0xffffffffffffffff 0xffffffffffffffff > 0xadddc0: 0xffffffffffffffff 0xffffffffffffffff > 0xadddd0: 0xffffffffffffffff 0xffffffffffffffff > 0xaddde0: 0xffffffffffffffff 0xffffffffffffffff > 0xadddf0: 0xffffffffffffffff 0x0001ffffffffffff > > I don't see how this relates to the bisected commit, but maybe someone > else does. > > Reproduce using: > - a go program replaying the server part of the connection (also "supporting" http connect for curl) > - "gnutls-cli -d3 duckduckgo.com" (with "127.0.0.1 duckduckgo.com" in /etc/hosts) > - or "curl -x http://127.0.0.1:9090 https://duckduckgo.com" > > gnutls-cli -d3 output (skipping the "initial asserts"): > [...] > Resolving 'duckduckgo.com:9090'... > Connecting to '127.0.0.1:9090'... > |<3>| ASSERT: constate.c[_gnutls_epoch_get]:600 > |<3>| ASSERT: buffers.c[get_last_packet]:1159 > |<3>| ASSERT: buffers.c[get_last_packet]:1159 > |<3>| ASSERT: buffers.c[get_last_packet]:1159 > - Certificate type: X.509 > - Got a certificate list of 2 certificates. > - Certificate[0] info: > |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 > |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > - subject `C=US,ST=Pennsylvania,L=Paoli,O=Duck Duck Go\, Inc.,CN=*.duckduckgo.com', issuer `C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA', serial 0x07622fe9d08fe56097dc5943b673cb02, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-05-25 00:00:00 UTC', expires `2017-07-26 12:00:00 UTC', SHA-1 fingerprint `cdb31f6fe0974565227249bb1ad08b1747b5ec61' > Public Key ID: > 5c1d8e326fef9f3f52c84838b50e91bca7436c23 > Public key's random art: > +--[ RSA 2048]----+ > | . . . | > | + = . | > | + B + | > | E # + | > | S @ o . | > | + + o . | > | . . . | > | . . o | > | ..+.o| > +-----------------+ > > - Certificate[1] info: > |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 > |<3>| ASSERT: dn.c[_gnutls_x509_parse_dn]:250 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > - subject `C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA', issuer `C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert Global Root CA', serial 0x01fda3eb6eca75c888438b724bcfbc91, RSA key 2048 bits, signed using RSA-SHA256, activated `2013-03-08 12:00:00 UTC', expires `2023-03-08 12:00:00 UTC', SHA-1 fingerprint `1fb86b1168ec743154062e8c9cc5b171a4b7ccb4' > |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 > |<3>| ASSERT: ocsp.c[find_signercert]:1888 > |<3>| ASSERT: common.c[_gnutls_x509_der_encode]:860 > |<3>| ASSERT: ocsp.c[find_signercert]:1942 > |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 > |<3>| ASSERT: ocsp.c[gnutls_ocsp_resp_verify]:2200 > |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1516 > |<3>| ASSERT: ocsp.c[find_signercert]:1888 > |<3>| ASSERT: common.c[_gnutls_x509_der_encode]:860 > |<3>| ASSERT: ocsp.c[find_signercert]:1942 > |<3>| ASSERT: ocsp.c[gnutls_ocsp_resp_get_single]:1541 > |<3>| ASSERT: common.c[x509_read_value]:693 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: common.c[x509_read_value]:693 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: dn.c[_gnutls_x509_compare_raw_dn]:919 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > |<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > |<3>| ASSERT: mpi.c[_gnutls_x509_read_uint]:246 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > |<3>| ASSERT: common.c[x509_read_value]:693 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > |<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 > |<3>| ASSERT: extensions.c[_gnutls_get_extension]:65 > |<3>| ASSERT: common.c[x509_read_value]:693 > - Status: The certificate is trusted. > |<3>| ASSERT: buffers.c[get_last_packet]:1159 > |<2>| received curve SECP256R1 > |<3>| ASSERT: pk.c[_wrap_nettle_pk_verify]:756 > |<3>| ASSERT: pubkey.c[pubkey_verify_hashed_data]:1911 > |<3>| ASSERT: tls-sig.c[verify_tls_hash]:270 > |<3>| ASSERT: tls-sig.c[_gnutls_handshake_verify_data]:365 > |<3>| ASSERT: cert.c[_gnutls_proc_dhe_signature]:2213 > |<3>| ASSERT: kx.c[_gnutls_recv_server_kx_message]:513 > |<3>| ASSERT: handshake.c[handshake_client]:2847 > *** Fatal error: Public key signature verification has failed. > *** handshake has failed: Public key signature verification has failed. > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Wed Sep 21 08:40:47 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Sep 2016 08:40:47 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> Message-ID: On Tue, Sep 20, 2016 at 8:51 PM, marcelomendes at gmail.com wrote: > Thanks, I'm attaching the logs. > First I tried a git pull with libgnutls30 3.5.4, which gave me the > handshaking error, then I downgraded to 3.5.2-3, and, as you can see > at the end of the file, the pull ran well. Thank you, that was very helpful. gnutls[4]: HSK[0x2d932b0]: verify handshake data: using RSA-SHA256 gnutls[3]: ASSERT: pk.c[_wrap_nettle_pk_verify]:740 The lines above indicate that the failure is at the check: "if (signature->size != pub.size)" We don't have the values here, however, what changed since 3.5.2 is that nettle is now calculating pub.size in rsa_public_key_prepare() while previously it was directly calculated as "nettle_mpz_sizeinbase_256_u(pub->n);" According to the capture signature->size is 256 bytes and in the certificate the modulus is 2048-bits (256 bytes). The signature starts with "44c5...", while the modulus with "f245...". The latter makes me suspect that rsa_public_key_prepare() could have calculated size as 257 (assuming it had added a 00 ahead of f2 to make it non-negative). Let's see how rsa_public_key_prepare does calculate size. It sets size as "(mpz_sizeinbase(n, 2) + 7) / 8;" . Interestingly nettle_mpz_sizeinbase_256_u() also calculates that size as "(mpz_sizeinbase(x,2) + 7) / 8", so they should have been equal. In fact they are equal on every system I've tried but yours... So I am wondering whether I have missed something here. Running the example program I sent, as well as this under valgrind may provide more information. regards, Nikos From nmav at gnutls.org Wed Sep 21 08:49:25 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Sep 2016 08:49:25 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <01bd5333-5b59-f1c8-6ab7-185ddc8341c8@stbuehler.de> Message-ID: On Wed, Sep 21, 2016 at 12:07 AM, Stefan B?hler wrote: > Hi, > Sorry. My fault - the server key exchange fails of course > due to the mismatching client random, which is included in > the key exchange signature... Right. You can overcome this by using gnutls_handshake_set_random(), however you have to also match the ciphersuites sent (and order), as well as the extensions. The latter part is the hardest, and made me gave up on a proper simulator. > Also I confused m and m1, so the power function always > returned the same data, just the hash didn't match it. > It's obviously already too late :) Note that you also proceeded past the signature size check at which Marcelo's system fails. > Sorry again. I hope the go program still is useful; > just need a way to fix the client random to the original > value. A simulator would have certainly be very helpful to have for debugging such issues. I am not fluent in go so I have not yet checked the server, but my approach was to use a file to store server's messages, and registered a custom pull function for the client. That pull function was reading from that file to feed the client's session. regards, Nikos From nmav at gnutls.org Wed Sep 21 21:05:34 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 21 Sep 2016 21:05:34 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: References: <20160826171846.hdyq5vbo42wdoybq@argenau.bebt.de> <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> Message-ID: <1474484734.2322.0.camel@gnutls.org> On Wed, 2016-09-21 at 12:38 -0400, marcelomendes at gmail.com wrote: > 2016-09-20 14:21 GMT-04:00 Nikos Mavrogiannopoulos : > > > > On Tue, Sep 20, 2016 at 2:25 PM, Nikos Mavrogiannopoulos > > wrote: > > > > > > On Tue, Sep 20, 2016 at 8:56 AM, Nikos Mavrogiannopoulos > > > wrote: > > > > > > > > I do not see anything wrong in the capture. I even created a > > > > small > > > > program to replay the connection locally (I have a debian > > > > installation > > > > on x86_64 with the same packages available), and the connection > > > > continued past the failure point on that system. > > > > > > > > I'm searching in the dark here, but the following info could > > > > help: > > > > 3. compile the attached program as "gcc -O2 -g sim.c -lgmp > > > > -lhogweed && > > > > ./a.out", and also run valgrind ./a.out > The result of the commands are the same for both versions of > libgnutls30 (you don't have to run with both versions, the one that causes the issue is sufficient). Do you have a valgrind output of curl or another command that fails to run? regards, Nikos From ametzler at bebt.de Fri Sep 23 18:55:47 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 23 Sep 2016 18:55:47 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474484734.2322.0.camel@gnutls.org> References: <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <1474484734.2322.0.camel@gnutls.org> Message-ID: <20160923165547.3fqowu75ibkdhqvm@argenau.bebt.de> Looks like this response did not make it to the list: ----- Forwarded message from "marcelomendes at gmail.com" ----- 2016-09-21 15:05 GMT-04:00 Nikos Mavrogiannopoulos : > On Wed, 2016-09-21 at 12:38 -0400, marcelomendes at gmail.com wrote: >> 2016-09-20 14:21 GMT-04:00 Nikos Mavrogiannopoulos : >>> On Tue, Sep 20, 2016 at 2:25 PM, Nikos Mavrogiannopoulos >>> wrote: >>>> On Tue, Sep 20, 2016 at 8:56 AM, Nikos Mavrogiannopoulos >>>> wrote: >>>>> I do not see anything wrong in the capture. I even created a >>>>> small >>>>> program to replay the connection locally (I have a debian >>>>> installation >>>>> on x86_64 with the same packages available), and the connection >>>>> continued past the failure point on that system. >>>>> I'm searching in the dark here, but the following info could >>>>> help: >>>>> 3. compile the attached program as "gcc -O2 -g sim.c -lgmp >>>>> -lhogweed && >>>>> ./a.out", and also run valgrind ./a.out >> The result of the commands are the same for both versions of >> libgnutls30 > (you don't have to run with both versions, the one that causes the > issue is sufficient). > Do you have a valgrind output of curl or another command that fails to > run? Sure! http://pastebin.com/m5Ks6uzZ -- "Free Software is not the only way, but it's a correct way." Marcelo Mendes http://underlabs.org mmendes @ IRC [OFTC-Freenode] Gtalk: marcelomendes at gmail dot com ----- End forwarded message ----- From nmav at gnutls.org Fri Sep 23 20:38:59 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 23 Sep 2016 20:38:59 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <20160923165547.3fqowu75ibkdhqvm@argenau.bebt.de> References: <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <1474484734.2322.0.camel@gnutls.org> <20160923165547.3fqowu75ibkdhqvm@argenau.bebt.de> Message-ID: <1474655939.2393.9.camel@gnutls.org> On Fri, 2016-09-23 at 18:55 +0200, Andreas Metzler wrote: > Looks like this response did not make it to the list: To summarize the issue. It seems that the programs that failed were indirectly linked with both libhogweed.so.2 and libhogweed.so.4. The structure of rsa_public_key on these two libraries, is different, the size symbol is 64-bits in one and 32-bits on the other. The libhogweed.4 also contains versioned symbols, whilst the .2 is unversioned. If gnutls for some reason was calling the?rsa_public_key_prepare of the unversioned library it would explain the failure Marcelo encountered. The question if someone wants to dig it further, is why would the unversioned rsa_public_key_prepare would be called, especially since gnutls was linked against the versioned library. regards, Nikos From ametzler at bebt.de Sat Sep 24 07:42:25 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 24 Sep 2016 07:42:25 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474655939.2393.9.camel@gnutls.org> References: <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <1474484734.2322.0.camel@gnutls.org> <20160923165547.3fqowu75ibkdhqvm@argenau.bebt.de> <1474655939.2393.9.camel@gnutls.org> Message-ID: <20160924054225.3i76dw2xrsgjrwur@argenau.bebt.de> On 2016-09-23 Nikos Mavrogiannopoulos wrote: > On Fri, 2016-09-23 at 18:55 +0200, Andreas Metzler wrote: >> Looks like this response did not make it to the list: > To summarize the issue. It seems that the programs that failed were > indirectly linked with both libhogweed.so.2 and libhogweed.so.4. The > structure of rsa_public_key on these two libraries, is different, the > size symbol is 64-bits in one and 32-bits on the other. The > libhogweed.4 also contains versioned symbols, whilst the .2 is > unversioned. If gnutls for some reason was calling > the?rsa_public_key_prepare of the unversioned library it would explain > the failure Marcelo encountered. > The question if someone wants to dig it further, is why would the > unversioned rsa_public_key_prepare would be called, especially since > gnutls was linked against the versioned library. I am pretty sure that happened because the involved very old librmtp library was not built against versioned nettle. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nisse at lysator.liu.se Tue Sep 27 15:22:02 2016 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Tue, 27 Sep 2016 15:22:02 +0200 Subject: [gnutls-devel] Problem with proxied connections on 3.5.3 In-Reply-To: <1474655939.2393.9.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 23 Sep 2016 20:38:59 +0200") References: <20160916172830.cucm7kimg3s3e7tq@argenau.bebt.de> <1474105750.1994.6.camel@gmail.com> <20160917104840.bpskbjllf25vz4it@argenau.bebt.de> <1474128467.2008.7.camel@gmail.com> <20160919165304.r5dehmq7ma7f4zfq@argenau.bebt.de> <1474354579.2112.5.camel@gnutls.org> <1474484734.2322.0.camel@gnutls.org> <20160923165547.3fqowu75ibkdhqvm@argenau.bebt.de> <1474655939.2393.9.camel@gnutls.org> Message-ID: Nikos Mavrogiannopoulos writes: > On Fri, 2016-09-23 at 18:55 +0200, Andreas Metzler wrote: > To summarize the issue. It seems that the programs that failed were > indirectly linked with both libhogweed.so.2 and libhogweed.so.4. The > structure of rsa_public_key on these two libraries, is different, the > size symbol is 64-bits in one and 32-bits on the other. The > libhogweed.4 also contains versioned symbols, whilst the .2 is > unversioned. If gnutls for some reason was calling > the rsa_public_key_prepare of the unversioned library it would explain > the failure Marcelo encountered. Thanks for the analysis. Regards, /Niels -- Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. From tn at osimis.io Thu Sep 29 14:01:58 2016 From: tn at osimis.io (Thibault =?ISO-8859-1?Q?N=E9lis?=) Date: Thu, 29 Sep 2016 14:01:58 +0200 Subject: [gnutls-devel] [feature request] certtool: Cleanup output file on error Message-ID: <1475150518.2510.12.camel@osimis.io> Hello, Currently the output file (as specified with --outfile) is created no matter what and left behind in case of an error. $ file foo foo: cannot open `foo' (No such file or directory) $ certtool --generate-request --load-privkey=foo --outfile=bar Generating a PKCS #10 certificate request... reading --load-privkey: foo $ echo $? 1 $ file bar bar: empty $ certtool --version=v certtool 3.4.14 $ rpm --query gnutls-utils? gnutls-utils-3.4.14-1.fc23.x86_64 These semantics are definitely OK, but I find they make it a little bit cumbersome to use certtool in automated procedures that can't afford to leave empty files around. Would it be reasonable for --outfile to remove the file in case of an error, or even avoid creating it (or just avoid linking it) in the first place when it errors-out? Side-request: Some diagnostic messages on stderr would be NTH as well. Thank you for considering this. -t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From nmav at gnutls.org Fri Sep 30 10:18:25 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 30 Sep 2016 10:18:25 +0200 Subject: [gnutls-devel] [feature request] certtool: Cleanup output file on error In-Reply-To: <1475150518.2510.12.camel@osimis.io> References: <1475150518.2510.12.camel@osimis.io> Message-ID: On Thu, Sep 29, 2016 at 2:01 PM, Thibault N?lis wrote: > Hello, > > Currently the output file (as specified with --outfile) is created no > matter what and left behind in case of an error. > $ file foo > foo: cannot open `foo' (No such file or directory) > $ certtool --generate-request --load-privkey=foo --outfile=bar > Generating a PKCS #10 certificate request... > reading --load-privkey: foo [...] > Thank you for considering this. It would be much for efficient if you propose a fix for these features with a patch. regards, Nikos From tn at osimis.io Fri Sep 30 12:04:18 2016 From: tn at osimis.io (Thibault =?ISO-8859-1?Q?N=E9lis?=) Date: Fri, 30 Sep 2016 12:04:18 +0200 Subject: [gnutls-devel] [feature request] certtool: Cleanup output file on error In-Reply-To: References: <1475150518.2510.12.camel@osimis.io> Message-ID: <1475229858.4040.1.camel@osimis.io> On Fri, 2016-09-30 at 10:18 +0200, Nikos Mavrogiannopoulos wrote: > It would be much for efficient if you propose a fix for these > features with a patch. Sure, sorry. https://gitlab.com/gnutls/gnutls/merge_requests/96 https://gitlab.com/gnutls/gnutls/merge_requests/97 -t -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: