Re: [tor-relays] building Tor against LibreSSL 2.1.1 fails with "undefined reference to `EVP_aes_128_ctr'" error
Date: Fri, 21 Nov 2014 07:22:10 -0800 From: Seth <list@sysfu.com>
I'm trying to build tor-0.2.5.10 from source against LibreSSL 2.1.1 on a FreeBSD 9.3x jail system.
It fails with this message
-----------------------------------
CC src/tools/tor-gencert.o CCLD src/tools/tor-gencert src/common/libor-crypto.a(aes.o): In function `aes_new_cipher': /usr/local/src/tor-0.2.5.10/src/common/aes.c:100: undefined reference to `EVP_aes_128_ctr' *** [src/tools/tor-gencert] Error code 1
Stop in /usr/local/src/tor-0.2.5.10. *** [all] Error code 1
Stop in /usr/local/src/tor-0.2.5.10.
--------------------------------------
Has anyone has any luck building Tor against LibreSSL?
Yes, on OS X, but it wasn't easy, and it didn't bootstrap for me due to SSL errors. Others have had more luck, but mostly on Linux AFAIK. Do you perhaps have a system-installed OpenSSL 0.9.* which is lacking EVP_aes_128_ctr? See https://trac.torproject.org/projects/tor/ticket/13817 for a similar failure, due to the following issues: configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables. configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X. If you do run into runtime SSL errors, see this bug: https://trac.torproject.org/projects/tor/ticket/13816 teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7wt...
On Sat, 22 Nov 2014 06:40:24 -0800, teor <teor2345@gmail.com> wrote:
Yes, on OS X, but it wasn't easy, and it didn't bootstrap for me due to SSL errors. Others have had more luck, but mostly on Linux AFAIK.
Do you perhaps have a system-installed OpenSSL 0.9.* which is lacking EVP_aes_128_ctr?
See https://trac.torproject.org/projects/tor/ticket/13817 for a similar failure, due to the following issues:
configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables. configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X.
If you do run into runtime SSL errors, see this bug: https://trac.torproject.org/projects/tor/ticket/13816
Thanks for the information. I was able to get the latest git version of Tor build against the libressl-2.1.1 pkg in a fresh FreeBSD 9x jail using the following steps: pkg install libressl autoconf git gmake gettext mkdir /usr/local/src;cd /usr/local/src;git clone https://git.torproject.org/git/tor cd tor;sh autogen.sh;./configure --with-openssl-dir=/usr/local --disable-asciidoc make;make install;tor Here's the terminal output when launching it: Nov 22 17:26:41.971 [notice] Tor v0.2.6.1-alpha-dev (git-336c856e52d211aa) running on FreeBSD with Libevent 2.0.21-stable, OpenSSL LibreSSL 2.1 and Zlib 1.2.8. Nov 22 17:26:41.971 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Nov 22 17:26:41.971 [notice] This version is not a stable Tor release. Expect more bugs than usual. Nov 22 17:26:41.972 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults. Nov 22 17:26:41.987 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 22 17:26:41.971 [notice] Tor v0.2.6.1-alpha-dev (git-336c856e52d211aa) running on FreeBSD with Libevent 2.0.21-stable, OpenSSL LibreSSL 2.1 and Zlib 1.2.8. Nov 22 17:26:41.971 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Nov 22 17:26:41.971 [notice] This version is not a stable Tor release. Expect more bugs than usual. Nov 22 17:26:41.972 [notice] Configuration file "/usr/local/etc/tor/torrc" not present, using reasonable defaults. Nov 22 17:26:41.987 [notice] Opening Socks listener on 127.0.0.1:9050 Nov 22 17:26:41.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Nov 22 17:26:42.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Nov 22 17:26:42.000 [warn] You are running Tor as root. You don't need to, and you probably shouldn't. Nov 22 17:26:42.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Nov 22 17:26:42.000 [notice] Bootstrapped 0%: Starting Nov 22 17:26:43.000 [notice] Bootstrapped 5%: Connecting to directory server Nov 22 17:26:43.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Nov 22 17:26:43.000 [notice] We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block. Nov 22 17:26:43.000 [notice] To correct this, use a version of OpenSSL built with none of its ciphers disabled. Nov 22 17:26:44.000 [notice] Bootstrapped 15%: Establishing an encrypted directory connection Nov 22 17:26:44.000 [notice] Bootstrapped 20%: Asking for networkstatus consensus Nov 22 17:26:45.000 [notice] Bootstrapped 25%: Loading networkstatus consensus Nov 22 17:26:47.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Nov 22 17:26:48.000 [notice] Bootstrapped 40%: Loading authority key certs Nov 22 17:26:49.000 [notice] Bootstrapped 45%: Asking for relay descriptors Nov 22 17:26:49.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6624, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of exit bw.) Nov 22 17:26:50.000 [notice] Bootstrapped 50%: Loading relay descriptors Nov 22 17:26:53.000 [notice] Bootstrapped 55%: Loading relay descriptors Nov 22 17:26:54.000 [notice] Bootstrapped 60%: Loading relay descriptors Nov 22 17:26:54.000 [notice] Bootstrapped 65%: Loading relay descriptors Nov 22 17:26:55.000 [notice] Bootstrapped 70%: Loading relay descriptors Nov 22 17:26:55.000 [notice] Bootstrapped 75%: Loading relay descriptors Nov 22 17:26:55.000 [notice] We now have enough directory information to build circuits. Nov 22 17:26:55.000 [notice] Bootstrapped 80%: Connecting to the Tor network Nov 22 17:26:55.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Nov 22 17:26:56.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Nov 22 17:26:56.000 [notice] Bootstrapped 100%: Done
On Sat, 22 Nov 2014 17:33:59 -0800, Seth <list@sysfu.com> wrote:
Thanks for the information. I was able to get the latest git version of Tor build against the libressl-2.1.1 pkg in a fresh FreeBSD 9x jail using the following steps:
pkg install libressl autoconf git gmake gettext mkdir /usr/local/src;cd /usr/local/src;git clone https://git.torproject.org/git/tor cd tor;sh autogen.sh;./configure --with-openssl-dir=/usr/local --disable-asciidoc make;make install;tor
Unfortunately after upgrading LibreSSL from 2.1.1 to 2.1.2 this method now fails with the error: src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1480: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1486: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1 I'll post a comment in the related Tor trac ticket
On Mon, Dec 22, 2014 at 5:54 PM, Seth <list@sysfu.com> wrote:
On Sat, 22 Nov 2014 17:33:59 -0800, Seth <list@sysfu.com> wrote:
Thanks for the information. I was able to get the latest git version of Tor build against the libressl-2.1.1 pkg in a fresh FreeBSD 9x jail using the following steps:
pkg install libressl autoconf git gmake gettext mkdir /usr/local/src;cd /usr/local/src;git clone https://git.torproject.org/git/tor cd tor;sh autogen.sh;./configure --with-openssl-dir=/usr/local --disable-asciidoc make;make install;tor
Unfortunately after upgrading LibreSSL from 2.1.1 to 2.1.2 this method now fails with the error:
src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1480: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1486: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1
I'll post a comment in the related Tor trac ticket
What version of Tor are you using here? I think we have this fixed in 0.2.6.1-alpha with this commit: d1fa0163e571913b8e4972c5c8a2d46798f46156 And this ticket: https://trac.torproject.org/projects/tor/ticket/13325 -- Nick
On Tue, 23 Dec 2014 06:33:44 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
What version of Tor are you using here? I think we have this fixed in 0.2.6.1-alpha with this commit: d1fa0163e571913b8e4972c5c8a2d46798f46156 And this ticket: https://trac.torproject.org/projects/tor/ticket/13325
I tried unsuccessfully with all three versions: stable, alpha and the latest from git. Tor builds no problem when using the previous LibreSSL version (2.1.1) on FreeBSD 9.3. As a side note, LibreSSL 2.1.2 also caused nginx builds using libressl as a dependency to fail. OpenSMTPD and Dovecot will still build successfully against LibreSSL 2.1.2 on the same system.
On Tue, Dec 23, 2014 at 12:00 PM, Seth <list@sysfu.com> wrote:
On Tue, 23 Dec 2014 06:33:44 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
What version of Tor are you using here? I think we have this fixed in 0.2.6.1-alpha with this commit: d1fa0163e571913b8e4972c5c8a2d46798f46156 And this ticket: https://trac.torproject.org/projects/tor/ticket/13325
I tried unsuccessfully with all three versions: stable, alpha and the latest from git.
Tor builds no problem when using the previous LibreSSL version (2.1.1) on FreeBSD 9.3.
Strange! There is code in git master that is supposed to prevent this. The current Tor's "find_cipher_by_id" is supposed to avoid looking at the get_cipher_by_id field. Do you really get the same errors with master, or is the error different? -- Nick
OK Seth, I need to ask you a random question. It is one from a man with attention deficit issues when it comes to certain things, but when I get the hang of something I am OK. There is so much to read on the whole For thing and I'll be damned if I can get Orbot to work on my rooted D 855 with Android L 5.0.2. Maths was not my strong point at school as you can imagine and binary a task and a half. I keep getting warning I am giving away public address and for not configured? I do so wish to understand and once I do I will donate to this cause. I hate corporate control!!! On 23 Dec 2014 17:17, "Nick Mathewson" <nickm@freehaven.net> wrote:
On Tue, Dec 23, 2014 at 12:00 PM, Seth <list@sysfu.com> wrote:
On Tue, 23 Dec 2014 06:33:44 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
What version of Tor are you using here? I think we have this fixed in 0.2.6.1-alpha with this commit: d1fa0163e571913b8e4972c5c8a2d46798f46156 And this ticket: https://trac.torproject.org/projects/tor/ticket/13325
I tried unsuccessfully with all three versions: stable, alpha and the latest from git.
Tor builds no problem when using the previous LibreSSL version (2.1.1) on FreeBSD 9.3.
Strange! There is code in git master that is supposed to prevent this. The current Tor's "find_cipher_by_id" is supposed to avoid looking at the get_cipher_by_id field. Do you really get the same errors with master, or is the error different?
-- Nick _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Tue, 23 Dec 2014 09:16:56 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
Strange! There is code in git master that is supposed to prevent this.
Yes, I thought it had been fixed by your commit from this ticket https://trac.torproject.org/projects/tor/ticket/13325
The current Tor's "find_cipher_by_id" is supposed to avoid looking at the get_cipher_by_id field. Do you really get the same errors with master, or is the error different?
Makes no difference, same error for master branch as the rest. latest Git - master branch - git clone https://git.torproject.org/git/tor ------------------------------------------------------------------------- # cd tor; git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean # sh autogen.sh ; ./configure --with-openssl-dir=/usr/local --disable-asciidoc ; make src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1478: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1484: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1 Alpha - https://www.torproject.org/dist/tor-0.2.6.1-alpha.tar.gz ---------------------------------------------------------------- #./configure --with-openssl-dir=/usr/local --disable-asciidoc ; make src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1478: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1484: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1 Stable - https://www.torproject.org/dist/tor-0.2.5.10.tar.gz ------------------------------------------------------------ # ./configure --with-openssl-dir=/usr/local --disable-asciidoc ; make src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1480: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1486: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1
On Wed, Dec 24, 2014 at 5:15 PM, Seth <list@sysfu.com> wrote:
On Tue, 23 Dec 2014 09:16:56 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
Strange! There is code in git master that is supposed to prevent this.
Yes, I thought it had been fixed by your commit from this ticket https://trac.torproject.org/projects/tor/ticket/13325
The current Tor's "find_cipher_by_id" is supposed to avoid looking at the get_cipher_by_id field. Do you really get the same errors with master, or is the error different?
Makes no difference, same error for master branch as the rest.
latest Git - master branch - git clone https://git.torproject.org/git/tor -------------------------------------------------------------------------
# cd tor; git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
# sh autogen.sh ; ./configure --with-openssl-dir=/usr/local --disable-asciidoc ; make
src/common/tortls.c: In function 'find_cipher_by_id': src/common/tortls.c:1478: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' src/common/tortls.c:1484: error: 'SSL_METHOD' has no member named 'get_cipher_by_char' *** [src/common/tortls.o] Error code 1
Huh. So, that code is wrapped inside a block that does #ifdef HAVE_STRUCT_SSL_METHOD_ST_GET_CIPHER_BY_CHAR And that macro is supposed to be defined by autoconf if it sees the get_cipher_by_char method in SSL_METHOD_ST. Hm. Maybe the problem is in our (notoriously wonky) SSL library detection! Maybe the autoconf script is looking at the headers in /usr/include, instead of /usr/local/include ? That would mess it up. Instead of using --with-openssl-dir=/usr/local, what happens if you set CFLAGS and LDFLAGS by hand when compiling? If that works, then the underlying bug here is actually the library detection issues in https://trac.torproject.org/projects/tor/ticket/13817 For the meantime, is there a compiler macro we can use to distinguish libressl from openssl at compile-time?
On Sun, 28 Dec 2014 16:01:12 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
Instead of using --with-openssl-dir=/usr/local, what happens if you set CFLAGS and LDFLAGS by hand when compiling?
Maybe something like this would work? CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure
On Thu, 01 Jan 2015 10:55:18 -0800, Seth <list@sysfu.com> wrote:
On Sun, 28 Dec 2014 16:01:12 -0800, Nick Mathewson <nickm@freehaven.net> Maybe something like this would work?
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure
That resolves the tortls.o error, thanks! This is the line I used for OpenBSD: env CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure --disable-asciidoc --sysconfdir=/etc
On Sun, 28 Dec 2014 16:01:12 -0800, Nick Mathewson <nickm@freehaven.net> wrote:
Maybe the autoconf script is looking at the headers in /usr/include, instead of /usr/local/include ? That would mess it up.
Instead of using --with-openssl-dir=/usr/local, what happens if you set CFLAGS and LDFLAGS by hand when compiling?
I tried to find out how to do this by myself but I don't understand very well how these flags work. Could you please provide some examples and I'll test? Also of note, I was able to get tor-0.2.6.2-alpha to build succesfully on a the release version of OpenBSD 5.6 which includes LibreSSL 2.0-something. When I tried to build tor-0.2.6.2-alpha against libressl 2.1.2 on the same system using ./configure --with-openssl-dir=/usr/local it bails out with same the tortls.o error.
For the meantime, is there a compiler macro we can use to distinguish libressl from openssl at compile-time?
Do not know.
participants (4)
-
Graeme Briggs-White -
Nick Mathewson -
Seth -
teor