<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi All,<div class=""><br class=""></div><div class="">Please find below and attached a proposal: Rendezvous Single Onion Services.</div><div class=""><br class=""></div><div class="">This is an updated and expanded version of "Direct Onion Services: Fast-but-not-hidden services”. </div><div class="">It also borrows heavily from "Single Onion Services" (Proposal #252).</div><div class=""><br class=""></div><div class="">The proposal is available in the branch “feature-17178-rsos” at <a href="https://github.com/teor2345/torspec.git" class="">https://github.com/teor2345/torspec.git</a> as</div><div class="">torspec/proposals/ideas/xxx-rend-single-onion.txt</div><div class=""><br class=""></div><div class=""><div class="">Work on this proposal is being tracked in trac ticket #17178 at</div><div class=""><a href="https://trac.torproject.org/projects/tor/ticket/17178" class="">https://trac.torproject.org/projects/tor/ticket/17178</a></div></div><div class=""><br class=""></div><div class="">There is a basic implementation in the branch “feature-17178-rsos” at <a href="https://github.com/teor2345/tor.git" class="">https://github.com/teor2345/tor.git</a></div><div class=""><br class=""></div><div class="">This can be tested with the chutney branch "feature-17178-rsos” at <a href="https://github.com/teor2345/chutney.git" class="">https://github.com/teor2345/chutney.git</a> using the command:</div><div class="">src/test/test-network.sh --flavor rsos-min</div><div class=""><br class=""></div><div class="">Regards,</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><div class="">-----</div><div class=""><div class="">Filename: xxx-rend-single-onion.txt</div><div class="">Title: Rendezvous Single Onion Services</div><div class="">Author: Tim Wilson-Brown, John Brooks, Aaron Johnson, Rob Jansen, George Kadianakis, Paul Syverson, Roger Dingledine</div><div class="">Created: 2015-10-17</div><div class="">Status: Draft</div><div class=""><br class=""></div><div class="">1. Overview</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services are an alternative design for single onion</div><div class=""> services, which trade service-side location privacy for improved</div><div class=""> performance, reliability, and scalability.</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services have a .onion address identical to any</div><div class=""> other onion service. The descriptor contains the same information as the</div><div class=""> existing double onion (hidden) service descriptors. The introduction point</div><div class=""> and rendezvous protocols occur as in double onion services, with one</div><div class=""> modification: one-hop connections are made from the onion server to the</div><div class=""> introduction and rendezvous points.</div><div class=""><br class=""></div><div class=""> This proposal is a revision of the unnumbered proposal Direct Onion</div><div class=""> Services: Fast-but-not-hidden services by Roger Dingledine, and George</div><div class=""> Kadianakis at</div><div class=""> <a href="https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html" class="">https://lists.torproject.org/pipermail/tor-dev/2015-April/008625.html</a></div><div class=""><br class=""></div><div class=""> It incorporates much of the discussion around hidden services since April</div><div class=""> 2015, including content from Single Onion Services (Proposal #252) by John</div><div class=""> Brooks, Paul Syverson, and Roger Dingledine.</div><div class=""><br class=""></div><div class="">2. Motivation</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services are best used by sites which:</div><div class=""> * Don’t require location anonymity</div><div class=""> * Would appreciate lower latency or self-authenticated addresses</div><div class=""> * Would like to work with existing tor clients and relays</div><div class=""> * Can’t accept connections to an open ORPort</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services have a few benefits over double onion</div><div class=""> services:</div><div class=""><br class=""></div><div class=""> * Connection latency is lower, as one-hop circuits are built to the</div><div class=""> introduction and rendezvous points, rather than three-hop circuits</div><div class=""> * Stream latency is reduced on a four-hop circuit</div><div class=""> * Less Tor network capacity is consumed by the service, as there are</div><div class=""> fewer hops (4 rather than 6) between the client and server via the</div><div class=""> rendezvous point</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services have a few benefits over single onion</div><div class=""> services:</div><div class=""><br class=""></div><div class=""> * A rendezvous single onion service can load-balance over multiple</div><div class=""> rendezvous backends (see proposal #255)</div><div class=""> * A rendezvous single onion service doesn't need an accessible ORPort</div><div class=""> (it works behind a NAT, and in server enclaves that only allow</div><div class=""> outward connections)</div><div class=""> * A rendezvous single onion service is compatible with existing tor</div><div class=""> clients, hidden service directories, introduction points, and</div><div class=""> rendezvous points</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services have a few drawbacks over single onion</div><div class=""> services:</div><div class=""><br class=""></div><div class=""> * Connection latency is higher, as one-hop circuits are built to the</div><div class=""> introduction and rendezvous points. Single onion services perform one</div><div class=""> extend to the single onion service’s ORPort only</div><div class=""><br class=""></div><div class=""> It should also be noted that, while single onion services receive many</div><div class=""> incoming connections from different relays, rendezvous single onion</div><div class=""> services make many outgoing connections to different relays. This should</div><div class=""> be taken into account when planning the connection capacity of the</div><div class=""> infrastructure supporting the onion service.</div><div class=""><br class=""></div><div class=""> Rendezvous single onion services are not location hidden on the service</div><div class=""> side, but clients retain all of the benefits and privacy of onion</div><div class=""> services. (The rationale for the 'single' and 'double' nomenclature is</div><div class=""> described in section 7.4 of proposal #252.)</div><div class=""><br class=""></div><div class=""> We believe that it is important for the Tor community to be aware of the</div><div class=""> alternative single onion service designs, so that we can reach consensus</div><div class=""> on the features and tradeoffs of each design. However, we recognise that</div><div class=""> each additional flavour of onion service splits the anonymity set of onion</div><div class=""> service users. Therefore, it may be best for user anonymity that not all</div><div class=""> designs are adopted, or that mitigations are implemented along with each</div><div class=""> additional flavour. (See sections 8 & 9 for a further discussion.)</div><div class=""><br class=""></div><div class="">3. Onion descriptors</div><div class=""><br class=""></div><div class=""> The rendezvous single onion descriptor format is identical to the double</div><div class=""> onion descriptor format.</div><div class=""><br class=""></div><div class="">4. Reaching a rendezvous single onion service as a client</div><div class=""><br class=""></div><div class=""> Clients reach rendezvous single onion services in an identical fashion</div><div class=""> to double onion services. The rendezvous design means that clients do not</div><div class=""> know whether they are talking to a double or rendezvous single onion</div><div class=""> service, unless that service tells them. (This may be a security issue.)</div><div class=""><br class=""></div><div class=""> However, the use of a four-hop path between client and rendezvous single</div><div class=""> onion service may be statistically distinguishable. (See section 8 for</div><div class=""> further discussion of security issues.)</div><div class=""><br class=""></div><div class=""> (Please note that this proposal follows the hop counting conventions in the</div><div class=""> tor source code. A circuit with a single connections between the client and</div><div class=""> the endpoint is one-hop, a circuit with 4 connections (and 3 nodes) between</div><div class=""> the client and endpoint is four-hop.)</div><div class=""><br class=""></div><div class="">5. Publishing a rendezvous single onion service</div><div class=""><br class=""></div><div class=""> To act as a rendezvous single onion service, a tor instance (or cooperating</div><div class=""> group of tor instances) must:</div><div class=""><br class=""></div><div class=""> * Publish onion descriptors in the same manner as any onion service,</div><div class=""> using three-hop circuits. This avoids service blocking by IP address,</div><div class=""> proposal #224 (next-generation hidden services) avoids blocking by</div><div class=""> onion address.</div><div class=""> * Perform the rendezvous protocol in the same manner as a double</div><div class=""> onion service, but make the intro and rendezvous connections one-hop.</div><div class=""> (This may allow intro and rendezvous points to block the service.)</div><div class=""><br class=""></div><div class="">5.1. Configuration options</div><div class=""><br class=""></div><div class="">5.1.1 RendezvousSingleOnionServiceNonAnonymousServer</div><div class=""><br class=""></div><div class=""> The tor instance operating a rendezvous single onion service must make</div><div class=""> one-hop circuits to the introduction and rendezvous points:</div><div class=""><br class=""></div><div class=""> RendezvousSingleOnionServiceNonAnonymousServer 0|1</div><div class=""> If set, make one-hop circuits between the Rendezvous Single Onion</div><div class=""> Service server, and the introduction and rendezvous points. This</div><div class=""> option makes every onion service instance hosted by this tor instance</div><div class=""> a Rendezvous Single Onion Service. (Default: 0)</div><div class=""><br class=""></div><div class=""> Because of the grave consequences of misconfiguration here, we have added</div><div class=""> ‘NonAnonymous’ to the name of the torrc option. Furthermore, Tor MUST issue</div><div class=""> a startup warning message to operators of the onion service if this feature</div><div class=""> is enabled.</div><div class=""> [Should the name start with ‘NonAnonymous’ instead?]</div><div class=""><br class=""></div><div class=""> As RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour</div><div class=""> of every onion service on a tor instance, it is impossible to run hidden</div><div class=""> (double onion) services and rendezvous single onion services on the same</div><div class=""> tor instance. This is considered a feature, as it prevents hidden services</div><div class=""> from being discovered via rendezvous single onion services on the same tor</div><div class=""> instance.</div><div class=""><br class=""></div><div class="">5.1.2 Recommended Additional Options: Correctness</div><div class=""><br class=""></div><div class=""> Based on the experiences of Tor2Web with one-hop paths, operators should</div><div class=""> consider using the following options with every rendezvous single onion</div><div class=""> service, and every single onion service:</div><div class=""> </div><div class=""> UseEntryGuards 0</div><div class=""> One-hop paths do not use entry guards. This also deactivates the entry</div><div class=""> guard pathbias code, which is not compatible with one-hop paths. Entry</div><div class=""> guards are a security measure against Sybil attacks. Unfortunately,</div><div class=""> they also act as the bottleneck of busy onion services and overload</div><div class=""> those Tor relays.</div><div class=""><br class=""></div><div class=""> LearnCircuitBuildTimeout 0</div><div class=""> Learning circuit build timeouts is incompatible with one-hop paths.</div><div class=""> It also creates additional, unnecessary connections.</div><div class=""><br class=""></div><div class=""> Perhaps these options should be set automatically on (rendezvous) single</div><div class=""> onion services. Tor2Web sets these options automatically:</div><div class=""> UseEntryGuards 0</div><div class=""> LearnCircuitBuildTimeout 0</div><div class=""><br class=""></div><div class="">5.1.3 Recommended Additional Options: Performance</div><div class=""><br class=""></div><div class=""> LongLivedPorts</div><div class=""> The default LongLivedPorts setting creates additional, unnecessary</div><div class=""> connections. This specifies no long-lived ports (the empty list).</div><div class=""><br class=""></div><div class=""> PredictedPortsRelevanceTime 0 seconds</div><div class=""> The default PredictedPortsRelevanceTime setting creates additional,</div><div class=""> unnecessary connections.</div><div class=""><br class=""></div><div class=""> RendPostPeriod 0 seconds</div><div class=""> This option typically hides the startup time of a hidden service by</div><div class=""> randomly posting over a 2 hour period. Since single onion services</div><div class=""> value speed over anonymity, they can post descriptors straight away.</div><div class=""> (Actually, 30 seconds after they bootstrap, for descriptor stability.)</div><div class=""><br class=""></div><div class=""> However, we do not recommend setting the following option to 1, unless bug</div><div class=""> #17359 is resolved so tor onion services can bootstrap without predicted</div><div class=""> circuits.</div><div class=""><br class=""></div><div class=""> __DisablePredictedCircuits 0</div><div class=""> This option disables all predicted circuits. It is equivalent to:</div><div class=""> LearnCircuitBuildTimeout 0</div><div class=""> LongLivedPorts</div><div class=""> PredictedPortsRelevanceTime 0 seconds</div><div class=""> And turning off hidden service server preemptive circuits, which is</div><div class=""> currently unimplemented (#17360)</div><div class=""><br class=""></div><div class="">5.1.3 Recommended Additional Options: Security</div><div class=""><br class=""></div><div class=""> We recommend that no other services are run on a rendezvous single onion</div><div class=""> service tor instance. Since tor runs as a client (and not a relay) by</div><div class=""> default, rendezvous single onion service operators should set:</div><div class=""><br class=""></div><div class=""> SocksPort 0</div><div class=""> Disallow connections from client applications to the tor network</div><div class=""> via this tor instance.</div><div class=""><br class=""></div><div class=""> ClientOnly 1</div><div class=""> Even if the defaults file configures this instance to be a relay,</div><div class=""> never relay any traffic or serve any descriptors.</div><div class=""><br class=""></div><div class="">5.2. Publishing descriptors</div><div class=""><br class=""></div><div class=""> A single onion service must publish descriptors in the same manner as any</div><div class=""> onion service, as defined by rend-spec.</div><div class=""><br class=""></div><div class="">5.3. Authorization</div><div class=""><br class=""></div><div class=""> Client authorization for a rendezvous single onion service is possible via</div><div class=""> the same methods used for double onion services.</div><div class=""><br class=""></div><div class="">6. Related Proposals, Tools, and Features</div><div class=""><br class=""></div><div class="">6.1. Load balancing</div><div class=""><br class=""></div><div class=""> High capacity services can distribute load and implement failover by:</div><div class=""> * running multiple instances that publish to the same onion service</div><div class=""> directories,</div><div class=""> * publishing descriptors containing multiple introduction points</div><div class=""> (OnionBalance),</div><div class=""> * publishing different introduction points to different onion service</div><div class=""> directories (OnionBalance upcoming(?) feature),</div><div class=""> * handing off rendezvous to a different tor instance via control port</div><div class=""> messages (proposal #255),</div><div class=""> or by a combination of these methods.</div><div class=""><br class=""></div><div class="">6.2. Ephemeral single onion services (ADD_ONION)</div><div class=""><br class=""></div><div class=""> The ADD_ONION control port command could be extended to support ephemerally</div><div class=""> configured rendezvous single onion services. Given that</div><div class=""> RendezvousSingleOnionServiceNonAnonymousServer modifies the behaviour of</div><div class=""> all onion services on a tor instance, if it is set, any ephemerally</div><div class=""> configured onion service should become a rendezvous single onion service.</div><div class=""><br class=""></div><div class="">6.3. Proposal 224 ("Next-Generation Hidden Services")</div><div class=""><br class=""></div><div class=""> This proposal is compatible with proposal 224, with onion services</div><div class=""> acting just like a next-generation hidden service, but making one-hop</div><div class=""> paths to the introduction and rendezvous points.</div><div class=""><br class=""></div><div class="">6.4. Proposal 246 ("Merging Hidden Service Directories and Intro Points")</div><div class=""><br class=""></div><div class=""> This proposal is compatible with proposal 246. The onion service will</div><div class=""> publish its descriptor to the introduction points in the same manner as any</div><div class=""> other onion service. Clients will use the merged hidden service directory</div><div class=""> and introduction point just as they do for other onion services.</div><div class=""><br class=""></div><div class="">6.5. Proposal 252 ("Single Onion Services")</div><div class=""><br class=""></div><div class=""> This proposal is compatible with proposal 252. The onion service will</div><div class=""> publish its descriptor to the introduction points in the same manner as any</div><div class=""> other onion service. Clients can then choose to extend to the single onion</div><div class=""> service, or continue with the rendezvous protocol.</div><div class=""><br class=""></div><div class=""> Running a rendezvous single onion service and single onion service allows</div><div class=""> older clients to connect via rendezvous, and newer clients to connenct via</div><div class=""> extend. This is useful for the transition period where not all clients</div><div class=""> support single onion services.</div><div class=""><br class=""></div><div class="">6.5. Proposal 255 ("Hidden Service Load Balancing")</div><div class=""><br class=""></div><div class=""> This proposal is compatible with proposal 255. The onion service will</div><div class=""> perform the rendezvous protocol in the same manner as any other onion</div><div class=""> service. Controllers can then choose to handoff the rendezvous point</div><div class=""> connection to another tor instance, which should also be configured</div><div class=""> as a rendezvous single onion service.</div><div class=""><br class=""></div><div class="">7. Considerations</div><div class=""><br class=""></div><div class="">7.1 Modifying RendezvousSingleOnionServiceNonAnonymousServer at runtime</div><div class=""> </div><div class=""> Implementations should not reuse introduction points or introduction point</div><div class=""> circuits if the value of RendezvousSingleOnionServiceNonAnonymousServer is</div><div class=""> different than it was when the introduction point was selected. This is</div><div class=""> because these circuits will have an undesirable length.</div><div class=""><br class=""></div><div class=""> There is specific code in tor that preserves introduction points on a HUP,</div><div class=""> if RendezvousSingleOnionServiceNonAnonymousServer has changed, all circuits</div><div class=""> should be closed, and all introduction points must be discarded.</div><div class=""><br class=""></div><div class="">7.2 Delaying connection expiry</div><div class=""><br class=""></div><div class=""> Tor clients typically expire connections much faster than tor relays</div><div class=""> [citation needed].</div><div class=""><br class=""></div><div class=""> (Rendezvous) single onion service operators may find that keeping</div><div class=""> connections open saves on connection latency. However, it may also place an</div><div class=""> additional load on the service. (This could be implemented by increasing the</div><div class=""> configured connection expiry time.)</div><div class=""><br class=""></div><div class="">7.3. (No) Benefit to also running a Tor relay</div><div class=""><br class=""></div><div class=""> In tor Trac ticket #8742, running a relay and hidden onion service on the</div><div class=""> same tor instance was disabled for security reasons. While there may be</div><div class=""> benefits to running a relay on the same instance as a rendezvous single</div><div class=""> onion service (existing connections mean lower latency, it helps the tor</div><div class=""> network overall), a security analysis of this configuration has not yet</div><div class=""> been performed. In addition, a potential drawback is overloading a busy</div><div class=""> single onion service.</div><div class=""><br class=""></div><div class="">6.4 Predicted circuits</div><div class=""><br class=""></div><div class=""> We should look whether we can optimize further the predicted circuits that</div><div class=""> Tor makes as a onion service for this mode.</div><div class=""><br class=""></div><div class="">8. Security Implications</div><div class=""><br class=""></div><div class="">8.1 Splitting the Anonymity Set</div><div class=""><br class=""></div><div class=""> Each additional flavour of onion service, and each additional externally</div><div class=""> visible onion service feature, provides oportunities for fingerprinting.</div><div class=""><br class=""></div><div class=""> Also, each additional type of onion service shrinks the anonymity set for</div><div class=""> users of double onion (hidden) services who require server location</div><div class=""> anonymity. These users benefit from the cover provided by current users of</div><div class=""> onion services, who use them for client anonymity, self-authentication,</div><div class=""> NAT-punching, or other benefits.</div><div class=""><br class=""></div><div class=""> For this reason, features that shrink the double onion service anonymity</div><div class=""> set should be carefully considered. The benefits and drawbacks of</div><div class=""> additional features also often depend on a particular threat model.</div><div class=""><br class=""></div><div class=""> It may be that a significant number of users and sites adopt (rendezvous)</div><div class=""> single onion services due to their benefits. This could increase the</div><div class=""> traffic on the tor network, therefore increasing anonymity overall.</div><div class=""> However, the unique behaviour of each type of onion service may still be</div><div class=""> distinguishable from both the client and server ends of the connection.</div><div class=""><br class=""></div><div class="">8.2 Hidden Service Designs can potentially be more secure</div><div class=""><br class=""></div><div class=""> As a side-effect, by optimizing for performance in this feature, it</div><div class=""> allows us to lean more heavily towards security decisions for</div><div class=""> regular onion services.</div><div class=""><br class=""></div><div class="">8.3 One-hop onion service paths may encourage more attacks</div><div class=""><br class=""></div><div class=""> There's a possible second-order effect here since both encrypted</div><div class=""> services and hidden services will have foo.onion addresses and it's</div><div class=""> not clear based on the address whether the service will be hidden --</div><div class=""> if *some* .onion addresses are easy to track down, are we encouraging</div><div class=""> adversaries to attack all rendezvous points just in case?</div><div class=""><br class=""></div><div class="">9. Further Work</div><div class=""><br class=""></div><div class="">Further proposals or research could attempt to mitigate the anonymity-set</div><div class="">splitting described in section 8. Here are some initial ideas.</div><div class=""><br class=""></div><div class="">9.1 Making Client Exit connections look like Client Onion Service Connections</div><div class=""><br class=""></div><div class=""> A mitigation to this fingerprinting is to make each (or some) exit</div><div class=""> connections look like onion service connections. This provides cover for</div><div class=""> particular types of onion service connections. Unfortunately, it is not</div><div class=""> possible to make onion service connections look like exit connections,</div><div class=""> as there are no suitable dummy servers to exit to on the Internet.</div><div class=""><br class=""></div><div class="">9.1.1 Making Client Exit connections perform Descriptor Downloads</div><div class=""><br class=""></div><div class=""> (Some) exit connections could perform a dummy descriptor download.</div><div class=""> (However, descriptors for recently accessed onion services are cached, so</div><div class=""> dummy downloads should only be performed occasionally.)</div><div class=""><br class=""></div><div class=""> Exit connections already involve a four-hop "circuit" to the server</div><div class=""> (including the connection between the exit and the server on the Internet).</div><div class=""> The server on the Internet is not included in the consensus. Therefore,</div><div class=""> this mitigation would effectively cover single onion services which are not</div><div class=""> relays.</div><div class=""><br class=""></div><div class="">9.1.2 Making Client Exit connections perform the Rendezvous Protocol</div><div class=""><br class=""></div><div class=""> (Some) exit connections could perform a dummy rendezvous protocol.</div><div class=""><br class=""></div><div class=""> Exit connections already involve a four-hop "circuit" to the server</div><div class=""> (including the connection between the exit and the server on the Internet).</div><div class=""> Therefore, this mitigation would effectively cover rendezvous single onion</div><div class=""> services, as long as a dummy descriptor download was also performed</div><div class=""> occasionally.</div><div class=""><br class=""></div><div class="">9.1.3 Making Single Onion Service rendezvous points perform name resolution</div><div class=""><br class=""></div><div class=""> Currently, Exits perform DNS name resolution, and changing this behaviour</div><div class=""> would cause unacceptable connection latency. Therefore, we could make</div><div class=""> onion service connections look like exit connections by making the</div><div class=""> rendezvous point do name resolution (that is, descriptor fetching), and, if</div><div class=""> needed, the introduction part of the protocol. This could potentially</div><div class=""> *reduce* the latency of single onion service connections, depending on the</div><div class=""> length of the paths used by the rendezvous point.</div><div class=""><br class=""></div><div class=""> However, this change makes rendezvous points almost as powerful as Exits,</div><div class=""> a careful security analysis will need to be performed before this is</div><div class=""> implemented.</div><div class=""><br class=""></div><div class=""> There is also a design issue with rendezvous name resolution: a client</div><div class=""> wants to leave resolution (descriptor download) to the RP, but it doesn't</div><div class=""> know whether it can use the exit-like protocol with an RP until it has</div><div class=""> downloaded the descriptor. This might mean that single onion services of</div><div class=""> both flavours need a different address style or address namespace. We could</div><div class=""> use .single.onion or something. (This would require an update to the HSDir</div><div class=""> code.)</div><div class=""><br class=""></div><div class="">9.2 Performing automated and common queries over onion services</div><div class=""><br class=""></div><div class=""> Tor could create cover traffic for a flavour of onion service by performing</div><div class=""> automated or common queries via an onion service of that type. In addition,</div><div class=""> onion service-based checks have security benefits over DNS-based checks.</div><div class=""> See Genuine Onion, Syverson and Boyce, 2015, at</div><div class=""> <a href="http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexible-and-cheap-website-authentication" class="">http://www.nrl.navy.mil/itd/chacs/syverson-genuine-onion-simple-fast-flexible-and-cheap-website-authentication</a></div><div class=""><br class=""></div><div class=""> Here are some examples of automated queries that could be performed over</div><div class=""> an onion service:</div><div class=""><br class=""></div><div class="">9.2.1 torcheck over onion service</div><div class=""><br class=""></div><div class=""> torcheck ("Congratulations! This browser is configured to use Tor.") could</div><div class=""> be retrieved from an onion service.</div><div class=""><br class=""></div><div class=""> Incidentally, this would resolve the exitmap issues in #17297, but it</div><div class=""> would also fail to check that exit connections work, which is important for</div><div class=""> many Tor Browser users.</div><div class=""><br class=""></div><div class="">9.2.2 Tor Browser version checks over onion service</div><div class=""><br class=""></div><div class=""> Running tor browser version checks over an onion service seems to be an</div><div class=""> excellent use-case for onion services. It would also have the Tor Project</div><div class=""> "eating its own dogfood", that is, using onion services for its essential</div><div class=""> services.</div><div class=""><br class=""></div><div class="">9.2.3 Tor Browser downloads over onion service</div><div class=""><br class=""></div><div class=""> Running tor browser downloads over an onion service might require some work</div><div class=""> on the onion service codebase to support high loads, load-balancing, and</div><div class=""> failover. It is a good use case for a (rendezvous) single onion service,</div><div class=""> as the traffic over the tor network is only slightly higher than for</div><div class=""> Tor Browser downloads over tor. (4 hops for [R]SOS, 3 hops for Exit.)</div><div class=""><br class=""></div><div class="">9.2.4 SSL Observatory submissions over onion service</div><div class=""><br class=""></div><div class=""> HTTPS certificates could be submitted to HTTPS Everywhere's SSL Observatory</div><div class=""> over an onion service.</div><div class=""><br class=""></div><div class=""> This option is disabled in Tor Browser by default. Perhaps some users would</div><div class=""> be more comfortable enabling submission over an onion service, due to the</div><div class=""> additional security benefits.</div></div><div class="">-----</div><div class=""><div apple-content-edited="true" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></body></html>