On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd adrian@freebsd.org wrote:
... that's .. odd.
Let's poke the freebsd crypto and network stack people and ask. I can't imagine why this is a problem anymore and we should default to it being on.
I don't think there's a crypto@ list, though security@ might represent.
The other thing you could do is have the tor port require it be turned on before tor runs.
That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki.
On 7 November 2014 00:20, grarpamp grarpamp@gmail.com wrote:
On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter phw@nymity.ch wrote:
FreeBSD still seems to use globally incrementing IP IDs by default. That's an issue as it leaks fine-grained information about how many packets a relay's networking stack processes. (However, nobody investigated the exact impact on Tor relays so far, which makes this a FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD relays I tested (38%) use global IP IDs.
There's a sysctl variable called "net.inet.ip.random_id" which makes a FreeBSD's IP ID behaviour random. FreeBSD relay operators should set this to "1".
Note that this issue was already discussed earlier this year in a thread called "Lots of tor relays send out sequential IP IDs; please fix that!".
It's been default off since before it was a sysctl over a decade ago. Anyone know what the deal is with that? Some objection, or forgotten flag day, or oversight that really should be set to 1? https://svnweb.freebsd.org/base?view=revision&revision=133720