Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5598 closed enhancement (implemented)

Turn DynamicDHGroups off by default

Reported by: rransom Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: dynamic-dh tor-relay
Cc: asn, ioerror, marsh@…, iang Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The DynamicDHGroups feature has at least one significant implementation bug (#4721 is about the least bad consequence of generating group parameters in Tor's main thread), and it can only harm Tor's resistance to DPI attacks, not help. It should be turned off by default.

Child Tickets

Change History (23)

comment:1 Changed 7 years ago by arma

I'd be fine with turning it off by default. My intuition about DPI is that looking like something they expect is better than looking like a different unexpected thing each time.

comment:2 Changed 7 years ago by arma

Cc: asn ioerror added

comment:3 Changed 7 years ago by ioerror

I think it should be enabled for bridges by default, personally. I'd even argue that it should be enabled for relays as well but not as strongly.

While I like the idea of being uniform, I think we're never going to be uniform and so, we should build uniform transports if that is a claim we want to make.

Specifically, I want to use 2048bit DH at some point and that will make us stick out, even if with have a 2048 RSA - But the DH size *must* go up for security reasons, so we're sorta going to have to bite the bullet on protocol distinguishers to ensure that we stay way way ahead of the crypto cracking curve.

comment:4 Changed 7 years ago by nickm

I would really like to see data here. Does the SSL observatory track DH size and modulus?

Specifically, I want to use 2048bit DH at some point and that will make us stick out,

Actually, I think that P256 is seeing some high-profile adoption; it might be a better choice. That's not this bug though.

comment:5 Changed 7 years ago by nickm

So the downside of leaving the option on here is that the delay in initial startup time makes controllers see various kinds of weird behavior.

The downside of turning it off is that we use the default mod_ssl DH group, which:

  • was generated according to an non-reproducible process (if I recall correctly). But I'm not aware of any attack where a DH group that passes all of the strong prime tests is nonetheless flawed, so this one doesn't bug me too much.
  • might get blocked someday, if a censor is willing to block every mod_ssl installation that negotiates DH with the default group.

Neither side seems completely compelling; any more upsides/downsides to add?

looking like something they expect is better than looking like a different unexpected thing each time.

BTW, we don't look like a different unexpected thing each time: we use the same DH parameters for each response, and we look like an expected thing, which is "a server that has generated its own DH parameters". They're all over.

comment:6 in reply to:  5 Changed 7 years ago by arma

Replying to nickm:

  • might get blocked someday, if a censor is willing to block every mod_ssl installation that negotiates DH with the default group.

While we're talking about people who might block all apache ssl servers, consider people who might block every ssl handshake *except* apache ssl servers.

Both seem far enough down the arms race that we're not going to predict much at this point.

comment:7 Changed 7 years ago by mikeperry

Component: Tor RelayTor Client
Milestone: Tor: 0.2.3.x-final
Priority: normalminor

I think it's foolish to make a network-wide decision based on local control port properties.

Even if a randomized DH modulus is bad for fingerprinting, if it's good for PFS, we should just use obsfproxy to remove visibility of it.

rransom: Were you just testing us? Was that the answer you wanted? ;)

comment:8 Changed 7 years ago by arma

Component: Tor ClientTor Relay

How is sticking to one prime good for PFS? Is it the theory that apache's prime, which passes all known tests, might somehow secretly have a trapdoor in it?

comment:9 Changed 7 years ago by arma

(I'm told by crypto people that once you're at the point you can brute force one 1024 bit dh prime, the rest follow pretty quickly.)

comment:10 Changed 7 years ago by mikeperry

Cc: marsh@… added

I think choosing a random "prime" chosen from available primes of the same bitwidth is better for PFS, assuming the apache prime passes the same level of known primality tests as our ad-hoc primes pass, and also assuming that these primatilty tests are actually valid.

The reason I think ad-hoc primes are better for PFS is because of the possibility of time-space tradeoff attacks against specific prime groups. Seems plausible to me that certain small-ish prime groups might have precomputed tables to expedite the discrete log.

Maybe DH-1024 is too big for these types of attacks, but hey, I'm not the one who thinks it's actually useful to build a datacenter in Utah to record all data for future cryptanalysis.

Also note: I am not a cryptographer. I just play one on tv.

comment:11 Changed 7 years ago by mikeperry

Cc: iang added

Ian: You're actually a cryptographer. Thoughts?

comment:12 in reply to:  10 ; Changed 7 years ago by iang

Replying to mikeperry:

Also note: I am not a cryptographer. I just play one on tv.

Hey, that's my line! ;-)

If we're worried about the difference between solving DLs in a single, common, 1024-bit Zp group versus solving it for lots of different 1024-bit Zp groups, then our prime is way too small. You don't want to be anywhere near the place where even one (random) problem of that size could be solved (with acceptable probability in reasonable time).

It's true that precomputation tables make it faster to compute DLs for a fixed prime once you've built the tables, but if they can do it once, in a few years, they'll probably be able to do it often.

comment:13 in reply to:  12 ; Changed 7 years ago by mikeperry

Replying to iang:

If we're worried about the difference between solving DLs in a single, common, 1024-bit Zp group versus solving it for lots of different 1024-bit Zp groups, then our prime is way too small. You don't want to be anywhere near the place where even one (random) problem of that size could be solved (with acceptable probability in reasonable time).

I agree. But we're sort of stuck there for about another year though, I bet. :/

It's true that precomputation tables make it faster to compute DLs for a fixed prime once you've built the tables, but if they can do it once, in a few years, they'll probably be able to do it often.

Ah, right. So either way the "P" in PFS is probably gone eventually for specific traffic streams...

Personally though, my choice would be for the bastards to have to have at least a few more cages full of machines occupied by computing and storing DL tables rather than actual people's unconstitutionally obtained personal data :)

If it were up to me, I wouldn't even store the dynamic DH modulus on disk at all.. Let it rotate early and often (again, assuming the ones we generate are just as "prime" as the apache prime).

After all, there are a fairly large number of these primes to choose from (something around O(21014), right?).. Like Pokemon, They gotta collect 'em all...

And by then, we'll have upgraded our DH handshake either to EC or larger primes.

comment:14 in reply to:  13 Changed 7 years ago by mikeperry

Replying to mikeperry:

Personally though, my choice would be for the bastards to have to have at least a few more cages full of machines occupied by computing and storing DL tables rather than actual people's unconstitutionally obtained personal data :)

If it were up to me, I wouldn't even store the dynamic DH modulus on disk at all.. Let it rotate early and often (again, assuming the ones we generate are just as "prime" as the apache prime).

For the lullz: https://gitweb.torproject.org/mikeperry/tor.git/log/refs/heads/OccupyUtah

comment:15 Changed 7 years ago by mikeperry

Priority: minormajor
Summary: Turn DynamicDHGroups off by defaultGenerate DH groups asynchronously when we change TLS keys

More seriously, rransom: would this retitling solve your problems?

We already rotate our TLS keys every two hours. Why not also rotate the DH group then, too? If we did both at the same time, they shouldn't block the control port like the DH one does, right? After all, TLS key generation doesn't block... Haven't looked at the code for that bit yet, though...

Slightly more complicated fix, but it sounds more like the right one.

comment:16 Changed 7 years ago by nickm

Generating DH groups can take minutes to tens of minutes on hardware where RSA key generation takes only tiny fractions of a second. They're very different operations.

Also, rotating your DH groups frequently is even weirder than rotating your client-visible TLS keys frequently; I worry that we'd stand out lots.

comment:17 Changed 7 years ago by nickm

So my current thinking here is that this option doesn't actually help fingerprinting resistance or PFS much.

I can be persuaded otherwise wrt fingerprinting if I get data that the mod_ssl prime is actually rare in the wild.

With respect to the PFS case, I believe Ian: the right solution for PFS is a better group, not more DH groups. In 0.2.4.x, we're hoping to move to a better, similarly popular group (say, P256). (With Chrome's use of it, and recent openssl improvements, I'd be surprised if P256 is less common than "DH in Z_p with a randomly generated 2048-bit prime".)

comment:18 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final
Summary: Generate DH groups asynchronously when we change TLS keysTurn DynamicDHGroups off by default

(To throw some numbers on the usability issue: with a few experiments, it stalls my heftiest box by 2-15 seconds. It stalls my least hefty still-in-use laptop by 5-76 sec.)

WRT the fingerprinting issue: using nonstandard keys is actually a downside, if we want blocked bridges to be able to change their IPs and become unblocked.

(Changing the title back. If you want to do a different solution, please open a different ticket.)

comment:19 Changed 7 years ago by nickm

Keywords: dynamic-dh added


comment:20 Changed 7 years ago by nickm

Status: newneeds_review

Branch bug5598 in my public repo has the default change and the attendant documentation.

I also added bugs #6087 and #6089 for the issues we'd need to solve to turn this back on safely and usably.

comment:21 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Okay, merged this. It's sad to disable a feature, but the cost/benefit here is not in its favor, especially until #6087 is fixed.

comment:22 Changed 7 years ago by nickm

Keywords: tor-relay added

comment:23 Changed 7 years ago by nickm

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