Hey,

following up on my still persisting openbsd issue (https://lists.torproject.org/pipermail/tor-relays/2020-July/018717.html) I reckon this might also a libressl issue.

I did as Roger suggested and set "usebridges 1 bridge ip:orport"

Tor[17665]: connection_or_init_conn_from_address(): init conn from address 192.68.11.219: 0000000000000000000000000000000000000000, <unset> (1) Tor[17665]: connection_or_set_identity_digest(): Set identity digest for 0x320be2f8110 ([scrubbed]): 0000000000000000000000000000000000000000 <unset>. Tor[17665]: connection_or_set_identity_digest(): (Previously: 0000000000000000000000000000000000000000 <unset>) Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_state (<gid=4 chan=1 proxy_type=0 state=1>) from orconn_event, on orconn. Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_state (<gid=4 chan=1 proxy_type=0 state=1>) from orconn_event, on orconn: Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: bto_state_rcvr(): ORCONN gid=4 chan=1 proxy_type=0 state=1 Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_status (<gid=4 status=0 reason=0>) from orconn_event, on orconn. Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_status (<gid=4 status=0 reason=0>) from orconn_event, on orconn: Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: connection_connect(): Connecting to [scrubbed]:443. Tor[17665]: connection_connect_sockaddr(): Connection to socket in progress (sock 9). Tor[17665]: connection_add_impl(): new conn type OR, socket 9, address 192.68.11.219, n_conns 4. Tor[17665]: channel_tls_connect(): Got orconn 0x320be2f8110 for channel with global id 1 Tor[17665]: channel_register(): Registering channel 0x320be0a4ae0 (ID 1) in state opening (1) with digest 0000000000000000000000000000000000000000 Tor[17665]: channel_register(): Channel 0x320be0a4ae0 (global ID 1) in state opening (1) registered with no identity digest Tor[17665]: channel_set_cell_handlers(): Setting cell_handler callback for channel 0x320be0a4ae0 to 0x320bca217e0 Tor[17665]: dispatch_send_msg_unchecked(): Queued: ocirc_chan (<gid=1 chan=1 onehop=1>) from ocirc_event, on ocirc. Tor[17665]: dispatcher_run_msg_cbs(): Delivering: ocirc_chan (<gid=1 chan=1 onehop=1>) from ocirc_event, on ocirc: Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: bto_chan_rcvr(): ORCONN LAUNCH chan=1 onehop=1 Tor[17665]: bto_update_best(): ORCONN BEST_ANY state -1->1 gid=4 Tor[17665]: Bootstrapped 5% (conn): Connecting to a relay Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: btc_chan_rcvr(): CIRC gid=1 chan=1 onehop=1 Tor[17665]: circuit_handle_first_hop(): connecting in progress (or finished). Good. Tor[17665]: conn_read_callback(): socket -1 wants to read. Tor[17665]: connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer. Tor[17665]: connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer. Tor[17665]: connection_dir_finished_flushing(): client finished sending command. Tor[17665]: conn_write_callback(): socket 9 wants to write. Tor[17665]: connection_or_finished_connecting(): OR connect() to router at 192.68.11.219:443 finished. Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_state (<gid=4 chan=1 proxy_type=0 state=3>) from orconn_event, on orconn. Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_state (<gid=4 chan=1 proxy_type=0 state=3>) from orconn_event, on orconn: Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: bto_state_rcvr(): ORCONN gid=4 chan=1 proxy_type=0 state=3 Tor[17665]: bto_update_best(): ORCONN BEST_ANY state 1->3 gid=4 Tor[17665]: Bootstrapped 10% (conn_done): Connected to a relay Tor[17665]: connection_tls_start_handshake(): starting TLS handshake on fd 9 Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 (before SSL initialization) Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state before SSL initialization [type=16,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state before SSL initialization [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write client hello [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write client hello [type=4098,val=-1]. Tor[17665]: tor_tls_handshake(): After call, 0x320be24e490 was in state SSLv3/TLS write client hello Tor[17665]: connection_tls_continue_handshake(): wanted read Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 (SSLv3/TLS write client hello) Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write client hello [type=4098,val=-1]. Tor[17665]: connection_tls_continue_handshake(): wanted read Tor[17665]: conn_read_callback(): socket 9 wants to read. Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 (SSLv3/TLS write client hello) Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write client hello [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS read server hello [type=4098,val=-1]. Tor[17665]: tor_tls_handshake(): After call, 0x320be24e490 was in state SSLv3/TLS read server hello Tor[17665]: connection_tls_continue_handshake(): wanted read Tor[17665]: conn_read_callback(): socket 9 wants to read. Tor[17665]: tor_tls_handshake(): About to call SSL_connect on 0x320be24e490 (SSLv3/TLS read server hello) Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS read server hello [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state TLSv1.3 read encrypted extensions [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS read server certificate request [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS read server certificate [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state TLSv1.3 read server certificate verify [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS read finished [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write change cipher spec [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write client certificate [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSLv3/TLS write finished [type=4097,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSL negotiation finished successfully [type=32,val=1]. Tor[17665]: tor_tls_debug_state_callback(): SSL 0x320be24e800 is now in state SSL negotiation finished successfully [type=4098,val=1]. Tor[17665]: tor_tls_handshake(): After call, 0x320be24e490 was in state SSL negotiation finished successfully Tor[17665]: control_event_network_liveness_update(): Sending NETWORK_LIVENESS UP Tor[17665]: dispatch_send_msg_unchecked(): Queued: orconn_state (<gid=4 chan=1 proxy_type=0 state=7>) from orconn_event, on orconn. Tor[17665]: dispatcher_run_msg_cbs(): Delivering: orconn_state (<gid=4 chan=1 proxy_type=0 state=7>) from orconn_event, on orconn: Tor[17665]: dispatcher_run_msg_cbs(): Delivering to btrack. Tor[17665]: bto_state_rcvr(): ORCONN gid=4 chan=1 proxy_type=0 state=7 Tor[17665]: bto_update_best(): ORCONN BEST_ANY state 3->7 gid=4 Tor[17665]: Bootstrapped 14% (handshake): Handshaking with a relay Tor[17665]: connection_or_process_cells_from_inbuf(): 9: starting, inbuf_datalen 0 (0 pending in tls object). Tor[17665]: conn_write_callback(): socket 9 wants to write. Tor[17665]: flush_chunk_tls(): flushed 11 bytes, 0 ready to flush, 0 remain. Tor[17665]: connection_handle_write_impl(): After TLS write of 11: 1227 read, 473 written Tor[17665]: scheduler_set_channel_state(): chan 1 changed from scheduler state IDLE to WAITING_FOR_CELLS Tor[17665]: download_status_log_helper(): [scrubbed] attempted 2 time(s); I'll try again in 2 seconds. Tor[17665]: fetch_bridge_descriptors(): ask_bridge_directly=1 (1, 1, 0) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: download_status_log_helper(): [scrubbed] attempted 3 time(s); I'll try again in 2 seconds. Tor[17665]: fetch_bridge_descriptors(): ask_bridge_directly=1 (1, 1, 0) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known) Tor[17665]: should_delay_dir_fetches(): Delaying dir fetches (no running bridges known)

For future reference here the link to the issue Felix created: https://gitlab.torproject.org/tpo/core/tor/-/issues/40128

Best Fran

On 20.09.20 13:06, Roger Dingledine wrote:

On Sun, Sep 20, 2020 at 12:57:46PM +0200, Felix wrote:

...

Libressl 321 is not compatible to what is needed to make the authorities tor26, dizum, gabel., maatu. and longc. happy (let them not grant a "Running"). What can that be?

Please somebody can _confirm_ this thing?

You're not crazy. We had a user on irc reporting a similar thing, and my guess at the time was also "libressl compatibility issue".

You can see it also by using a Tor client and setting "usebridges 1 bridge ip:port" where ip:port is your ORPort. If it's like the user from irc, it will get almost through the TLS handshake but not quite. That is, the Tor client will fail to bootstrap.

If you could open a gitlab issue for the mystery, that would be great!

--Roger

---

tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On 9/20/20 12:57 PM, Felix wrote:

Please somebody can _confirm_ this thing?

Much more worse:

The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%.

I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1.

Will roll back to 3.2.0 here

On 10/22/21 18:41, Felix wrote:

Hi All

Libressl 3.4.1 (devel) seems to run for us.

I don't have the exact commit(s), but this LibreSSL issue was fixed many months ago in OpenBSD snapshots, which everyone is now seeing with the more recent LibreSSL releases and the release of OpenBSD 7.0 a few weeks ago.

g

...

Oct 22 21:06:26.894 [notice] Tor 0.4.6.7 running on FreeBSD with

Libevent 2.1.12-stable, OpenSSL LibreSSL 3.4.1, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.5.0 and Unknown N/A as libc.

Am 20.09.2020 um 14:32 schrieb Toralf Förster:

...

On 9/20/20 12:57 PM, Felix wrote:

...

Please somebody can _confirm_ this thing?

Much more worse:

The relay here under a hardened Gentoo Linux with LibreSSL 3.2.1 has only 50% of the amount of the conenctions as with 3.2.0 at all - and the TCP traffic dropped down by nearly 100%.

I recompiled Tor to ensure, that it is not an ABI issue where API looks ok - Tor doesn't play well with LibreSSL 3.2.1.

Will roll back to 3.2.0 here

Toralf, it would be super nice if you could check on your end, or somebody else can confirm?

-- Cheers, Felix _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays