Opened 7 months ago

Last modified 6 months ago

#33648 assigned task

vanguards: What is the recommended value?

Reported by: cypherpunks Owned by: mikeperry
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: vanguards
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Since your default configuration & github document doesn't tell me much, I'd like to hear developer's opinion on this.

vanguards.conf

Bandguards:
circ_max_age_hours = 1 (Mine is just simple WWW service without fancy WebSockets, downloads or videos)
circ_max_hsdesc_kilobytes = 30
circ_max_megabytes = 5

Q1. Is using smaller value such as 1 for circ_max_age_hours have any problems regarding anonymity?

Q2. You didn't mention default size of hidden service descriptor. What value is it? This is not OnionShare or onionbalance.
(if you can do {circ_max_hsdesc_kilobytes != normal_desc_size kill_connection} that's great)

Q3. You said "HTTP GET can resume if this limit is hit, HTTP POST will not" in circ_max_megabytes. You better add this text, don't you think: "If the client reach this limit, we close the connection and create another one to continue operation. Client will experience small downtime."

Q4. Can you add an option to slow down packets on purpose, to prevent simple DDoS? e.g. 'limit_packets_per_seconds = 10' will allow 10 packets per seconds and delay exceeded packets (x) seconds

Child Tickets

Change History (9)

comment:1 Changed 7 months ago by pili

Component: ApplicationsCore Tor

comment:2 Changed 7 months ago by teor

Component: Core TorCore Tor/Tor
Keywords: vanguards added
Milestone: Tor: unspecified
Owner: set to asn
Status: newassigned

Hi asn, you might be the best person to answer this question, while mikeperry is busy?

comment:3 Changed 7 months ago by asn

Owner: changed from asn to mikeperry

Hmm, wrt Q1 and Q2 I think the default values mentioned in the top post make sense. Max descriptor size of 30kb seems fine. I think usually HSv3 descriptors are around 14kb.

I haven't looked at vanguards in a while, so I'm gonna pass this back to Mike in case he can answer these and the other questions.

comment:4 Changed 7 months ago by cypherpunks

circ_max_hsdesc_kilobytes = 30

I have no idea why this value is 30 (it's vanguard.conf's default) so I'm keeping it as is.

HSv3 descriptors are around 14kb

And this is what I wanted to learn. This valuable information should be documented inside vanguards.conf or github docs.

I'll set it to 20 to see how it breaks my https onionsite...

comment:5 Changed 7 months ago by mikeperry

Q1 - Smaller values for max circuit age may make you stand out a little. Completely idle circuits are held open for about an hour, give or take. If you never exceed an hour for them, you might stand out over a long period of time. 2 or 3 should not be noticeable, though. The main purpose of this option is to avoid deliberately held open application connections from keeping circuits and TLS streams opened so long that they are the only thing on the TLS connection (Tor relays rotate TLS connections about 1x/week).

Q3 - The retry of a truncated HTTP GET is not guaranteed. I think when asn and I tested onionshare, the GET was not actually resumed by Tor Browser, and/or onionshare shut down the service as soon as the GET got cut off..

Q4 - Packet rate can't easily be limited by the control port. You *might* be able to limit general data rate with BandwidthRate torrc option, but I am not 100% sure that will apply to onion service traffic. 'tc' scripts on Linux should definitely work, though. See https://github.com/mikeperry-tor/vanguards/issues/46

Last edited 7 months ago by mikeperry (previous) (diff)

comment:6 Changed 7 months ago by cypherpunks

Thank you for detailed answer. I'll set circ_max_age_hours to 4 for now.

I'm not linux master so I'm not sure how to use 'tc' option.
I found this instead:

# drop 1% of traffic
iptables -A INPUT -m statistic --mode random --probability 0.01 -j DROP

Should I add something like this to let Tor's outgoing connection drop randomly?
I just want to prevent "traffic timing attack" as much as possible.

comment:7 in reply to:  5 Changed 7 months ago by teor

Replying to mikeperry:

Q4 - Packet rate can't easily be limited by the control port. You *might* be able to limit general data rate with BandwidthRate torrc option, but I am not 100% sure that will apply to onion service traffic. 'tc' scripts on Linux should definitely work, though. See https://github.com/mikeperry-tor/vanguards/issues/46

BandwidthRate caps all tor traffic, with an allowed BandwidthBurst value. But you should test it, to check that it works the way you want. If it doesn't work, let us know, and we'll fix the bug.

But BandwidthRate is risky, because it also caps directory downloads. So a constantly-loaded client, onion service, or relay can go offline, because it can't download directory information.

RelayBandwidthRate / RelayBandwidthBurst only caps relayed traffic. So if you're running a relay, that's what you want. But it's a bit imprecise, because it will allow all traffic on any circuits that have been used for client directory downloads in the last 30 seconds. So again, test it to make sure it does what you expect.

We don't have an equivalent bandwidth rate option for client or onion service data (excluding directory downloads). Let us know if you need it, and we can open a ticket.

comment:8 in reply to:  5 ; Changed 6 months ago by Thernet

Replying to mikeperry:

Q1 - Smaller values for max circuit age may make you stand out a little.

"Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Service"
ISBN 978-1-939133-11-3

First, all circuits should have **similar lifetime**.
Client IP and hidden service IP lasts either a **very short or very long time**,
and this is **very identifying**.

Vanguards' circ_max_age_hours makes you unique. Are you sure this configurable parameter is safe to use for everyone?

comment:9 in reply to:  8 Changed 6 months ago by mikeperry

Replying to Thernet:

Replying to mikeperry:

Q1 - Smaller values for max circuit age may make you stand out a little.

"Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Service"
ISBN 978-1-939133-11-3

First, all circuits should have **similar lifetime**.
Client IP and hidden service IP lasts either a **very short or very long time**,
and this is **very identifying**.

Vanguards' circ_max_age_hours makes you unique. Are you sure this configurable parameter is safe to use for everyone?

The max is meant to be set waaayyy beyond onion service setup times -- as in hours or days. And it is a max. If a circuit is closing for other reasons, it does not keep it open. Our circuit padding defense handles this, though.

I do not think this is extremely fingerprintable, but it is noticeable at the guard in cases where your circuits do live this long and they get closed at exactly this time. It is arguable that maybe we should randomize this so we don't close on exactly this value, but it is also meant to be used as a safeguard against *really* long circuits, as in day-long or longer, since at that point intermeditate TLS connections may rotate and expose you to traffic analysis risks due to that.

Note that vanguards does not attempt to conceal its presence from client, local, or guard adversaries -- it is possible for both adversaries to determine you are using the addon. This is documented in the security document: https://github.com/mikeperry-tor/vanguards/blob/master/README_SECURITY.md

Search that document for vanguards for details. It is possible to tune some of those things to be less noticable, but at the end of the day, using 3 middles after your guard will be visible to your guard, unless you start spamming and try to look like a web crawler or something. Or we develop a circuit padding defense to conceal this.

Note: See TracTickets for help on using tickets.