Hello David, David Goulet wrote: > Hi everyone! > > We are soon at the stage of implementing the service part of proposal 224 > (next gen. hidden service.). Parent ticket is #20657 but I'll be discussing > here ticket #18054. > > In a nutshell, we need to figure out the interface for the torrc file[1]. We > currently have some options to configure an hidden service and the question is > now how do we proceed on using those for next version? > > Instead of listing all options and going in an endless loop of possibilities, > I'll outline what we've discussed so far between some of us. In the following, > "v2" is current hidden service and "v3" is the next generation detailed in > prop224. > > 1) Once v3 is released, from that point on _no_ v2 service will be allowed to > be created by "tor" itself. It will always be possible to do it by hand by > creating an RSA key and putting it in the service directory (see 3 below). > > The reasoning for this is that we really want to phase out as quickly as > possible the v2 protocol for privacy and security reasons. > Perfect. Fully agree. > 2) All the current torrc options will be kept for v3 as they all apply in > terms of format. (One exception might be the client authorization.) > Very good. We can add a new torrc option for ed25519 key based authentication for clients (v3) so the current HiddenServiceAuthorizeClient (v2) will not break old torrc's until everyone upgrades. However, we could just add an auth-type value after HiddenServiceAuthorizeClient that will only work for v3. For example: HiddenServiceAuthorizeClient pubkey client-name,client-name,client-name,... It's obvious where 'pubkey' comes from, but it can be changed to anything. This way we preserve the option that it's already common for users (HiddenServiceAuthorizeClient), we maintain compatibility of torrcs during transition period and also have the same option in the future when we are fully migrated to v3. This is perfectly fine, since we do not use any auth method that works on v2 to v3 (which I am also super happy with). We also don't restrict ourselves from the possibility to add new auth-types for v3 in the future, should we need them. > 3) When tor is loading config for a service: > > if a v2 key is found that is an RSA key, we treat that service as v2, print > a deprecation warning and continue. > > if a v3 key is found, use v3, all is good. > > if no key is found, consider a new service and generate v3 (ties to 1 > above). > Great. > 4) Over time, extra option might appear and they will be ONLY for v3 unless > for force majeur security madness. > > One of those options that we want to add is this one as offline key will be > a reality with v3: > > "HiddenServiceOfflineKey 1" > > It will indicate tor to _not_ generate the master identity key and will > require the user to put the public key in the HiddenServiceDir. > > Note that with all of the above it will be possible to have one of your > application on both v2 and v3 address. Here is a snippet as an example: > > # v2 > HiddenServiceDir /srv/hs/v2 > HiddenServicePort 80 localhost:80 > > # v3 > HiddenServiceDir /srv/hs/v3 > HiddenServicePort 80 localhost:80 > > The important part here is the different directories but the port points to > the same place. > > Ok here it is. Please comment, improve, or propose! :) > > Cheers! > David > > [1] https://www.torproject.org/docs/tor-manual.html.en (see HIDDEN SERVICE OPTIONS) > Yes, this looks good to me as well. As for ADD_ONION, I think we should give the people that use it automatically for other apps a change until they upgrade to be compatible with v3, so for the transition period as long as v2 is supported (but not recommended) in the network, ADD_ONION controller command will create a v2 service, and we add another controller command: ADD_ONIONV3 that will create v3 services. When v2 is permanently gone, we make ADD_ONION a synonym to ADD_ONIONV3, remove the RSA1024/SHA1 code and we're all set.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev