-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate SecureDrop onion interfaces to v3 onion services #2951
Comments
v3 onion services provide numerous safety advantages for both admins and sources, with massive improvements to the cryptography involved (invalidating most of the concerns in the docs). It also makes it harder for HSDirs to know whether they are hosting the descriptors without knowing the .onion address, makes targeted DDoS attacks effectively impossible because the HSDir selection is randomised through per-day random consensus variables, as well as many other improvements. Since you can host both v2 and v3 onion services at the same time (though tor has supported v3 for a fairly long time now) we should just enable v3 and then provide both URLs to users (indicating that the longer URL is preferred). Not having v3 onion support (and outdated documentation saying that the cryptography is bad) should really be fixed. |
Yep we are in agreement - this is on the roadmap, we're hoping to get support for v3 onion support shipped with SecureDrop 0.15.0 (planned September 3rd release) |
@redshiftzero have you evaluated integrating Tor via TorControl port? This would make it possible to create and control ephemeral hidden services and eventually regenerate them. In GlobaLeaks we have experimented it by using https://github.com/meejah/txtorcon by @meejah (as we run on twisted) and we just rolled out Onion Services V3: globaleaks/globaleaks-whistleblowing-software#2582 The relevant code is here: |
For the next SecureDrop sprint (7/10-7/24), we're considering formalizing a migration plan in preparation for SecureDrop 1.0.0 release, which is intended to be the first to support v3 .onion services. |
Here is a blog post on setting up authorized v3 services https://kushaldas.in/posts/setting-up-authorized-v3-onion-services.html |
All done except #4630, which will likely not be done (but can be reopened and track independently if needed). |
Description
Next generation onion services are now in the latest stable Tor release, 0.3.2.9. We should have a migration path to enable v3 onion services alongside v2 onion services for source interfaces. Since our journalist and app/mon SSH onion services are stealth onion services (i.e. they use
HiddenServiceAuthorizeClient stealth
),we can't migrate those over until v3 stealth onion service support lands in stable, but we can migrate the source interfaces(support for v3 stealth onion services was added in 0.3.5.x, so we can migrate all interfaces).This can be done by adding an additional block in
torrc
on the app server containingHiddenServiceVersion 3
alongside v2, e.g.:We can continue to support v2 onion addresses for the foreseeable future until we have all instances moved over to v3. Given the action required from news organizations to add the v3 onion address to their landing pages / physical newspapers / etc., and the messaging they will need to need to do with any long-term sources to encourage them to move over to the v3 address, we'll need to coordinate with news organizations to make this change.
Subtickets
securedrop-admin sdconfig
should setv2_onion_services
andv3_onion_services
variablestor-hidden-services
ansible rolesecuredrop-admin tailsconfig
to use v3 if availableAlt-Srv
header in Apache configsUser Stories
As a SecureDrop source, I want to use the most secure version of onion services when I use a SecureDrop instance so that I minimize risk to myself.
The text was updated successfully, but these errors were encountered: