This project is archived. Its data is
read-only
.
Changes
Page history
Raw import from Trac using Trac markup language.
authored
Jun 15, 2020
by
Alexander Hansen Færøy
Hide whitespace changes
Inline
Side-by-side
doc/TorFragileHardening.md
0 → 100644
View page @
53a16e3a
== Should I use --enable-expensive-hardening? ==
Does "expensive-hardening" makes your Tor
more secure or less secure? The answer isn't obvious!
The 'expensive-hardening' option replaces a number of underlying bugs
with aborts. If any of these underlying bugs was remotely
triggerable, it becomes a remotely triggerable abort.
Some possible underlying bugs here are actually harmless -- like the
integer underflow bug here in TROVE-2017-001, or the
read-one-extra-byte bug of TROVE-2016-12-002[
*
]. So long as any bugs
like these bugs exist, "expensive-hardening" will make your Tor more
vulnerable to remote denial of service.
But some possible underlying bugs are potential trouble -- like if we
had an actual stack overflow bug or a heap overflow bug.
"expensive-hardening" can replace some of these with aborts too. So
long as any bugs like these bugs exist, "expensive-hardening" makes it
a little more difficult to do RCE or heartbleed-style leaks against
your Tor.
The first kind of bug seems much more common in practice over Tor's
history. But the impact of the second kind would be significantly worse.
So using "expensive-hardening" in production means "Make me much more
vulnerable to remote DoS, but (probably) less vulnerable to RCE or
heartbleed."
I don't think that's an obvious "yes", but I'm also not totally sure
it's an obvious "no".