Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-06-17T18:30:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32688Make tor_tls_get_buffer_sizes() work again2022-06-17T18:30:22ZNick MathewsonMake tor_tls_get_buffer_sizes() work againWhere supported, Tor uses OpenSSL skulduggery to find out how much RAM openssl has allocated and/or is using for buffers in each SSL object, and . This information is only used for logging right now (in `dumpstats()`), but it has potent...Where supported, Tor uses OpenSSL skulduggery to find out how much RAM openssl has allocated and/or is using for buffers in each SSL object, and . This information is only used for logging right now (in `dumpstats()`), but it has potential use in our OOM/DOS prevention code.
The tricks that we used up till now no longer actually work with OpenSSL 1.1.0, however, since the relevant structures are now opaque. We'll either need to find another way to get their sizes, or add some API to OpenSSL to expose them.
This is low-priority, unless we actually have time to use this information in OOM calculation.https://gitlab.torproject.org/tpo/core/tor/-/issues/19981Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed2021-09-16T14:33:30ZNick MathewsonMake sure we build with OpenSSL 1.1.0 with all deprecated APIs removedThere's an option to build openssl 1.1.0 with all the deprecated APIs turned off. We should make sure that Tor still works without using any of those.There's an option to build openssl 1.1.0 with all the deprecated APIs turned off. We should make sure that Tor still works without using any of those.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19979Use OpenSSL 1.1.0 HKDF in Tor when available.2021-09-16T14:33:30ZNick MathewsonUse OpenSSL 1.1.0 HKDF in Tor when available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.OpenSSL 1.1.0 now includes HKDF support. We should consider using their implementation instead of ours when it's available.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/19429Clean up our OpenSSL 1.1 support.2021-09-16T14:33:30ZYawning AngelClean up our OpenSSL 1.1 support.In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we...In an ideal world, we should support OpenSSL 1.1 built with the deprecated APIs entirely disabled. Additionally while the code that uses the new opaque wrappers for the RSA stuff is functional and maintainable, it would be cleaner if we provided our own wrappers for a more unified codepath.
Neither of these are high priority as the current code works, the changes suggested would just make things better.Tor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19983Is openssl 1.1.0's "secure heap" feature useful for us?2021-08-23T15:17:06ZNick MathewsonIs openssl 1.1.0's "secure heap" feature useful for us?Found out about this in the 1.1.0 changelog. Maybe it could be something to take advantage of.Found out about this in the 1.1.0 changelog. Maybe it could be something to take advantage of.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32871Static linking issue with OpenSSL2021-07-09T17:22:51ZTracStatic linking issue with OpenSSLThere is a static linking issue with OpenSSL, link order of libz must be adjusted to solve bug with static linking and host paths must be removed when looking for openssl.
The patch is available at https://git.buildroot.net/buildroot/tr...There is a static linking issue with OpenSSL, link order of libz must be adjusted to solve bug with static linking and host paths must be removed when looking for openssl.
The patch is available at https://git.buildroot.net/buildroot/tree/package/tor/0001-Fix-static-linking-with-OpenSSL.patch
**Trac**:
**Username**: ffontainehttps://gitlab.torproject.org/tpo/core/tor/-/issues/33624Static building tor with openssl does not work2021-02-06T05:05:34ZDavid Gouletdgoulet@torproject.orgStatic building tor with openssl does not workWe have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which ...We have couple opened ticket about building OpenSSL statically: legacy/trac#31565 and legacy/trac#32871 are the one I could find.
I've been working on this to measure the size of tor as a shared library for mobile environment for which we need to build tor with openssl and libevent statically.
At current master, this is not working for build system and code reasons.
This ticket is to address it all so we can close all other related tickets.
Here is a raw tor.git diff that makes this work. There is still some think to consider especially with the `OPENSSL_VERSION`:
https://gitlab.torproject.org/dgoulet/tor-library-size/blob/master/tor.diffTor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/32773Remove Jenkins tor master jobs which don't have OpenSSL 1.1.12021-02-05T21:03:36ZteorRemove Jenkins tor master jobs which don't have OpenSSL 1.1.1These jenkins tor master builds will fail after legacy/trac#31820 merges:
* jessie: OpenSSL 1.0.1t
* stretch: OpenSSL 1.1.0
* xenial: OpenSSL 1.0.2g
I don't know how to change jenkins configs. We may need a jenkins patch before we put ...These jenkins tor master builds will fail after legacy/trac#31820 merges:
* jessie: OpenSSL 1.0.1t
* stretch: OpenSSL 1.1.0
* xenial: OpenSSL 1.0.2g
I don't know how to change jenkins configs. We may need a jenkins patch before we put this task in the jenkins component.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-09-23T13:43:20ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-07-29T13:10:29ZTracstatic Tor building against openssl-1.1.1 fails: configure unable to find linkable OpenSSLTrying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4...Trying to cross build static Tor on Linux with mingw (to use on Windows-x86). It seems configure cannot find OpenSSL if its version is not 1.0.2. Tried openssl-1.1.0 and openssl-1.1.1, and also different Tor versions from 0.3.5.XX to 0.4.0.5 and 0.4.1.5. Building against openssl-1.0.2 works.
**Trac**:
**Username**: shredderTor: 0.4.5.x-freezehttps://gitlab.torproject.org/tpo/core/tor/-/issues/27593Call CRYPTO_set_mem_functions with tor_malloc, tor_realloc and tor_free2020-07-28T22:58:51Zrl1987Call CRYPTO_set_mem_functions with tor_malloc, tor_realloc and tor_freelegacy/trac#8415 deals with attaching our memory management code to libevent. We should do the same with OpenSSL.
Note that OpenSSL had some API changes in last few years in this area.legacy/trac#8415 deals with attaching our memory management code to libevent. We should do the same with OpenSSL.
Note that OpenSSL had some API changes in last few years in this area.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25957Tor 0.3.3.5-rc died: Caught signal 112020-07-28T19:04:24ZTracTor 0.3.3.5-rc died: Caught signal 11from tor.log (tor server: devuan 8A00CE9638BDB4686B91F1F0B229DB3F8C9B8415):
.../...
Apr 28 00:58:53.000 [notice] Heartbeat: Tor's uptime is 23:59 hours, with 9698 circuits open. I've sent 556.38 GB and received 553.75 GB.
Apr 28 00:58:53...from tor.log (tor server: devuan 8A00CE9638BDB4686B91F1F0B229DB3F8C9B8415):
.../...
Apr 28 00:58:53.000 [notice] Heartbeat: Tor's uptime is 23:59 hours, with 9698 circuits open. I've sent 556.38 GB and received 553.75 GB.
Apr 28 00:58:53.000 [notice] Circuit handshake stats since last time: 21677/21677 TAP, 252349/252349 NTor.
Apr 28 00:58:53.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 1 v3 connections, and 16330 v4 connections; and received 36 v1 connections, 8546 v2 connections, 13955 v3 connections, and 12846 v4 connections.
Apr 28 00:58:53.000 [notice] DoS mitigation since startup: 0 circuits rejected, 0 marked addresses. 0 connections closed. 294 single hop clients refused.
```
============================================================ T= 1524879769
Tor 0.3.3.5-rc died: Caught signal 11
tor(+0x189059)[0x558d01f7c059]
/lib/x86_64-linux-gnu/libc.so.6(+0x791d5)[0x7f201753e1d5]
/lib/x86_64-linux-gnu/libc.so.6(+0x791d5)[0x7f201753e1d5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f201753ff64]
/usr/local/lib/libssl.so.1.1(+0x24f40)[0x7f2018ca4f40]
/usr/local/lib/libssl.so.1.1(+0x24b25)[0x7f2018ca4b25]
/usr/local/lib/libssl.so.1.1(+0x2baec)[0x7f2018cabaec]
/usr/local/lib/libssl.so.1.1(+0x374d0)[0x7f2018cb74d0]
/usr/local/lib/libssl.so.1.1(SSL_read+0x15)[0x7f2018cb76b5]
tor(tor_tls_read+0x52)[0x558d01fae7a2]
tor(buf_read_from_tls+0xac)[0x558d01fa01dc]
tor(+0x10b9e1)[0x558d01efe9e1]
tor(+0x5367e)[0x558d01e4667e]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f2018f1f5a0]
tor(do_main_loop+0x264)[0x558d01e47694]
tor(tor_run_main+0x275)[0x558d01e48c95]
tor(tor_main+0x3a)[0x558d01e422aa]
tor(main+0x19)[0x558d01e42019]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f20174e52e1]
tor(_start+0x2a)[0x558d01e4206a]
```
**Trac**:
**Username**: Pine64ARMv8Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15918Investigate using the EVP interface for non-oneshot hash calls.2020-07-24T17:32:48ZYawning AngelInvestigate using the EVP interface for non-oneshot hash calls.People have recently asked about VIA PadLock and cryptdev (legacy/trac#15503/some random tor-relays@ post). Both of these things in theory can do SHA1/SHA256 in hardware (though in the case of cryptdev, performance is likely to be worse...People have recently asked about VIA PadLock and cryptdev (legacy/trac#15503/some random tor-relays@ post). Both of these things in theory can do SHA1/SHA256 in hardware (though in the case of cryptdev, performance is likely to be worse).
Since it can be a decent gain (at least PadLock will be), we should consider switching over the `crypto_digest_t` routines to use the EVP interface (People that try to use cryptdev for hashes and suffer a performance decrease did not read the documentation, and thus get what they deserve).
Minor (very low priority) because:
* cryptdev's hash performance will probably suck.
* OpenSSL does not support PadLock SHA acceleration.
* The only hardware SHA implementation that's actually relevant to a significant sized userbase (ARMv8) is supported via the raw `SHA*` routines.
So this is mostly for future-proofing and code cleanup purposes.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15017Experiment: does BIO_f_buffer help performance with read/write syscalls?2020-07-24T17:05:12ZNick MathewsonExperiment: does BIO_f_buffer help performance with read/write syscalls?dgoulet has found that openssl generates lots of small read and write syscalls. Maybe we'd do better to have openssl buffer stuff?
BIO_f_buffer can supposedly help us here. We could buffer reads, writes, or both.
We should see whether...dgoulet has found that openssl generates lots of small read and write syscalls. Maybe we'd do better to have openssl buffer stuff?
BIO_f_buffer can supposedly help us here. We could buffer reads, writes, or both.
We should see whether this helps performance, whether it causes weird bugs, and so on. We should also try to find out how much memory openssl allocates for this stuff, and take that into account for our OOM calculations.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13977Evaluate alternate SSL/TLS libraries: CyaSSL, GnuTLS, ...2020-07-24T16:28:27ZteorEvaluate alternate SSL/TLS libraries: CyaSSL, GnuTLS, ...Is tor able to compile and run against these libraries?
Should we support/recommend them?Is tor able to compile and run against these libraries?
Should we support/recommend them?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40021Pin OSS-Fuzz OpenSSL version to 1.1.12020-07-06T12:24:16ZNick MathewsonPin OSS-Fuzz OpenSSL version to 1.1.1OpenSSL 3.0.0 is badly broken with Tor -- or Tor is badly broken with OpenSSL 3.0.0. (See #34139.) But this has caused Tor to fail on OSS-Fuzz, where the configuration is set up to use OpenSSL master.
So we should change our OSS-Fuzz c...OpenSSL 3.0.0 is badly broken with Tor -- or Tor is badly broken with OpenSSL 3.0.0. (See #34139.) But this has caused Tor to fail on OSS-Fuzz, where the configuration is set up to use OpenSSL master.
So we should change our OSS-Fuzz configuration to use OpenSSL 1.1.1 instead.
We should also plan to revert this change later on, once OpenSSL is fixed.Perhaps we should hold off on this for a few days, in case OpenSSL fixes itself fast?Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1709Fix compilation with mingw and OpenSSL 0.9.8m+2020-06-27T14:09:21ZTracFix compilation with mingw and OpenSSL 0.9.8m+--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+...--- tortls.c.was Tue Jul 13 01:37:00 2010
+++ tortls.c Mon Jul 19 19:17:42 2010
@@ -21,6 +21,17 @@
#endif
#include <assert.h>
+#ifdef MS_WINDOWS /*wrkard for dtls1.h >= 0.9.8m of "#include <winsock.h>"*/
+ #define WIN32_WINNT 0x400
+ #define _WIN32_WINNT 0x400
+ #define WIN32_LEAN_AND_MEAN
+ #if defined(_MSC_VER) && (_MSC_VER < 1300)
+ #include <winsock.h>
+ #else
+ #include <winsock2.h>
+ #include <ws2tcpip.h>
+ #endif
+#endif
#include <openssl/ssl.h>
#include <openssl/ssl3.h>
#include <openssl/err.h>
**Trac**:
**Username**: mingw-sanTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2299TLS decode error while handshaking with OpenSSL 0.9.8o2020-06-27T14:08:52ZTracTLS decode error while handshaking with OpenSSL 0.9.8oI seem to be experiencing TLS decode errors similar to ones reported for Tor 0.2.1.22. I'm running in a private network on Ubuntu 10.10 server.
John
urrtor@urr1:~/tor$ uname -a
Linux urr1 2.6.35-22-generic-pae legacy/trac#35-Ubuntu SM...I seem to be experiencing TLS decode errors similar to ones reported for Tor 0.2.1.22. I'm running in a private network on Ubuntu 10.10 server.
John
urrtor@urr1:~/tor$ uname -a
Linux urr1 2.6.35-22-generic-pae legacy/trac#35-Ubuntu SMP Sat Oct 16 22:16:51 UTC 2010 i686 GNU/Linux
urrtor@urr1:~/tor$ openssl version
OpenSSL 0.9.8o 01 Jun 2010
urrtor@urr1:~/tor$ tor --version
Dec 17 15:42:13.293 [notice] Tor v0.2.1.26 (r12). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Tor version 0.2.1.26 (r12).
urrtor@urr1:~/tor$ grep TLS urr1.log
Dec 17 15:18:45.153 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 9
Dec 17 15:18:45.154 [info] TLS error while handshaking with [scrubbed]: tlsv1 alert decode error (in SSL routines:SSL23_GET_SERVER_HELLO)
Dec 17 15:18:45.155 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 9
Dec 17 15:18:45.155 [info] TLS error while handshaking with [scrubbed]: tlsv1 alert decode error (in SSL routines:SSL23_GET_SERVER_HELLO)
Dec 17 15:19:46.256 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 9
Dec 17 15:19:46.257 [info] TLS error while handshaking with [scrubbed]: tlsv1 alert decode error (in SSL routines:SSL23_GET_SERVER_HELLO)
Dec 17 15:24:51.780 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 9
Dec 17 15:24:51.781 [info] TLS error while handshaking with [scrubbed]: tlsv1 alert decode error (in SSL routines:SSL23_GET_SERVER_HELLO)
Dec 17 15:35:01.836 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 9
Dec 17 15:35:01.837 [info] TLS error while handshaking with [scrubbed]: tlsv1 alert decode error (in SSL routines:SSL23_GET_SERVER_HELLO)
urrtor@urr1:~/tor$
**Trac**:
**Username**: ramsdellhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4008Identify safe, common, useful openssl engines to enable by default2020-06-27T14:07:44ZNick MathewsonIdentify safe, common, useful openssl engines to enable by defaultEver since f0d4b3d1 (svn revision r5829) , all of our crypto acceleration is off by default, since we can't trust any given openssl engine to be secure, stable, and to run without crashing.
We should identify engines which it would be s...Ever since f0d4b3d1 (svn revision r5829) , all of our crypto acceleration is off by default, since we can't trust any given openssl engine to be secure, stable, and to run without crashing.
We should identify engines which it would be safe and useful to turn on by default, and have them be on-by-default. IMO the criteria should be:
* It needs to be pretty common for a user to have the requisite hardware but not know about it. IOW, anybody who has bought a special-purpose board can configure it themselves, but people with CPU or chipset support for acceleration are likely not to have thought about it.
* It needs to be really stable.
* It needs to be pretty well distributed.
* It needs to be using a recent version of openssl.
* It needs to make an actual improvement to Tor's performance or security.
* We need to be able to test it.
Good candidates to look at for a start IMO are aes-ni instructions.
We'll also maybe need a UI change to let people disable default engines and add extra ones.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6055Re-enable TLS 1.1 and TLS 1.2 once they are fixed2020-06-27T14:06:15ZNick MathewsonRe-enable TLS 1.1 and TLS 1.2 once they are fixedSee legacy/trac#6033 for why we needed to disable TLS1.1 and TLS1.2.
We'd like to turn them back on once OpenSSL 1.0.1d comes out with the bugfix. The easiest way to do that will be to make the whole block that disables them conditiona...See legacy/trac#6033 for why we needed to disable TLS1.1 and TLS1.2.
We'd like to turn them back on once OpenSSL 1.0.1d comes out with the bugfix. The easiest way to do that will be to make the whole block that disables them conditional on the compile-time OpenSSL version.
Of course, we'll have the obvious problem: many vendors will only partially backport openssl changes, and will not bump the OpenSSL version when they do so. We should see where and how this is a problem: Right now, Ubuntu 12.04 (LTS!? :( ) seems to be the likeliest place for a problem to occur here, since it's shipping a patched 1.0.1 that it calls 1.0.1-4.
If we decide we need to re-enable TLS on these platforms too, here are the options I can think of:
* Try renegotiation with TLS 1.2 with ourselves at runtime. If that fails, disable TLS 1.1 and TLS 1.2.
* Have a compile-time or runtime option that tells us that openssl has been fixed.Tor: 0.2.4.x-final