Hi everybody This is early. Yesterday I upgraded Ichotolot60 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E from 4.2.7 to 4.4.5. Now I see in the consensus health: moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520 And _no_ Authority "owns" the relay. Old Apr 02 21:51:31.872 [notice] Tor 0.4.2.7 running on FreeBSD with Libevent 2.1.11-stable, OpenSSL LibreSSL 3.0.2, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.4. New Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. (Yeah, some Lib stuff is new too, hehe) The "Guard !Run Stab" consensus looks quite interesting to me. How can it be? Other relays with that nice "Guard !Run Stab" dropped off consensus over night (or since days) and no authority "owns" them too: HORUS1 0.4.4.4-rc norisknofun 0.3.5.10 ULayerKiriakou 0.4.3.5 Stellvia 0.4.3.6 torexit42 (StaleDesc) 0.4.1.6 torpidsDEhetzner1 0.4.3.2-alpha (3 days) karen (StaleDesc) 0.4.2.7 Stephen304 0.4.2.7 (3 days) Rigel2020 (StaleDesc) 0.4.3.6 dgplug (FallbackDir, StaleDesc) 0.4.4.5 =?= May-be the operators updated and are now in the same floating position? May-be this is super normal and came to my attention by surprise? Anyways, I let everthing run for a day or so. Time can heal. -- Cheers, Felix
Hi everybody
Sep 18 21:00:22.384 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.1, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Guard Stab V2Dir Valid dizum Fast Guard Stab V2Dir Valid gabel. Fast Stab V2Dir Valid bw=1130 danne. Fast Guard Run Stab V2Dir Valid maatu. Fast Stab V2Dir Valid bw=1200 farav. Fast Guard Run Stab V2Dir Valid bw=2970 longc. Fast Stab V2Dir Valid bw=490 bastet Fast Guard Run Stab V2Dir Valid bw=3520
2 hours after Libressl 321 -> 320 Sep 20 10:30:45.633 [notice] Tor 0.4.4.5 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.2.0, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.5. moria1 Fast Run Stab V2Dir Valid bw=566 tor26 Fast Run Stab V2Dir Valid dizum Fast Run Stab V2Dir Valid gabel. Fast Run Stab V2Dir Valid bw=1130 danne. Fast -Guard Run Stab V2Dir Valid maatu. Fast Run Stab V2Dir Valid bw=1200 farav. Fast -Guard Run Stab V2Dir Valid bw=2970 longc. !Fast Run Stab V2Dir Valid bw=70 bastet Fast -Guard Run Stab V2Dir Valid bw=3520 OWNER :: bwauth=gabelmoo
(Yeah, some Lib stuff is new too, hehe) 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? PS: We had the same trouble with Libressl 292 when 28x worked well and 30x too. PPS: Is that a good reason to stay away from automated updates? Ok, Libressl 321 is -devel .... -- Cheers, Felix
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
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:
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? Just upgraded here 2 tor-0.4.5.0 (Gentoo Linux, same ip) from 3.2.0 to 3.2.1 Will see how it works by restarting one of the two Tor instances...
-- Toralf
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
Hi All Libressl 3.4.1 (devel) seems to run for us.
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
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
On 10/23/21 12:41 AM, Felix wrote:
Toralf, it would be super nice if you could check on your end, or somebody else can confirm?
Hi, we here in Gentoo decided to stop supporting LibreSSL, so I cannot tell you if it would work here or not. -- Toralf
participants (5)
-
Felix -
Fran -
George -
Roger Dingledine -
Toralf Förster