Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#4721 closed defect (fixed)

Control socket available prior to generating DH modulus

Reported by: atagar Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: dynamic-dh tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


The control socket is made available prior to a lengthy crypto operation which causes any input on to that socket to be ignored for something on the order of minutes. This in turn causes any controllers to either hang or need to implement timeouts for control responses (thankfully those haven't been necessary previously).

If we could reorder the startup activity so the DH modulus generation happened before opening the control socket then that would be perfect.

Flagging this as major since it's gonna cause a lot of sadness for first time tor users.

irc context...
08:13 < atagar> I'm trying to reproduce the arm issue mentioned on tor-talk and getting something odd from
08:13 < atagar> Dec 15 08:09:59.000 [notice] Generating fresh dynamic DH modulus. This might take a while...
08:13 < atagar> What does that log message mean? While that's going on controller requests hang (for instance, when I issue a PROTOCOLINFO I didn't get any response until I gave up and killed the process). Unfortunately this makes arm hang (and probably any other controller that tries to attach).
08:13 < atagar> It would be nice if tor rejected the socket if it can't handle controller commands - shall I file a bug about this?
08:14 < atagar> nickm:
08:15 < nickm> atagar: It means that Tor is doing some cryptoish math to generate a modulus.
08:15 < nickm> it will take a while.
08:15 < nickm> it will happen on startup once, and will eat a bunch of cpu
08:16 < atagar> Gotcha, thanks. Can it happen before opening a control socket?
08:19 < nickm> I don't know. It's possible, I think

Child Tickets

Change History (11)

comment:1 Changed 9 years ago by asn


please note that this procedure will only happen once during the lifetime of a Tor relay. In subsequent relay restarts, tor will simply load the generated thing off the hard disk.

I'll try to see if reordering the startup order is possible, so that the DH generation happens before opening the control socket.

comment:2 Changed 8 years ago by ioerror

It seems like it makes sense to not block. I believe that Tor should be generating that DH parameter as soon as possible and giving output to controllers the entire time.

comment:3 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-final
Priority: majornormal

Marking this as 'normal, 0.2.4.x" now that the "generate your own DH modulus" feature is now off-by-default.

For my two cents, the sanest approach is to generate the DH modulus in a separate thread, and let the rest of Tor go on apace. Blocking at all is silly. The challenge would be making sure we don't open any TLS listeners until the modulus is done.

comment:4 Changed 8 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.3.x-final

Okay, I apparently got confused by an alternate reality. "DynamicDHGroups" is still on by default, so this matters for 0.2.3.

comment:5 Changed 8 years ago by arma

How about we turn DynamicDHGroups off in 0.2.3, and move this back to 0.2.4? :)

comment:6 Changed 8 years ago by nickm

Fair idea; needs a ticket.

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

Replying to nickm:

Fair idea; needs a ticket.

I have gone back in time and entered it as ticket #5598.

comment:8 Changed 8 years ago by nickm

Keywords: dynamic-dh added

comment:9 Changed 8 years ago by nickm

Resolution: fixed
Status: newclosed

DynamicDHGroups is off in 0.2.3 (#5598); there is a ticket for generating DH groups asynchonously if we must generate them (#6089). Closing this.

comment:10 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:11 Changed 8 years ago by nickm

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