Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#5146 closed defect (fixed)

Bridges include or-address [::]:$port in their server descriptor

Reported by: karsten Owned by: ln5
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version: Tor: 0.2.3.12-alpha
Severity: Keywords: tor-bridge
Cc: murble Actual Points:
Parent ID: #4563 Points:
Reviewer: Sponsor:

Description

Since yesterday 16:05 UTC, metrics-db is complaining about or-address lines in bridge server descriptors that it cannot parse and sanitize. Here are two server descriptors it doesn't like with [scrubbed] parts put in by me:

router Unnamed [scrubbed] 9001 0 0
or-address [::]:9001
platform Tor 0.2.3.12-alpha (git-5c7b9174848cc05b) on Linux i686
opt protocols Link 1 2 Circuit 1
published 2012-02-15 21:08:13
...
router Unnamed [scrubbed] 443 0 0
or-address [::]:9090
platform Tor 0.2.3.12-alpha (git-5c7b9174848cc05b) on Linux x86_64
opt protocols Link 1 2 Circuit 1
published 2012-02-16 03:37:30
...

The [::] address part probably comes from some misconfiguration on the bridge. But the bridge shouldn't include this address in its server descriptor.

I'm cc'ing murble who is running these bridges. (Maybe don't fix the configuration yet, so that we can figure out how to fix Tor.)

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by karsten

#5143 may be related here.

comment:2 Changed 7 years ago by murble

# My tor configs
ORPort 0.0.0.0:443 NoListen
ORPort "[::]:9090 IPv6Only"
ORPort "0.0.0.0:9090"
ContactInfo murb@oftc
BridgeRelay 1
ExitPolicy reject *:*
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=warn --log-file=/var/log/tor/obfsproxy.log --managed

# and
ORPort "0.0.0.0:9001"
ORPort "[::]:9001 IPv6Only"
ContactInfo IRC://murble@oftc
BridgeRelay 1
ExitPolicy reject *:*
ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --log-min-severity=warn --log-file=/var/log/tor/obfsproxy.log --managed

comment:3 Changed 7 years ago by ln5

We get the IPv4 address from router_pick_published_address() which
first tries resolve_my_address() and then, if that fails, tries to get
it from HTTP headers received from "a peer".

router_pick_published_address() bases its work on what's in torrc 'Address'

comment:4 Changed 7 years ago by ln5

Status: newassigned

(Slipped on submit.)

router_rebuild_descriptor() gets ri->ipv4h_addr from
router_pick_published_address() while ri->ipv6_orport comes from
configuration, non-sanitized.

router_pick_published_address() first tries resolve_my_address() and
then, if that fails, tries to get it from HTTP headers received from
"a peer".

Should we turn resolve_my_address() into resolve_my_addresses() and
teach it about IPv6? get_interface_address6() used here needs some
work for #4806 too.

As a minimal approach, we should check IPv6 ORPort's from config with
tor_addr_is_internal(for_listening=1). This will catch '[::]'. And
document the importance of configuring an IPv6 ORPort with some extra
care for the time being.

comment:5 Changed 7 years ago by ln5

Parent ID: #4563

comment:6 in reply to:  4 Changed 7 years ago by nickm

Replying to ln5:

(Slipped on submit.)

router_rebuild_descriptor() gets ri->ipv4h_addr from
router_pick_published_address() while ri->ipv6_orport comes from
configuration, non-sanitized.

router_pick_published_address() first tries resolve_my_address() and
then, if that fails, tries to get it from HTTP headers received from
"a peer".

Should we turn resolve_my_address() into resolve_my_addresses() and
teach it about IPv6? get_interface_address6() used here needs some
work for #4806 too.

That seems like a plausible solution. Other options include looking at gethostname() of the listener socket, but resolving your address is probably the better bet.

As a minimal approach, we should check IPv6 ORPort's from config with
tor_addr_is_internal(for_listening=1). This will catch '[::]'. And
document the importance of configuring an IPv6 ORPort with some extra
care for the time being.

Right.

comment:7 Changed 7 years ago by ln5

We _do_ check IPv6 ORPort's using
tor_addr_is_internal(for_listening=1) which returns 0 for [::].

Setting for_listening=0 will do what we want to -- stop [::] from
being accepted -- so that's what I'll do for a short term solution.

What's a good place for telling bridge operators to not use [::] for
now?

comment:8 Changed 7 years ago by ln5

Status: assignedneeds_review

Please see bug5146 in my repo for the short term fix.

I think we should merge this (if it's found to be correct) and open a
new ticket for the real solution.

comment:9 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:10 Changed 7 years ago by nickm

Seems okay to me for now. I'll merge this; we can close once somebody has a chance to "open a ticket for the real solution".

comment:11 Changed 6 years ago by ln5

Resolution: fixed
Status: needs_reviewclosed

See #5940 for a more complete solution.

comment:12 Changed 6 years ago by nickm

Keywords: tor-bridge added

comment:13 Changed 6 years ago by nickm

Component: Tor BridgeTor
Note: See TracTickets for help on using tickets.