Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:13:13Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4008Identify safe, common, useful openssl engines to enable by default2020-06-13T14:13:13ZNick 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/legacy/trac/-/issues/5087configure should realize libssl-dev is missing2013-09-25T16:59:02ZTracconfigure should realize libssl-dev is missingHey Guys,
I thought I would create a new ticket as it doesn't seem to be related to the previous one. I picked up the comments from #5009 and got in so far as autogen.sh and ./configure work perfectly.
My problem now appears to be that...Hey Guys,
I thought I would create a new ticket as it doesn't seem to be related to the previous one. I picked up the comments from #5009 and got in so far as autogen.sh and ./configure work perfectly.
My problem now appears to be that "make" falls over.
Here is the output when I run the command:
root@dragon:~/obfsproxy# make
make all-am
make[1]: Entering directory `/root/obfsproxy'
gcc -DHAVE_CONFIG_H -I. -I./src -Wall -Wwrite-strings -Werror -I/usr/local/include -I/usr/local/include -g -O2 -MT crypt.o -MD -MP -MF .deps/crypt.Tpo -c -o crypt.o `test -f 'src/crypt.c' || echo './'`src/crypt.c
In file included from src/crypt.c:16:
src/crypt.h:58:25: error: openssl/aes.h: No such file or directory
In file included from src/crypt.c:16:
src/crypt.h:66: error: expected specifier-qualifier-list before âAES_KEYâ
src/crypt.c:21:30: error: openssl/opensslv.h: No such file or directory
src/crypt.c:22:25: error: openssl/err.h: No such file or directory
src/crypt.c:23:26: error: openssl/rand.h: No such file or directory
cc1: warnings being treated as errors
src/crypt.c: In function âinitialize_cryptoâ:
src/crypt.c:39: error: implicit declaration of function âERR_load_crypto_stringsâ
src/crypt.c:50: error: implicit declaration of function âperrorâ
src/crypt.c:58: error: implicit declaration of function âRAND_seedâ
src/crypt.c: In function âcleanup_cryptoâ:
src/crypt.c:71: error: implicit declaration of function âERR_free_stringsâ
src/crypt.c: In function âcrypt_newâ:
src/crypt.c:147: error: âAES_BLOCK_SIZEâ undeclared (first use in this function)
src/crypt.c:147: error: (Each undeclared identifier is reported only once
src/crypt.c:147: error: for each function it appears in.)
src/crypt.c:149: error: implicit declaration of function âAES_set_encrypt_keyâ
src/crypt.c:149: error: âcrypt_tâ has no member named âkeyâ
src/crypt.c: In function âcrypt_set_ivâ:
src/crypt.c:160: error: âcrypt_tâ has no member named âivecâ
src/crypt.c:161: error: âcrypt_tâ has no member named âivecâ
src/crypt.c: In function âstream_cryptâ:
src/crypt.c:170: error: implicit declaration of function âAES_ctr128_encryptâ
src/crypt.c:171: error: âcrypt_tâ has no member named âkeyâ
src/crypt.c:171: error: âcrypt_tâ has no member named âivecâ
src/crypt.c:171: error: âcrypt_tâ has no member named âecount_bufâ
src/crypt.c:172: error: âcrypt_tâ has no member named âposâ
src/crypt.c: In function ârandom_bytesâ:
src/crypt.c:196: error: implicit declaration of function âRAND_bytesâ
make[1]: *** [crypt.o] Error 1
make[1]: Leaving directory `/root/obfsproxy'
make: *** [all] Error 2
**Trac**:
**Username**: MonotokoGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/6055Re-enable TLS 1.1 and TLS 1.2 once they are fixed2020-06-13T14:20:16ZNick MathewsonRe-enable TLS 1.1 and TLS 1.2 once they are fixedSee #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 co...See #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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6673tor crashes silently with non-threaded openssl build2020-06-13T14:22:00ZLeonid Evdokimovtor crashes silently with non-threaded openssl buildI've seen lots of cryptic crashes of tor on my openwrt gateway: https://atlas.torproject.org/#details/F44DA505AD91CFC8D5745BB070909F20F21E06D9
I've recently decided to debug this issue and run tor with --Daemon 0 under tmux and I got as...I've seen lots of cryptic crashes of tor on my openwrt gateway: https://atlas.torproject.org/#details/F44DA505AD91CFC8D5745BB070909F20F21E06D9
I've recently decided to debug this issue and run tor with --Daemon 0 under tmux and I got assertion failure:
```
...
Aug 24 00:43:13.842 [notice] Performing bandwidth self-test...done.
/usr/sbin/tor: md_rand.c: 325: ssleay_rand_add: Assertion `md_c[1] == md_count[1]' failed.
Aborted
```
Accoding to openssl code it means that openssl was built without OPENSSL_THREADS
```
crypto/rand/md_rand.c
320- if (entropy < ENTROPY_NEEDED) /* stop counting when we have enough */
321- entropy += add;
322- if (!do_not_lock) CRYPTO_w_unlock(CRYPTO_LOCK_RAND);
323-
324-#if !defined(OPENSSL_THREADS) && !defined(OPENSSL_SYS_WIN32)
325: assert(md_c[1] == md_count[1]);
326-#endif
327- }
328-
329-static void ssleay_rand_seed(const void *buf, int num)
330- {
```
If OPENSSL_THREADS is required for tor to work, then tor should probably check for it in compile-time:
```
openssl-1.0.1/doc/crypto/threads.pod
You can find out if OpenSSL was configured with thread support:
#define OPENSSL_THREAD_DEFINES
#include <openssl/opensslconf.h>
#if defined(OPENSSL_THREADS)
// thread support enabled
#else
// no thread support
#endif
```
If OPENSSL_THREADS is not required, than it looks like either bug in tor itself or in tor<->openssl interaction.
libopenssl - 1.0.1c-1
tor - 0.2.2.37-1
P.S. related OpenWrt ticket: https://dev.openwrt.org/ticket/12072Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8179stitched aes-ni ciphers in openssl 1.0.1d seems to break SSL Handshakes/Reneg...2020-06-13T14:27:13ZTracstitched aes-ni ciphers in openssl 1.0.1d seems to break SSL Handshakes/Renegotiationsrunning the tor deamon with static openssl 1.0.1d led to masses of
[warn] 45 connections have failed:
[warn] 32 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
[war...running the tor deamon with static openssl 1.0.1d led to masses of
[warn] 45 connections have failed:
[warn] 32 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
[warn] 13 connections died in state renegotiating (TLS, v2 handshake) with SSL state SSLv3 read server hello A in RENEGOTIATE
while bootstraping the node. please see attached excerpt of the debug-log.
what's odd looking to my untrained eye there is:
[debug] tor_tls_debug_state_callback(): SSL 0x7f70e1390720 is now in state before accept initialization [type=16,val=1].
[debug] tor_tls_debug_state_callback(): SSL 0x7f70e1390720 is now in state before accept initialization [type=8193,val=1].
[debug] tor_tls_debug_state_callback(): SSL 0x7f70e1390720 is now in state SSLv3 read client hello B [type=16392,val=522].
[debug] tor_tls_debug_state_callback(): SSL 0x7f70e1390720 is now in state SSLv3 read client hello B [type=8194,val=-1].
[debug] TLS error while reading with [scrubbed]: unexpected message (in SSL routines:SSL3_GET_MESSAGE:SSLv3 read client hello B)
[debug] tor_tls_read(): read returned r=-1, err=-9
[debug] connection_read_to_buf(): tls error [misc error]. breaking (nickname not set, address xx.xxx.xx.xx).
compiling tor with 1.0.0k seems to fix this.
**Trac**:
**Username**: ruebezahlTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/11441OpenSSL bug CVE-2014-0160 fixes2020-06-13T16:48:04ZAndrew LewmanOpenSSL bug CVE-2014-0160 fixesRespond to bad ssl libs, again.Respond to bad ssl libs, again.https://gitlab.torproject.org/legacy/trac/-/issues/13815Attempt to port tor to Google's BoringSSL2020-06-13T14:40:34ZteorAttempt to port tor to Google's BoringSSLSplit from #13415:
**nickm:**
Interesting. It looks like building with BoringSSL will require some actual porting to detect all the APIs they've removed, and to figure out whether we can replace them.
**teor:**
BoringSSL is even wors...Split from #13415:
**nickm:**
Interesting. It looks like building with BoringSSL will require some actual porting to detect all the APIs they've removed, and to figure out whether we can replace them.
**teor:**
BoringSSL is even worse - it doesn't even have an openssl executable, only builds static libraries, and is a pain to configure correctly under our current config scripts.
I can't seem to stop it finding the system-supplied SSL, even when I provide it the BoringSSL directories.
I get the following warnings when I manually install BoringSSL into include/lib/bin dirs, and fake the openssl executable using the bssl executable:
(I've cleaned up some warnings that were irrelevant or trivial.)
CC src/common/crypto.o
src/common/crypto.c:170:12: warning: implicit declaration of function
'ENGINE_get_name' is invalid in C99 [-Wimplicit-function-declaration]
name = ENGINE_get_name(e);
src/common/crypto.c:171:10: warning: implicit declaration of function
'ENGINE_get_id' is invalid in C99 [-Wimplicit-function-declaration]
id = ENGINE_get_id(e);
src/common/crypto.c:186:15: warning: implicit declaration of function
'ENGINE_by_id' is invalid in C99 [-Wimplicit-function-declaration]
ENGINE *e = ENGINE_by_id("dynamic");
src/common/crypto.c:188:10: warning: implicit declaration of function
'ENGINE_ctrl_cmd_string' is invalid in C99
[-Wimplicit-function-declaration]
if (!ENGINE_ctrl_cmd_string(e, "ID", engine, 0)
src/common/crypto.c:227:31: warning: implicit declaration of function
'SSLeay_version' is invalid in C99 [-Wimplicit-function-declaration]
const char *raw_version = SSLeay_version(SSLEAY_VERSION);
src/common/crypto.c:227:46: error: use of undeclared identifier 'SSLEAY_VERSION'
const char *raw_version = SSLeay_version(SSLEAY_VERSION);
src/common/crypto.c:241:51: error: use of undeclared identifier
'OPENSSL_VERSION_TEXT'
parse_openssl_version_str(OPENSSL_VERSION_TEXT);
src/common/crypto.c:251:7: warning: implicit declaration of function
'RAND_get_rand_method' is invalid in C99 [-Wimplicit-function-declaration]
if (RAND_get_rand_method() != RAND_SSLeay()) {
src/common/crypto.c:251:33: warning: implicit declaration of function
'RAND_SSLeay' is invalid in C99 [-Wimplicit-function-declaration]
if (RAND_get_rand_method() != RAND_SSLeay()) {
src/common/crypto.c:255:5: warning: implicit declaration of function
'RAND_set_rand_method' is invalid in C99 [-Wimplicit-function-declaration]
RAND_set_rand_method(RAND_SSLeay());
src/common/crypto.c:291:9: warning: implicit declaration of function 'SSLeay' is
invalid in C99 [-Wimplicit-function-declaration]
if (SSLeay() == OPENSSL_VERSION_NUMBER &&
src/common/crypto.c:292:32: error: use of undeclared identifier 'SSLEAY_VERSION'
!strcmp(SSLeay_version(SSLEAY_VERSION), OPENSSL_VERSION_TEXT)) {
src/common/crypto.c:292:49: error: use of undeclared identifier
'OPENSSL_VERSION_TEXT'
!strcmp(SSLeay_version(SSLEAY_VERSION), OPENSSL_VERSION_TEXT)) {
CC src/common/crypto_s2k.o
src/common/crypto.c:294:57: error: use of undeclared identifier 'SSLEAY_VERSION'
"(%lx: %s).", SSLeay(), SSLeay_version(SSLEAY_VERSION));
./src/common/../common/torlog.h:190:50: note: expanded from macro 'log_info'
log_fn_(LOG_INFO, domain, PRETTY_FUNCTION, args)
src/common/crypto.c:299:55: error: use of undeclared identifier
'OPENSSL_VERSION_TEXT'
(unsigned long)OPENSSL_VERSION_NUMBER, OPENSSL_VERSION_TEXT,
./src/common/../common/torlog.h:194:50: note: expanded from macro 'log_warn'
log_fn_(LOG_WARN, domain, PRETTY_FUNCTION, args)
src/common/crypto.c:300:41: error: use of undeclared identifier 'SSLEAY_VERSION'
SSLeay(), SSLeay_version(SSLEAY_VERSION));
./src/common/../common/torlog.h:194:50: note: expanded from macro 'log_warn'
log_fn_(LOG_WARN, domain, PRETTY_FUNCTION, args)
src/common/crypto.c:339:7: warning: implicit declaration of function
'ENGINE_load_builtin_engines' is invalid in C99
[-Wimplicit-function-declaration]
ENGINE_load_builtin_engines();
src/common/crypto.c:340:7: warning: implicit declaration of function
'ENGINE_register_all_complete' is invalid in C99
[-Wimplicit-function-declaration]
ENGINE_register_all_complete();
src/common/crypto.c:350:13: warning: incompatible integer to pointer conversion
assigning to 'ENGINE *' (aka 'struct engine_st *') from 'int'
[-Wint-conversion]
e = ENGINE_by_id(accelName);
~
src/common/crypto.c:363:9: warning: implicit declaration of function
'ENGINE_set_default' is invalid in C99 [-Wimplicit-function-declaration]
ENGINE_set_default(e, ENGINE_METHOD_ALL);
src/common/crypto.c:363:31: error: use of undeclared identifier
'ENGINE_METHOD_ALL'
ENGINE_set_default(e, ENGINE_METHOD_ALL);
src/common/crypto.c:367:25: warning: implicit declaration of function
'ENGINE_get_default_RSA' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("RSA", ENGINE_get_default_RSA());
src/common/crypto.c:368:24: warning: implicit declaration of function
'ENGINE_get_default_DH' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("DH", ENGINE_get_default_DH());
src/common/crypto.c:369:26: warning: implicit declaration of function
'ENGINE_get_default_ECDH' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("ECDH", ENGINE_get_default_ECDH());
src/common/crypto.c:370:27: warning: implicit declaration of function
'ENGINE_get_default_ECDSA' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("ECDSA", ENGINE_get_default_ECDSA());
src/common/crypto.c:371:26: warning: implicit declaration of function
'ENGINE_get_default_RAND' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("RAND", ENGINE_get_default_RAND());
src/common/crypto.c:373:26: warning: implicit declaration of function
'ENGINE_get_digest_engine' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("SHA1", ENGINE_get_digest_engine(NID_sha1));
src/common/crypto.c:374:30: warning: implicit declaration of function
'ENGINE_get_cipher_engine' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("3DES-CBC", ENGINE_get_cipher_engine(NID_des_ede3_cbc));
src/common/crypto.c:408:3: warning: implicit declaration of function
'ERR_remove_state' is invalid in C99 [-Wimplicit-function-declaration]
ERR_remove_state(0);
src/common/crypto.c:691:25: error: incomplete definition of type
'struct buf_mem_st'
*dest = tor_malloc(buf->length+1);
~
./src/common/util.h:116:44: note: expanded from macro 'tor_malloc'
#define tor_malloc(size) tor_malloc_(size DMALLOC_ARGS)
/test/tor/boringssl-install/include/openssl/base.h:170:16: note: forward
declaration of 'struct buf_mem_st'
typedef struct buf_mem_st BUF_MEM;
src/common/crypto.c:692:20: error: incomplete definition of type
'struct buf_mem_st'
memcpy(*dest, buf->data, buf->length);
~
/usr/include/secure/_string.h:65:33: note: expanded from macro 'memcpy'
builtin_memcpy_chk (dest, src, len, darwin_obsz0 (dest))
/test/tor/boringssl-install/include/openssl/base.h:170:16: note: forward
declaration of 'struct buf_mem_st'
typedef struct buf_mem_st BUF_MEM;
src/common/crypto.c:692:31: error: incomplete definition of type
'struct buf_mem_st'
memcpy(*dest, buf->data, buf->length);
~
/usr/include/secure/_string.h:65:38: note: expanded from macro 'memcpy'
builtin_memcpy_chk (dest, src, len, darwin_obsz0 (dest))
/test/tor/boringssl-install/include/openssl/base.h:170:16: note: forward
declaration of 'struct buf_mem_st'
typedef struct buf_mem_st BUF_MEM;
src/common/crypto.c:693:14: error: incomplete definition of type
'struct buf_mem_st'
(*dest)[buf->length] = 0; /* nul terminate it */
~
/test/tor/boringssl-install/include/openssl/base.h:170:16: note: forward
declaration of 'struct buf_mem_st'
typedef struct buf_mem_st BUF_MEM;
src/common/crypto.c:694:13: error: incomplete definition of type
'struct buf_mem_st'
*len = buf->length;
~
/test/tor/boringssl-install/include/openssl/base.h:170:16: note: forward
declaration of 'struct buf_mem_st'
typedef struct buf_mem_st BUF_MEM;
src/common/crypto.c:695:3: warning: implicit declaration of function
'BUF_MEM_free' is invalid in C99 [-Wimplicit-function-declaration]
BUF_MEM_free(buf);
src/common/crypto.c:1783:19: warning: implicit declaration of function
'DH_generate_parameters' is invalid in C99
[-Wimplicit-function-declaration]
dh_parameters = DH_generate_parameters(DH_BYTES*8, DH_GENERATOR, NULL, NULL);
src/common/crypto.c:2118:12: error: no member named 'length' in 'struct dh_st'
res->dh->length = DH_PRIVATE_KEY_BITS;
~
src/common/crypto.c:3046:2: error: OpenSSL has been built without thread
support. Tor requires an OpenSSL library with thread support enabled.
#error OpenSSL has been built without thread support. Tor requires an \
src/common/crypto.c:3149:3: warning: implicit declaration of function
'ENGINE_cleanup' is invalid in C99 [-Wimplicit-function-declaration]
ENGINE_cleanup();
src/common/crypto.c:3152:3: warning: implicit declaration of function
'CONF_modules_unload' is invalid in C99 [-Wimplicit-function-declaration]
CONF_modules_unload(1);Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/13977Evaluate alternate SSL/TLS libraries: CyaSSL, GnuTLS, ...2020-06-13T14:41:09ZteorEvaluate 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/legacy/trac/-/issues/14188OpenSSL 1.1.0-dev change: builds without deprecated functions by default2020-06-13T14:41:46ZteorOpenSSL 1.1.0-dev change: builds without deprecated functions by defaultDue to the following OpenSSL change:
```
*) config has been changed so that by default OPENSSL_NO_DEPRECATED is used.
Access to deprecated functions can be re-enabled by running config with
"enable-deprecated". In addition a...Due to the following OpenSSL change:
```
*) config has been changed so that by default OPENSSL_NO_DEPRECATED is used.
Access to deprecated functions can be re-enabled by running config with
"enable-deprecated". In addition applications wishing to use deprecated
functions must define OPENSSL_USE_DEPRECATED. Note that this new behaviour
will, by default, disable some transitive includes that previously existed
in the header files (e.g. ec.h will no longer, by default, include bn.h)
[Matt Caswell]
```
Building tor git with the latest OpenSSL 1.1.0-dev git causes the following errors on OS X with clang (edited for brevity):
```
CC src/common/tortls.o
src/common/crypto.c:408:3: error: implicit declaration of function
'ERR_remove_state' is invalid in C99
ERR_remove_state(0);
src/common/crypto.c:1783:19: error: implicit declaration of function
'DH_generate_parameters' is invalid in C99
dh_parameters = DH_generate_parameters(DH_BYTES*8, DH_GENERATOR, NULL, NULL);
src/common/crypto.c:1783:19: note: did you mean 'DH_generate_parameters_ex'?
/test/tor/openssl-install-x86_64/include/openssl/dh.h:213:5: note:
'DH_generate_parameters_ex' declared here
int DH_generate_parameters_ex(DH *dh, int prime_len,int generator, B...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC src/trunnel/pwbox.o
src/common/crypto.c:3131:3: error: implicit declaration of function
'CRYPTO_set_id_callback' is invalid in C99
CRYPTO_set_id_callback(tor_get_thread_id);
4 errors generated.
make[1]: *** [src/common/crypto.o] Error 1
src/common/tortls.c:675:27: error: implicit declaration of function 'BN_bin2bn'
is invalid in C99
if (!(serial_number = BN_bin2bn(serial_tmp, sizeof(serial_tmp), NULL)))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/common/tortls.c:713:5: error: implicit declaration of function
'BN_clear_free' is invalid in C99
BN_clear_free(serial_number);
src/common/tortls.c:1069:16: error: implicit declaration of function
'BN_num_bits' is invalid in C99
if (rsa && BN_num_bits(rsa->n) == 1024)
src/common/tortls.c:1069:31: error: incomplete definition of type
'struct rsa_st'
if (rsa && BN_num_bits(rsa->n) == 1024)
/test/tor/openssl-install-x86_64/include/openssl/ossl_typ.h:147:16: note:
forward declaration of 'struct rsa_st'
typedef struct rsa_st RSA;
src/common/tortls.c:1072:7: error: implicit declaration of function 'RSA_free'
is invalid in C99
RSA_free(rsa);
src/common/tortls.c:1072:7: note: did you mean 'SSL_free'?
/test/tor/openssl-install-x86_64/include/openssl/ssl.h:2201:6: note: 'SSL_free'
declared here
void SSL_free(SSL *ssl);
```
Building OpenSSL with `./Configure enable-deprecated` and including `-DOPENSSL_USE_DEPRECATED` in the CPPFLAGS seems to require a few tries to actually work. (I don't think it likes parallel builds.)
Building tor with this new version then works fine.
~~ causes a linker error: ~~ (This is actually due to OpenSSL not working with parallel builds.)
```
Undefined symbols for architecture x86_64:
"_EVP_aes_128_ctr", referenced from:
_aes_new_cipher in libor-crypto.a(aes.o)
```
We should probably fix this by 0.2.6-final, otherwise it won't be able to be built with OpenSSL 1.1.0 dev out of the box.
But how are we going to cope with platforms that build OpenSSL without deprecated functions?
Conditionalise on `#if OPENSSL_USE_DEPRECATED`s in the code?
Advise them not to?
It seems like this change could cause a huge mess.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15017Experiment: does BIO_f_buffer help performance with read/write syscalls?2020-06-13T14:43:37ZNick 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/legacy/trac/-/issues/15760tortls.c fails to compile with OpenSSL 1.1.0-dev2020-06-13T14:45:28ZTractortls.c fails to compile with OpenSSL 1.1.0-devOn NetBSD 6.1_Stable/i386 trying to compile15760
Tor v0.2.7.0-alpha-dev (git-06939551f4c081c4)
with
Libevent 2.1.5-beta, Zlib 1.2.3
AND
OpenSSL 1.1.0-dev
Since I was already compiling a development version of tor, thought I would compi...On NetBSD 6.1_Stable/i386 trying to compile15760
Tor v0.2.7.0-alpha-dev (git-06939551f4c081c4)
with
Libevent 2.1.5-beta, Zlib 1.2.3
AND
OpenSSL 1.1.0-dev
Since I was already compiling a development version of tor, thought I would compile against a dev version of openssl...
I used autogen and configure thusly:
./autogen.sh --with-libevent-dir=/usr/local --enable-static-openssl=1 --with-openssl-dir=/usr/local/ssl
./configure --with-libevent-dir=/usr/local --enable-static-openssl=1 --with-openssl-dir=/usr/local/ssl
The build started ok for the first 30-40 files then I received:
CC src/common/tortls.o
src/common/tortls.c: In function 'tor_tls_context_new':
src/common/tortls.c:1375:18: error: dereferencing pointer to incomplete type
src/common/tortls.c:1376:16: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'find_cipher_by_id':
src/common/tortls.c:1529:13: error: dereferencing pointer to incomplete type
src/common/tortls.c:1535:10: error: dereferencing pointer to incomplete type
src/common/tortls.c:1537:7: error: dereferencing pointer to incomplete type
src/common/tortls.c:1541:13: error: dereferencing pointer to incomplete type
src/common/tortls.c:1541:30: error: dereferencing pointer to incomplete type
src/common/tortls.c:1547:22: error: dereferencing pointer to incomplete type
src/common/tortls.c:1548:12: error: dereferencing pointer to incomplete type
src/common/tortls.c:1549:18: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_classify_client_ciphers':
src/common/tortls.c:1626:27: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_client_is_using_v2_ciphers':
src/common/tortls.c:1676:54: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_server_info_callback':
src/common/tortls.c:1695:11: error: dereferencing pointer to incomplete type
src/common/tortls.c:1696:11: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'rectify_client_ciphers':
src/common/tortls.c:1826:7: error: invalid application of 'sizeof' to incomplete type 'SSL_CIPHER'
src/common/tortls.c:1828:7: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1828:28: error: dereferencing pointer to incomplete type
src/common/tortls.c:1831:7: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1831:28: error: dereferencing pointer to incomplete type
src/common/tortls.c:1832:7: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1832:28: error: dereferencing pointer to incomplete type
src/common/tortls.c:1841:7: error: dereferencing pointer to incomplete type
src/common/tortls.c:1841:7: error: dereferencing pointer to incomplete type
src/common/tortls.c:1854:29: error: dereferencing pointer to incomplete type
src/common/tortls.c:1857:9: error: dereferencing pointer to incomplete type
src/common/tortls.c:1857:9: error: dereferencing pointer to incomplete type
src/common/tortls.c:1862:25: error: dereferencing pointer to incomplete type
src/common/tortls.c:1864:9: error: dereferencing pointer to incomplete type
src/common/tortls.c:1868:7: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1868:47: error: dereferencing pointer to incomplete type
src/common/tortls.c:1872:9: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1872:9: error: dereferencing pointer to incomplete type
src/common/tortls.c:1873:1: error: invalid use of undefined type 'struct ssl_cipher_st'
src/common/tortls.c:1873:9: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_new':
src/common/tortls.c:1939:40: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_unblock_renegotiation':
src/common/tortls.c:2033:13: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_block_renegotiation':
src/common/tortls.c:2048:11: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_assert_renegotiation_unblocked':
src/common/tortls.c:2056:5: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_handshake':
src/common/tortls.c:2193:22: error: dereferencing pointer to incomplete type
src/common/tortls.c:2203:27: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_finish_handshake':
src/common/tortls.c:2239:13: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_get_tlssecrets':
src/common/tortls.c:2842:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2843:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2848:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2848:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2849:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2849:3: error: dereferencing pointer to incomplete type
src/common/tortls.c:2853:37: error: dereferencing pointer to incomplete type
src/common/tortls.c:2854:30: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_get_buffer_sizes':
src/common/tortls.c:2870:15: error: dereferencing pointer to incomplete type
src/common/tortls.c:2871:30: error: dereferencing pointer to incomplete type
src/common/tortls.c:2874:15: error: dereferencing pointer to incomplete type
src/common/tortls.c:2875:30: error: dereferencing pointer to incomplete type
src/common/tortls.c:2878:25: error: dereferencing pointer to incomplete type
src/common/tortls.c:2879:25: error: dereferencing pointer to incomplete type
src/common/tortls.c: In function 'tor_tls_client_is_using_v2_ciphers':
src/common/tortls.c:1677:1: warning: control reaches end of non-void function
src/common/tortls.c: In function 'find_cipher_by_id':
src/common/tortls.c:1557:1: warning: control reaches end of non-void function
*** Error code 1
Stop.
make: stopped in /usr/local/src/tor
*** Error code 1
Fixable? Unsupported?
thanks,
gene
**Trac**:
**Username**: yancmTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15918Investigate using the EVP interface for non-oneshot hash calls.2020-06-13T14:45:48ZYawning AngelInvestigate using the EVP interface for non-oneshot hash calls.People have recently asked about VIA PadLock and cryptdev (#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 i...People have recently asked about VIA PadLock and cryptdev (#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/legacy/trac/-/issues/16153[warn] tor_tls_client_is_using_v2_ciphers(): Bug: Whoops. session->ciphers do...2020-06-13T14:46:26ZRoger Dingledine[warn] tor_tls_client_is_using_v2_ciphers(): Bug: Whoops. session->ciphers doesn't match SSL_get_ciphers() (on Tor 0.2.7.1-alpha-dev 45a9057 3e69d12dc)```
[warn] tor_tls_client_is_using_v2_ciphers(): Bug: Whoops. session->ciphers doesn't match SSL_get_ciphers() (on Tor 0.2.7.1-alpha-dev 45a90573e69d12dc)
```
This is moria1, running on RHEL. Presumably it's related to some of the recen...```
[warn] tor_tls_client_is_using_v2_ciphers(): Bug: Whoops. session->ciphers doesn't match SSL_get_ciphers() (on Tor 0.2.7.1-alpha-dev 45a90573e69d12dc)
```
This is moria1, running on RHEL. Presumably it's related to some of the recent openssl changes.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17109autoconf should check that the SSL implementation has ECC support and at leas...2020-06-13T14:49:16ZYawning Angelautoconf should check that the SSL implementation has ECC support and at least one usable curve.Gentoo apparently has special snowflake OpenSSL > 1.0 that is missing ECC support unless explicitly enabled. Since we only check the OpenSSL version and not if ECC support is present, the build fails at `make` time rather than `configur...Gentoo apparently has special snowflake OpenSSL > 1.0 that is missing ECC support unless explicitly enabled. Since we only check the OpenSSL version and not if ECC support is present, the build fails at `make` time rather than `configure` time.
We should fix this so it fails earlier rather than later.
https://bugs.gentoo.org/560780Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17549tortls.c compile error w/Tor v0.2.8.0-alpha-dev and OpenSSL 1.1.0-dev (git-19...2020-06-13T14:50:47ZTractortls.c compile error w/Tor v0.2.8.0-alpha-dev and OpenSSL 1.1.0-dev (git-19e10f95c105a698) against SSL_DevHi again...
with Tor v0.2.8.0-alpha-dev (builds after git-19e10f95c105a698) running on NetBSD (6/i386) with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3
For 5 or 6 days I receive the following compile errors:
gmake[1]: Entering...Hi again...
with Tor v0.2.8.0-alpha-dev (builds after git-19e10f95c105a698) running on NetBSD (6/i386) with Libevent 2.1.5-beta, OpenSSL 1.1.0-dev and Zlib 1.2.3
For 5 or 6 days I receive the following compile errors:
gmake[1]: Entering directory '/usr/local/src/tor'
CC src/common/tortls.o
src/common/tortls.c: In function 'tor_tls_server_info_callback':
src/common/tortls.c:1536:3: warning: implicit declaration of function 'SSL_state'
src/common/tortls.c:1537:21: error: 'SSL3_ST_SW_SRVR_HELLO_A' undeclared (first use in this function)
src/common/tortls.c:1537:21: note: each undeclared identifier is reported only once for each function it appears in
src/common/tortls.c:1538:21: error: 'SSL3_ST_SW_SRVR_HELLO_B' undeclared (first use in this function)
Makefile:3240: recipe for target 'src/common/tortls.o' failed
gmake[1]: *** [src/common/tortls.o] Error 1
gmake[1]: Leaving directory '/usr/local/src/tor'
Makefile:1864: recipe for target 'all' failed
gmake: *** [all] Error 2
regards,
gene
**Trac**:
**Username**: yancmTor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/17921OPENSSL_V_SERIES(1,1,0) compat guard macro borks LibreSSL2020-06-13T14:52:56ZcypherpunksOPENSSL_V_SERIES(1,1,0) compat guard macro borks LibreSSLSince LibreSSL didn't adapt the whole 'rename everything' policy, it still uses the old names.Since LibreSSL didn't adapt the whole 'rename everything' policy, it still uses the old names.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17984Tor fails to build with latest OpenSSL master2020-06-13T14:53:14Zrl1987Tor fails to build with latest OpenSSL masterI'm running Mac OS X 10.11.2 and installed the latest OpenSSL from their master branch (1de1d7689a81f2a3ed3348926e6a31ef79a2bc15). Current Tor master (cdbb04be102969bd2cece9daf42896e061cc8880) fails to build with the following warnings: ...I'm running Mac OS X 10.11.2 and installed the latest OpenSSL from their master branch (1de1d7689a81f2a3ed3348926e6a31ef79a2bc15). Current Tor master (cdbb04be102969bd2cece9daf42896e061cc8880) fails to build with the following warnings:
```
src/common/crypto.c:376:26: warning: implicit declaration of function
'ENGINE_get_default_ECDH' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("ECDH", ENGINE_get_default_ECDH());
^
src/common/crypto.c:376:26: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'ENGINE *' (aka 'struct engine_st *')
[-Wint-conversion]
log_engine("ECDH", ENGINE_get_default_ECDH());
^~~~~~~~~~~~~~~~~~~~~~~~~
src/common/crypto.c:173:36: note: passing argument to parameter 'e' here
log_engine(const char *fn, ENGINE *e)
^
src/common/crypto.c:377:27: warning: implicit declaration of function
'ENGINE_get_default_ECDSA' is invalid in C99
[-Wimplicit-function-declaration]
log_engine("ECDSA", ENGINE_get_default_ECDSA());
^
src/common/crypto.c:377:27: warning: incompatible integer to pointer conversion
passing 'int' to parameter of type 'ENGINE *' (aka 'struct engine_st *')
[-Wint-conversion]
log_engine("ECDSA", ENGINE_get_default_ECDSA());
^~~~~~~~~~~~~~~~~~~~~~~~~~
src/common/crypto.c:173:36: note: passing argument to parameter 'e' here
log_engine(const char *fn, ENGINE *e)
^
4 warnings generated.
```
and following error messages:
```
Undefined symbols for architecture x86_64:
"_ENGINE_get_default_ECDH", referenced from:
_crypto_global_init in libor-crypto.a(crypto.o)
"_ENGINE_get_default_ECDSA", referenced from:
_crypto_global_init in libor-crypto.a(crypto.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [src/or/tor] Error 1
make: *** [all] Error 2
```Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19429Clean up our OpenSSL 1.1 support.2020-06-13T14:58:43ZYawning 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/legacy/trac/-/issues/19981Make sure we build with OpenSSL 1.1.0 with all deprecated APIs removed2020-06-13T15:00:36ZNick 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/legacy/trac/-/issues/19983Is openssl 1.1.0's "secure heap" feature useful for us?2020-06-13T15:00:37ZNick 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/legacy/trac/-/issues/20266Provide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.12020-06-13T15:01:49ZteorProvide a shim for SSL_cipher_get_id in OpenSSL versions < 1.0.1Tor fails to compile on OpenSSL 1.0.0, because we use SSL_cipher_get_id, which was introduced in OpenSSL 1.0.1.
We can access the id member of the cipher object instead, like this:
https://github.com/SlimRoms/android_external_chromium/c...Tor fails to compile on OpenSSL 1.0.0, because we use SSL_cipher_get_id, which was introduced in OpenSSL 1.0.1.
We can access the id member of the cipher object instead, like this:
https://github.com/SlimRoms/android_external_chromium/commit/731158395b8ae1105c69cc42dae6244385f6b4ffTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21561CRYPTO_THREADID_set_callback2020-06-13T15:06:41ZTracCRYPTO_THREADID_set_callbackHi,
Since Windows 10 Insider Preview build 15042 install, the following error is received when loading the Tor Browser.
Not sure if its a 15042 development issue or Tor related, but never experienced this before.
Any ideas please?
>...Hi,
Since Windows 10 Insider Preview build 15042 install, the following error is received when loading the Tor Browser.
Not sure if its a 15042 development issue or Tor related, but never experienced this before.
Any ideas please?
>>
tor.exe - Entry Point Not Found
The proceedure entry point CRYPTO_THREADID_set_callback could not be located in the dynamic link library S:\Downloads\Tor Browser\Browser\TorBrowser\Tor\tor.exe
<<
Same error in both versions 6.5_en-US & 7.0a1_en-US
Thank you.
**Trac**:
**Username**: pdsTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24978Tor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with enable...2020-06-13T15:21:04ZNick MathewsonTor doesn't work when built with (unreleased) OpenSSL 1.1.1 built with enable-tls1_3From https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ :
>If you explicitly configure your ciphersuites then care should be taken to ensure that you are not inadvertently excluding all TLSv1.3 compatible ciphersuites. If a client ha...From https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ :
>If you explicitly configure your ciphersuites then care should be taken to ensure that you are not inadvertently excluding all TLSv1.3 compatible ciphersuites. If a client has TLSv1.3 enabled but no TLSv1.3 ciphersuites configured then it will immediately fail (even if the server does not support TLSv1.3) with an error message
That's the situation we're in now. When OpenSSL 1.1.1 releases in April, current Tor versions just won't work with it at all, since they have neither disabled TLS1.3 nor enabled any TLS1.3 ciphers.
We have two options for fixing this: I'll implement both and we can see what we like.Tor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25353Configure fails with some OpenSSL 1.1.0 built with no-deprecated.2020-06-13T15:22:23ZTracConfigure fails with some OpenSSL 1.1.0 built with no-deprecated.On my machine with OpenSSL 1.1.0, Tor's `configure` script fails to detect OpenSSL and gives me the following error:
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... configure: WARNING: Could not fin...On my machine with OpenSSL 1.1.0, Tor's `configure` script fails to detect OpenSSL and gives me the following error:
```
configure: Now, we'll look for OpenSSL >= 1.0.1
checking for openssl directory... configure: WARNING: Could not find a linkable openssl. If you have it installed somewhere unusual, you can specify an explicit path using --with-openssl-dir
configure: error: Missing libraries; unable to proceed.
```
This seems to be due to the fact that `configure` checks for OpenSSL >= 1.0.1 with `TLSv1_1_method()`, which is deprecated in favor of `TLS_method()` in OpenSSL 1.1.0.
On my configuration of OpenSSL 1.1.0, deprecated functions are not available by default (not without first enabling the `OPENSSL_API_COMPAT` compatibility #define), hence the failure.
I'd gladly provide a patch, but I'm not sure how this would best be fixed: explicitly check for `TLS_method()` in case the check for `TLSv1_1_method()` fails? Replace this test with a test on `OPENSSL_VERSION_NUMBER`? Find some other function introduced in 1.0.1 and neither removed nor deprecated in 1.1.0?
**Trac**:
**Username**: laomaiwengTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/25957Tor 0.3.3.5-rc died: Caught signal 112020-06-13T15:25:06ZTracTor 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/legacy/trac/-/issues/26156Undefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprec...2020-06-13T15:25:51ZTracUndefined references to EVP_CIPHER_CTX_cleanup() with OpenSSL 1.1.0 no-deprecatedOn my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/hom...On my machine with OpenSSL 1.1.0 `no-deprecated', Tor 0.3.4.1-alpha fails to build. The failure happens when linking several utilities, with the following error:
```
src/common/libor-crypto.a(aes.o): In function `aes_cipher_free_':
/home/quentin/Security/Code/Tor/tor/src/common/aes.c:121: undefined reference to `EVP_CIPHER_CTX_cleanup'
```
This appears to be due to _src/common/aes.c_ not #include-ing "compat_openssl.h", and thus not having the OPENSSL_1_1_API #define. Simply adding `#include "compat_openssl.h"` in _aes.c_ fixes the build.
I have also checked that building still succeeds against OpenSSL 1.0.1 and 1.0.2 with this modification.
**Trac**:
**Username**: laomaiwengTor: 0.3.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/27344Debian OpenSSL 1.1.1~~pre6-1 defaults to requiring 2048 bit RSA keys2020-06-13T15:32:32Zweasel (Peter Palfrader)Debian OpenSSL 1.1.1~~pre6-1 defaults to requiring 2048 bit RSA keysFrancois writes on https://bugs.debian.org/907351:
> I get the following error in my logs approximately every 2 hours:
>
> Aug 26 05:05:01 hostname Tor![25963]: TLS error while constructing a TLS context: dh key too small (in SSL routi...Francois writes on https://bugs.debian.org/907351:
> I get the following error in my logs approximately every 2 hours:
>
> Aug 26 05:05:01 hostname Tor![25963]: TLS error while constructing a TLS context: dh key too small (in SSL routines:ssl3_ctx_ctrl:---)
>
> I tried upgrading to the version in experimental and it also has this
> problem.
[experimental had 0.3.4.6-rc-1 at that time.]Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28245Tor nodes with OpenSSL 1.1.1 can't communicate with each other2020-06-13T15:33:30ZGeorge KadianakisTor nodes with OpenSSL 1.1.1 can't communicate with each otherWe seem to have trouble in networks where both clients and relays are running openssl-1.1.1 . In particular, a chutney network on `openssl-1.1.1 (11 sept 2018)` will have its clients fail to bootstrap because they cant communicate any by...We seem to have trouble in networks where both clients and relays are running openssl-1.1.1 . In particular, a chutney network on `openssl-1.1.1 (11 sept 2018)` will have its clients fail to bootstrap because they cant communicate any bytes after the SSL handshake is done.
The problem might be that 1.1.1 is the version that introduces TLS-1.3, so these nodes are trying to do TLS-1.3 with each other.
Thanks to teor, dgoulet, nickm for the debug help.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/29025OpenSSL will not compile without engine support2020-06-13T15:36:30ZTracOpenSSL will not compile without engine supportIn OpenWrt, ENGINE support is disabled (supposed to be actually) and this makes compilation fail as currently in Tor, it is unconditionally disabled for ANDROID.
This changes tor to check for OPENSSL_NO_ENGINE which also works with Andr...In OpenWrt, ENGINE support is disabled (supposed to be actually) and this makes compilation fail as currently in Tor, it is unconditionally disabled for ANDROID.
This changes tor to check for OPENSSL_NO_ENGINE which also works with Android.
The missing headers are for fixing offsetof and SHA512 being undefined.
**Trac**:
**Username**: Mangixhttps://gitlab.torproject.org/legacy/trac/-/issues/30190Do not warn about compatible OpenSSL upgrades2020-06-13T15:40:47ZteorDo not warn about compatible OpenSSL upgradesFrom https://github.com/torproject/tor/pull/951
When releasing OpenSSL patch-level maintenance updates,
we do not want to rebuild binaries using it.
And since they guarantee ABI stability, we do not have to.
Without this patch, warning...From https://github.com/torproject/tor/pull/951
When releasing OpenSSL patch-level maintenance updates,
we do not want to rebuild binaries using it.
And since they guarantee ABI stability, we do not have to.
Without this patch, warning messages were produced
that confused users:
https://bugzilla.opensuse.org/show_bug.cgi?id=1129411Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31565static Tor building against openssl-1.1.1 fails: configure unable to find lin...2020-06-13T15:52:15ZTracstatic 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.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32200only include required bits of OpenSSL in Android builds2020-06-16T01:25:49Zeighthaveonly include required bits of OpenSSL in Android buildsI've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./...I've been doing some experiments to make the Android _libtor.so_ binaries smaller. One of them is building OpenSSL with as many things as possible turned off. This does make the resulting binary smaller. Here's what I tried:
```
$ ./Configure \
no-comp no-dtls no-ec2m no-psk no-srp no-ssl2 no-ssl3 \
no-camellia no-idea no-md2 no-md4 no-mdc2 no-rc2 no-rc4 no-rc5 no-rmd160 no-whirlpool \
no-dso no-engine no-hw no-ui-console \
no-shared no-unit-test \
```
The open question is whether the test coverage is good enough to know whether this breaks anything.
Additionally, I think Android _ndk-build_ used to 'gcc' "gc sections" to mark unused code blocks which were then stripped out at the end. They seemed to have stopped doing this with _clang_, but I don't know why. In the past, I have seen the "gc sections" stripping reduce binary size quite a bit.
Also related: I tried building with `-Os` and `-Oz` instead of `-O2`. That made a big difference:
https://github.com/guardianproject/tor-android/issues/18
This is related to #28764https://gitlab.torproject.org/legacy/trac/-/issues/32688Make tor_tls_get_buffer_sizes() work again2020-06-13T15:48:54ZNick 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.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32773Remove Jenkins tor master jobs which don't have OpenSSL 1.1.12020-06-13T15:49:13ZteorRemove Jenkins tor master jobs which don't have OpenSSL 1.1.1These jenkins tor master builds will fail after #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 i...These jenkins tor master builds will fail after #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/legacy/trac/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-06-13T15:51:48ZTracUnsuccessful 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: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33624Static building tor with openssl does not work2020-06-13T15:52:15ZDavid Gouletdgoulet@torproject.orgStatic building tor with openssl does not workWe have couple opened ticket about building OpenSSL statically: #31565 and #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 w...We have couple opened ticket about building OpenSSL statically: #31565 and #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.4.x-final