[tor-dev] Proposal: Single onion services
David Goulet
dgoulet at ev0ke.net
Fri Sep 4 15:19:40 UTC 2015
Hi John!
This wonderful proposal has been given number 252 and now pushed in
torspec as a Draft!
--> 252-single-onion.txt
Thanks!
David
On 03 Sep (14:20:56), John Brooks wrote:
> Here’s a delayed shipment from the hidden services hackfest:
>
> Single onion services are a modified form of onion services, which
> trade
> service-side location privacy for improved performance, reliability,
> and
> scalability.
>
> Single onion services have a .onion address identical to any other
> onion
> service. The descriptor contains information sufficient to do a relay
> extend of a circuit to the onion service and to open a stream for the
> onion address. The introduction point and rendezvous protocols are
> bypassed for these services.
>
> The full proposal by Paul, Roger, and myself is below, and available
> from:
>
> https://gitweb.torproject.org/user/special/torspec.git/plain/proposals/ideas/single-onion.txt?h=single-onion
>
> Thanks especially to Paul, who is behind this whole concept, and all of
> the other participants of the Arlington Accords.
>
> - special
>
> -----
>
> Filename: xxx-single-onion.txt
> Title: Single Onion Services
> Author: John Brooks, Paul Syverson, Roger Dingledine
> Created: 2015-07-13
> Status: Draft
>
> 1. Overview
>
> Single onion services are a modified form of onion services, which
> trade
> service-side location privacy for improved performance, reliability,
> and
> scalability.
>
> Single onion services have a .onion address identical to any other
> onion
> service. The descriptor contains information sufficient to do a relay
> extend of a circuit to the onion service and to open a stream for the
> onion
> address. The introduction point and rendezvous protocols are bypassed
> for
> these services.
>
> We also specify behavior for a tor instance to publish a single onion
> service, which requires a reachable OR port, without necessarily
> acting
> as a public relay in the network.
>
> 2. Motivation
>
> Single onion services have a few benefits over double onion services:
>
> * Connection latency is much lower by skipping rendezvous
> * Stream latency is reduced on a 4-hop circuit
> * Removing rendezvous circuits improves service scalability
> * A single onion service can use multiple relays for load
> balancing
>
> Single onion services are not location hidden on the service side,
> but clients retain all of the benefits and privacy of onion
> services. More details, relation to double onion services, and the
> rationale for the 'single' and 'double' nomenclature are further
> described in section 7.4.
>
> We believe these improvements, along with the other benefits of onion
> services, will be a significant incentive for website and other
> internet
> service operators to provide these portals to preserve the privacy of
> their
> users.
>
> 3. Onion descriptors
>
> The onion descriptor format is extended to add:
>
> "service-extend-locations" NL encrypted-string
> [At most once]
>
> A list of relay extend info, which is used instead of
> introduction
> points and rendezvous for single onion services. This field is
> encoded and optionally encrypted in the same way as the
> "introduction-points" field.
>
> The encoded contents of this field contains no more than 10
> entries,
> each containing the following data:
>
> "service-extend-location" SP link-specifiers NL
> [At start, exactly once]
> link-specifiers is a base64 encoded link specifier block, in
> the format described by proposal 224 [BUILDING-BLOCKS] and
> the
> EXTEND2 cell.
>
> "onion-key" SP key-type NL onion-key
> [Exactly once]
> Describes the onion key that must be used when extending to
> the
> single onion service relay.
>
> The key-type field is one of:
> "tap"
> onion-key is a PEM-encoded RSA relay onion key
> "ntor"
> onion-key is a base64-encoded NTOR relay onion key
>
> [XXX: Should there be some kind of cookie to prove that we have the
> desc?
> See also section 7.1. -special]
>
> A descriptor may contain either or both of "introduction-points" and
> "service-extend-locations"; see section 5.2.
>
> [XXX: What kind of backwards compatibility issues exist here? Will
> existing
> relays accept one of those descriptors? -special]
>
> 4. Reaching a single onion service as a client
>
> Single onion services use normal onion hostnames, so the client will
> first request the service's descriptor. If the descriptor contains a
> "service-extend-locations" field, the client should ignore the
> introduction
> points and rendezvous process in favor of the process defined here.
>
> The descriptor's "service-extend-locations" information is sufficient
> for a
> client to extend a circuit to the onion service, regardless of
> whether it is
> also listed as a relay in the network consensus. This extend info
> must not
> be used for any other purpose. If multiple extend locations are
> specified,
> the client should randomly select one.
>
> The client uses a 3-hop circuit to extend to the service location
> from the
> descriptor. Once this circuit is built, the client sends a BEGIN cell
> to
> the relay, with the onion address as hostname and the desired TCP
> port.
>
> If the circuit or stream fails, the client should retry using another
> extend location from the descriptor. If all extend locations fail,
> and the
> descriptor contains an "introduction-points" field, the client may
> fall back
> to a full rendezvous operation.
>
> 5. Publishing a single onion service
>
> To act as a single onion service, a tor instance (or cooperating
> group of
> tor instances) must:
>
> * Have a publicly accessible OR port
> * Publish onion descriptors in the same manner as any onion
> service
> * Include a "service-extend-locations" section in the onion
> descriptor
> * Accept RELAY_BEGIN cells for the service as defined in section
> 5.3
>
> 5.1. Configuration options
>
> The tor server operating a single onion service must accept
> connections as
> a tor relay, but is not required to be published in the consensus or
> to
> allow extending circuits. To enable this, we propose the following
> configuration option:
>
> RelayAllowExtend 0|1
> If set, allow clients to extend circuits from this relay.
> Otherwise,
> refuse all extend cells. PublishServerDescriptor must also be
> disabled
> if this option is disabled. If ExitRelay is also disabled, this
> relay
> will not pass through any traffic.
>
> 5.2. Publishing descriptors
>
> A single onion service must publish descriptors in the same manner as
> any
> onion service, as defined by rend-spec and section 3 of this
> proposal.
>
> Optionally, a set of introduction points may be included in the
> descriptor
> to provide backwards compatibility with clients that don't support
> single
> onion services, or to provide a fallback when the extend locations
> fail.
>
> 5.3. RELAY_BEGIN
>
> When a RELAY_BEGIN cell is received with a configured single onion
> hostname
> as the destination, the stream should be connected to the configured
> backend
> server in the same manner as a service-side rendezvous stream.
>
> All relays must reject any RELAY_BEGIN cell with an address ending in
> ".onion" that does not match a locally configured single onion
> service.
>
> 6. Other considerations
>
> 6.1. Load balancing
>
> High capacity services can distribute load by including multiple
> entries
> in the "service-extend-locations" section of the descriptor, or by
> publishing several descriptors to different onion service
> directories, or
> by a combination of these methods.
>
> 6.2. Benefits of also running a Tor relay
>
> If a single onion service also acts as a published tor relay, it will
> keep
> connections to many other tor relays. This can significantly reduce
> the
> latency of connections to the single onion service, and also helps
> the tor
> network.
>
> 6.3. Proposal 224 ("Next-Generation Hidden Services")
>
> This proposal is compatible with proposal 224, with small changes to
> the
> service descriptor format. In particular:
>
> The "service-extend-location" sections are included in the encrypted
> portion
> of the descriptor, adjacent to any "introduction-point" sections. The
> "service-extend-locations" field is no longer present. An onion
> service is
> also single onion service if any "service-extend-location" field is
> present.
>
> 6.4. Proposal 246 ("Merging Hidden Service Directories and Intro
> Points")
>
> This proposal is compatible with proposal 246. The onion service will
> publish its descriptor to the introduction points in the same manner
> as any
> other onion service. The client may choose to build a circuit to the
> specified relays, or to continue with the rendezvous protocol.
>
> The client should not extend from the introduction point to the
> single onion
> service's relay, to avoid overloading the introduction point. The
> client
> may truncate the circuit and extend through a new relay.
>
> 7. Discussion
>
> 7.1. Authorization
>
> Client authorization for a single onion service is possible through
> encryption of the service-extend-locations section in the descriptor,
> or
> "stealth" publication under a new onion address, as with traditional
> onion services.
>
> One problem with this is that if you suspect a relay is also serving
> a
> single onion service, you can connect to it and send RELAY_BEGIN
> without
> any further authorization. To prevent this, we would need to include
> a
> cookie from the descriptor in the RELAY_BEGIN information.
>
> 7.2. Preventing relays from being unintentionally published
>
> Many single onion servers will not want to relay other traffic, and
> will
> set 'PublishServerDescriptor 0' to prevent it. Even when they do,
> they will
> still generate a relay descriptor, which could be downloaded and
> published
> to a directory authority without the relay's consent. To prevent
> this, we
> should insert a field in the relay descriptor when
> PublishServerDescriptor
> is disabled that instructs relays to never include it as part of a
> consensus.
>
> [XXX: Also see task #16564]
>
> 7.3. Ephemeral single onion services (ADD_ONION)
>
> The ADD_ONION control port command could be extended to support
> ephemerally
> configured single onion services. We encourage this, but specifying
> its
> behavior is out of the scope of this proposal.
>
> 7.4. Onion service taxonomy and nomenclature
>
> Onion services in general provide several benefits. First, by
> requiring a connection via Tor they provide the client the
> protections of Tor and make it much more difficult to inadvertently
> bypass those protections than when connecting to a non .onion site.
> Second, because .onion addresses are self-authenticating, onion
> services have look-up, routing, and authentication protections not
> provided by sites with standard domain addresses. These benefits
> apply to all onion services.
>
> Onion services as originally introduced also provide network
> location hiding of the service itself: because the client only ever
> connects through the end of a Tor circuit created by the onion
> service, the IP address of the onion service also remains
> protected.
>
> Applications and services already exist that use existing onion
> service protocols for the above described general benefits without
> the need for network location hiding. This Proposal is
> accordingly motivated by a desire to provide the general benefits,
> without the complexity and overhead of also protecting the location
> of the service.
>
> Further, as with what had originally been called 'location hidden
> services', there may be useful and valid applications of this
> design that are not reflected in our current intent. Just as
> 'location hidden service' is a misleading name for many current
> onion service applications, we prefer a name that is descriptive of
> the system but flexible with respect to applications of it. We also
> prefer a nomenclature that consistently works for the different
> types of onion services.
>
> It is also important to have short, simple names lest usage
> efficiencies evolve easier names for us. For example, 'hidden
> service' has replaced the original 'location hidden service' in Tor
> Proposals and other writings.
>
> For these reasons, we have chosen 'onion services' to refer to both
> those as set out in this Proposal and those with the client-side
> and server-side protections of the original---also for referring
> indiscriminately to any and all onion services. We use
> 'double-onion service' to refer to services that join two Tor
> circuits, one from the server and one from the client. We use
> 'single-onion' when referring to services that use only a
> client-side Tor circuit. In speech we sometimes use the even
> briefer, 'two-nion' and 'one-ion' respectively.
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150904/2e71fa91/attachment.sig>
More information about the tor-dev
mailing list