- tor-dev - lists.torproject.org

Proposal: Out of Band Circuit HMACs
by Mike Perry 08 Sep '15

08 Sep '15

This proposal exists in my torspec remote here: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx… Including it in-line for ease of reply: =============================== Filename: xxx-oob-hmac.txt Title: Out of Band Circuit HMACs Authors: Mike Perry Created: 01 September 2015 Status: Draft 0. Motivation It is currently possible for Guard nodes (and MITM adversaries that steal their identity keys) to perform a "tagging" attack to influence circuit construction and resulting relay usage[1]. Because Tor uses AES as a stream cipher, malicious or intercepted Guard nodes can simply XOR a unique identifier into the circuit cipherstream during circuit setup and usage. If this identifier is not removed by a colluding exit (either by performing another XOR, or making use of known plaintext regions of a cell to directly extract a complete side-channel value), then the circuit will fail. In this way, malicious or intercepted Guard nodes can ensure that all client traffic is directed only to colluding exit nodes, who can observe the destinations and deanonymize users. Most code paths in the Tor relay source code will emit loud warnings for the most obvious instances circuit failure caused by this attack. However, it is very difficult to ensure that all such error conditions are properly covered such that warnings will be emitted. This proposal aims to provide a mechanism to ensure that tagging and related malleability attacks are cryptographically detectable when they happen. 1. Overview Since Tor Relays are already storing a running hash of all data transmitted on their circuits (via the or_circuit_t::n_digest and or_circuit_t::p_digest properties), it is possible to compute an out-of-band HMAC on circuit data, and verify that it is as expected. This proposal first defines an OOB_HMAC primitive that can be included standalone in a new relay cell command type, and additionally in other cell types. Use of the standalone relay cell command serves to ensure that circuits that are successfully built and used were not manipulated at a previous point. By altering the RELAY_COMMAND_TRUNCATED and CELL_DESTROY cells to also include the OOB_HMAC information, it is similarly possible to detect alteration of circuit contents that cause failures before the point of usage. 2. The OOB_HMAC primitive The OOB_HMAC primitive uses the existing rolling hashes present in or_circuit_t to provide a Tor OP (aka client) with the hash history of the traffic that a given relay has seen it so far. Note that to avoid storing an additional 64 bytes of SHA256 digest for every circuit at every relay, we use SHA1 for the hash logs, since the circuits are already storing SHA1 hashes. It's not immediately clear how to upgrade the existing SHA1 digests to SHA256 with the current circuit protocol, either, since matching hash algorithms are essential to the 'recognized' relay cell forwarding behavior. The version field exists primarily for this reason, should the rolling circuit hashes ever upgrade to SHA256. The OOB_HMAC primitive is specified in Trunnel as follows: struct oob_hmac_body { /* Version of this section. Must be 1 */ u8 version; /* SHA1 hash of all client-originating data on this circuit (obtained from or_circuit_t::n_digest). */ u8 client_hash_log[20]; /* Number of cells processed in this hash, mod 2^32. Used to spot-check hash position */ u32 client_cell_count; /* SHA1 hash of all server-originating data on this circuit (obtained from or_circuit_t::p_digest). */ u8 server_hash_log[20]; /* Number of cells processed in this hash, mod 2^32. Used to spot-check hash position. XXX: Technically the server-side is not needed. */ u32 server_cell_count; /* HMAC-SHA-256 of the entire cell contents up to this point, using or_circuit_t::p_crypto as the hmac key. XXX: Should we use a KDF here instead of p_crypto directly? */ u8 cell_hmac_256[32]; }; 3. Usage of OOB_HMAC The OOB_HMAC body will be included in three places: 1. In a new relay cell command RELAY_COMMAND_HMAC_SEND, which is sent in response to a client-originating RELAY_COMMAND_HMAC_GET on stream 0. 2. In CELL_DESTROY, immediately after the error code 3. In RELAY_COMMAND_TRUNCATED, immediately after the CELL_DESTROY contents 3.1. RELAY_COMMAND_HMAC_GET/SEND relay commands Clients should use leaky-pipe topology to send RELAY_COMMAND_HMAC_GET to the second-to-last node (typically the middle node) in the circuit at three points during circuit construction and usage: 1. Immediately after the last RELAY_EARLY cell is sent 2. Upon any stream detachment, timeout, or failure. 3. Upon any OP-initiated circuit teardown (including timed-out partially built circuits). We use RELAY_EARLY as the point at which to send these cells to avoid leaking the path length to the middle hop. 3.2. Alteration of CELL_DESTROY and RELAY_COMMAND_TRUNCATED In order to provide an HMAC even when a circuit is torn down before use due to failure, the behavior for generating and handling CELL_DESTROY and RELAY_COMMAND_TRUNCATED should be modified as follows: Whenever an OR sends a CELL_DESTROY for a circuit towards the OP, if that circuit was already properly established, the OR should include the contents of oob_hmac_body immediately after the reason field. The HMAC must cover the error code from CELL_DESTROY. Upon receipt of a CELL_DESTROY, and in any other case where an OR would generate a RELAY_COMMAND_TRUNCATED due to error, a conformant relay would include the CELL_DESTROY oob_hmac_body, as well as its own locally created oob_hmac_body. The locally created oob_hmac_body must cover the entire payload contents of RELAY_COMMAND_TRUNCATED, including the error code and the CELL_DESTROY oob_hmac_body. Here is a new Trunnel specification for RELAY_COMMAND_TRUNCATED: struct relay_command_truncated { /* Error code */ u8 error_code; /* Number of oob_hmacs. Must be 0, 1, or 2 */ u8 num_hmac; /* If there are 2 hmacs, the first one is from the CELL_DESTROY, and the second one is from the truncating relay. If num_hmac is 0, then this came from a relay without support for oob_hmac. */ struct oob_hmac_body[num_hmac]; }; The usage of a strong HMAC to cover the entire CELL_DESTROY contents also allows an OP to properly authenticate the reason a remote node needed to close a circuit, without relying on the previous hop to be honest about it. 4. Ensuring proper ordering with respect to hashes 4.1. RELAY_COMMAND_HMAC_GET/SEND The in-order delivery guarantee of circuits will mean that the incoming hashes will match upon receipt of the RELAY_COMMAND_HMAC_SEND cell, but any outgoing traffic the OP sent since RELAY_COMMAND_HMAC_GET will not have been seen by the responding OR. Therefore, immediately upon sending a RELAY_COMMAND_HMAC_GET, the OP must record and store its current outgoing hash state for that circuit, until the RELAY_COMMAND_HMAC_SEND arrives, and use that stored hash value for comparison against the oob_hmac_body's client_hash_log field. The server_hash_log should be checked against the corresponding crypt_path_t entry in origin_circuit_t for the relay that the command was sent to. 4.2. RELAY_COMMAND_TRUNCATED Since RELAY_COMMAND_TRUNCATED may be sent in response to any error condition generated by a cell in either direction, the OP must check that its local cell counts match those present in the oob_hmac_body for that hop. If the counts do not match, the OP may generate a RELAY_COMMAND_HMAC_GET to the hop that sent RELAY_COMMAND_TRUNCATED, prior to tearing down the circuit. 4.3. CELL_DESTROY If the cell counts of the destroy cell's oob_hmac_body do not match what the client sent for that hop, unfortunately that hash must be discarded. Otherwise, it may be checked against values held from before processing the RELAY_COMMAND_TRUNCATED envelope. 5. Security concerns and mitigations 5.1. Silent circuit failure attacks The primary way to game this oob-hmac is to omit or block cells containing HMACs from reaching the OP, or otherwise tear down circuits before responses arrive with proof of tampering. If a large fraction of circuits somehow fail without any RELAY_COMMAND_TRUNCATED oob_hmac_body payloads present, and without any responses to RELAY_COMMAND_HMAC_GET requests, the user should be alerted of this fact as well. This rate of silent circuit failure should be kept as an additional, separate per-Guard Path Bias statistic, and the user should be warned if this failure rate exceeds some (low) threshold for circuits containing relays that should have supported this proposal. 5.2. Malicious/colluding middle nodes If the adversary is prevented from causing silent circuit failure without the client being able to notice and react, their next available vector is to ensure that circuits are only built to middle nodes that are malicious and colluding with them (or that do not support this proposal), so that they may lie about the proper hash values that they see (or omit them). Right now, the current path bias code also does not count circuit failures to the middle hop as circuit attempts. This was done to reduce the effect of ambient circuit failure on the path bias accounting (since an average ambient circuit failure of X per-hop causes the total circuit failure middle+exit circuits to be 2X). Unfortunately, not counting middle hop failure allows the adversary to only allow circuits to colluding middle hops to complete, so that they may lie about their hash logs. All failed circuits to non-colluding middle nodes could be torn down before RELAY_COMMAND_TRUNCATED is sent. For this reason, the per-Guard Path Bias counts should be augmented to additionally track middle-node-only failure as a separate statistic as well, and the user should be warned if middle-node failure drops below a similar threshold as the current end-to-end failure. 5.3. Side channel issues, mitigations, and limitations Unfortunately, leaking information about circuit usage to the middle node prevents us from sending RELAY_COMMAND_HMAC_GET cells at more optimal points in circuit usage (such as immediately upon open, immediately after stream usage, etc). As such, we are limited to waiting until RELAY_EARLY cells stop being sent. It is debatable if we should send hashes periodically (perhaps with windowing information updates?) instead. 6. Alternatives A handful of alternatives to this proposal have already been discussed, but have been dismissed for various reasons. Per-hop cell HMACs were ruled out because they will leak the total path length, as well as the current hop's position in the circuit. Wide-block ciphers have been discussed, which would provide the property that attempts to alter a cell at a previous hop would render it completely corrupted upon its final destination, thus preventing untagging and recovery, even by a colluding malicious peer. Unfortunately, performance analysis of modern provably secure versions of wide-block ciphers has shown them to be at least 10X slower than AES-NI[2]. 1. https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html 2. http://archives.seul.org/tor/dev/Mar-2015/msg00137.html -- Mike Perry

1 0

[Measurement Team] Next IRC meeting happens on Wednesday, Sep 9, 14:00 UTC in #tor-project
by Karsten Loesing 08 Sep '15

08 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, September 9, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150909T14 Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV7zD0AAoJEJD5dJfVqbCrNlAIAIHDOy3J3Rw7Tg8zbIECZMdU bLwUE31jnsIE54fPBv2+lofWq0FlciMNR/UGmuCDCvgKy1tzLAReWvZzZc4kB3hg sUMOYqB757/4IBFuh/6YWqrC7jOEuVEhky7/J/1obHj1pSzWY/Tt+whhC4Sfl4h5 WRHAUQUYPVIDaa8FjYiHCnHcTCLDiuu+FoODCD6LjtBX1dQYABkbUVm8Vo1vH/u+ UimxN+EhrJc/u5WA3Eb4YDURhikzUkdMM680gyZXrCip7klvX4fGlojBZHur6VkS p3LSSWfZ7o+mPBqyord7CPs+1o66sQLZdG6tzeOm3nQugqE2DgF9fNlnBkBt1D4= =sCDs -----END PGP SIGNATURE-----

1 0

Is there a way to do the man in the middle on hidden service?
by Liste 08 Sep '15

08 Sep '15

Sometime i can find the wrong SSL certificate on my hidden service.

1 0

Re: [tor-dev] Let's identify which measurement-related tools n eedwork when relays switch from RSA identities to ed25519 identities
by tordev123＠Safe-mail.net 08 Sep '15

08 Sep '15

From: Damian Johnson <atagar(a)torproject.org> To: "tor-dev(a)lists.torproject.org" <tor-dev(a)lists.torproject.org> Subject: Re: [tor-dev] Let's identify which measurement-related tools needwork when relays switch from RSA identities to ed25519 identities Date: Tue, 8 Sep 2015 09:16:15 -0700 > On a side note it would be nice to have a spec patch before changing > things this time. +1 The dir spec is still broken and doesn't cover the new descriptor format with stuff like: extra-info-digest 0589E8C4C8A522814EE8D7DC1A3703920B57208C Qychl+FIG6YEbXgGJaG13mMHW9z9Tci5D9DWCXOwmNg dir-spec: "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) [Versions before 0.2.0.1-alpha don't recognize this]

1 0

Let's identify which measurement-related tools need work when relays switch from RSA identities to ed25519 identities
by Karsten Loesing 08 Sep '15

08 Sep '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, Sebastian suggested to me in one of our last measurement team 1-1-1 task exchange rounds [0] to think about the following question: Which measurement-related tools need work when relays switch from RSA identities to ed25519 identities? You'll find below what I came up with. Please send any feedback and corrections to this list. I'll incorporate everything and send an updated document to this list next week. Thanks! All the best, Karsten The switch from RSA to ed25519 will happen in multiple steps (need to confirm these!): 0. Before ed25519 identities were used, each relay had a unique RSA identity. 1. Relays can create an optional ed25519 identity, change it, or stop using it at will. 2. Relays can create an ed25519 identity, but are not allowed to change it or stop using it. 3. Relays can stop using their earlier RSA identity. 4. Relays only use their ed25519 identity. (Add a notion of timeframe here. It seems unlikely that 3 or even 4 will happen before 2017 or even 2018, given how long it takes to deploy a new major Tor version in the network. Sebastian thinks that the timeline may not contain step 1.) ## Directory authority tools: Torflow, Guardfraction There are several tools that provide data to directory authorities for voting on relays. These tools include bandwidth authorities and the yet-to-be-finished Guardfraction tool. They will have to handle new ed25519 identities and provide their data in a format that directory authorities will be able to use for voting. ## Network health scanners: Exitmap, Sybilhunter It's unclear how much work remains to update network scanners like Exitmap and Syilbhunter. ## Descriptor parsing libraries: metrics-lib, Stem, Zoossh Descriptor parsing libraries need to support parsing new fields and later need to support that fields containing RSA fingerprints have become optional. Stem has already implemented ed25519 identities, and there's Java code that metrics-lib could re-use in CollecTor's bridge descriptor sanitizer. Zoossh is probably not updated yet. ## Descriptor archiver: CollecTor The part of CollecTor that archives relay descriptors relies heavily on RSA identities and SHA-1 digests. This includes its implementation of the Tor directory protocol and its structure for storing fetched descriptors in tarballs. Another part of CollecTor that needs to be updated is the bridge descriptor sanitizer. That is already done to the extent of sanitizing ed25519-related descriptor lines. The part that is not updated yet is the tarball structure that still uses SHA-1 digests. ## Network health checkers: DocTor, DepicTor Network health checkers like DocTor and DepicTor use relay fingerprints, but they focus more on network consensus meta data provided by the directory authorities. Updating to ed25519 identities shouldn't be hard. ## Statistics portal: Metrics Most of the data-aggregating modules behind the Metrics website use RSA identities to ensure uniqueness of reported statistics. Switching to another fingerprint format or length should be doable, but will cause some effort. ## Relay address database: ExoneraTor The relay address database ExoneraTor only uses the RSA identity to ensure uniqueness of database entries and for display purposes. Supporting new identities should not be that difficult. ## Onionoo server and clients: Onionoo, Atlas, Globe, Compass, OnionTip, Roster The Onionoo server heavily depends on RSA fingerprints of relays and hashed RSA fingerprints of bridges, both internally and in its API. Supporting ed25519 identities in addition to RSA fingerprints would not be hard, but stopping to support RSA fingerprints will require rewriting major parts of Onionoo. Onionoo clients use the RSA fingerprint provided by the Onionoo server to uniquely identify relays and bridges. They will have to adapt to changes in Onionoo that would first support ed25519 identities and later stop supporting RSA fingerprints. This shouldn't be difficult. ## OONI It's unclear how much effort is needed to update OONI to support new ed25519 identities. ## Exit address scanners: TorDNSEL, TorBEL, Check TorDNSEL and its planned successor TorBEL include RSA identities in their output format. It might be sufficient to simply add ed25519 identities there and leave out RSA identities once they are not used anymore. Check will have to be updated to understand these new formats. [0] 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV7uf1AAoJEJD5dJfVqbCrBJUH/A78UIeNy5UIvctO6EjMp6KU XXeB7jxDoA9RmdhNV7v5MzhSCjblQLfG5tyLmeFV/opX+xG0fMvqFdUB9jupXccV HQXLjeSuNF4Tenayn3W49EUF/O75BHcfwe0fHzmV8KEIhPf66KQn6gNBFFnWr4S0 OfvoSWbIb9Wu7hCya4C7J69FVAhwXPH8JpgpSpKLFYSZWQo1aKbgVqBDKNe/lmrV UO04Ws/O04osG9WWX/HcZgSCfSaN68nBMllnu0yCTJY+fEqFruxYhAaZZV6tXIfG E66vZc2K3S6Rk/1nwHEkNeZKCfjyRG1LthzH28HdCEMzl1mdQhUPkJawNaQXoDM= =rXAd -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Proposal: Single onion services
by tordev123＠Safe-mail.net 05 Sep '15

05 Sep '15

-------- Original Message -------- From: John Brooks <john.brooks(a)dereferenced.net> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Proposal: Single onion services Date: Fri, 4 Sep 2015 15:31:15 -0600 > tordev123(a)Safe-mail.net wrote: > > > Doesn't your proposal imply that you are turning all relays into > > exit-nodes lite? The last relay in the path will know what service you are > > connecting to (at least if that service is hosted with a unique relay), > > right? > > A single onion service operates its own server(s). These servers accept OR > connections like a relay does, but they aren’t required to be in the > consensus or to relay traffic. They are the servers listed in the > descriptor. Right, that's how I understood things. > A client connects by extending a circuit to the single onion server. This is > not the same as an exit connection: tor relays will extend circuits to > relays they don't know about, as long as the destination speaks the tor > protocol. It’s possible for any tor relay to be used as the last one before > the single onion server. > > If the single onion server isn’t also a tor relay, it’s possible for the > previous relay to guess the service you’re connecting to. That is a large part of my concern. > This isn’t a risk > to client anonymity, because tor clients will always choose the first three > hops in a circuit before extending to one they didn’t choose. I'm not concerned about clients. > The final circuit looks like: > > Client -> Guard -> Middle -> Middle -> Single Onion > > The client’s traffic is encrypted through to the single onion server as > well. IMO, the second Middle relay can be considered serving as an exit with regards to Single Onion services - that's what I meant with 'exit node lite'. There was the case of an Austrian exit node operator getting prosecuted. It will sometimes be possible to attribute traffic relating to specific transactions to the second Middle node in the path (e.g. when the single onion server keeps detailed logs). So the circumstances of that case could apply to a non-exit relay operator as well. Your proposal is shifting non-exit relays towards performing a role that can be considered exit-like, even if that role is much more limited than normal exits (and there is an additional Tor protocol layer involved).

2 1

Proposal: Single onion services
by John Brooks 04 Sep '15

04 Sep '15

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/idea… 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.

2 1

tor-browser git repository
by tordev123＠Safe-mail.net 04 Sep '15

04 Sep '15

Is there some documentation, how the tor-browser git repository is set up? In particular, how are new Firefox releases imported? How can I get a diff of Tor changes to the underlying Firefox release?

3 2

Donncha's SoP Status Report 7 - Final
by Donncha O'Cearbhaill 03 Sep '15

03 Sep '15

Hello all, This is my seventh, and final biweekly status report for my hidden service scaling / load-balancing SoP project. Since my last status report: * I have been revising my patch for #14846 with the aim of getting it merged before the 0.2.7 feature freeze. * I've been working with Ivan Markin on getting smart cards supported for signing in OnionBalance. Thank you Ivan for your code and enthusiasm. Although the Summer of Privacy program is now over, I plan to continue maintaining and developing this project into the future. My immediate objectives are to: * Package OnionBalance in Debian * Clarifying the documentation (installation, use cases, storing master hidden service keys on an isolated machine). * Implementing smartcard / HSM support master service key storage and signing. Work on the Complex Mode is advancing but I am not yet satisfied with the reliability of that mode. I will also further investigate any potential attacks or risks with that mode. Proposals #224 (next-gen hidden services) and #246 (merging hidden service directories and introduction points) are still developing. I'll continue developing OnionBalance so that if possible, it can facilitate some form of load balancing and redundancy with next-gen hidden services. I'd like to thank my mentors David Goulet and George Kadianakis for their invaluable guidance and feedback during the Summer of Privacy. Other members of the Tor community, in particular s7r, have been exceptional helpful with testing OnionBalance and offering feedback from a hidden service operator perspective. Finally I'd like to thank all in the wider Tor community for the welcome and support you have shown me over the past months. I hope that I can continue making contributions to the Tor community into the future. Regards, Donncha

2 1

Re: [tor-dev] Should cloud-hosted relays be rejected?
by tordev123＠Safe-mail.net 02 Sep '15

02 Sep '15

From: Sharif Olorin <sio(a)tesser.org> To: tor-dev <tor-dev(a)lists.torproject.org> Subject: Re: [tor-dev] Should cloud-hosted relays be rejected? Date: Wed, 02 Sep 2015 08:32:58 +0000 > > I'm not talking about those providers hosting exit nodes. I'm talking about general web sites and resources hosted by them and the traffic that goes there. > > I'm confused. You're worried about people hosting clearnet websites > with cloud hosting providers? Or non-exit relays? Correlation between all kinds of relay traffic and clearnet traffic. Entry traffic would be the worst, allowing end-to-end correlation.

2 1

Re: [tor-dev] Should cloud-hosted relays be rejected?
by tordev123＠Safe-mail.net 02 Sep '15

02 Sep '15

From: nusenu <nusenu(a)openmailbox.org> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Should cloud-hosted relays be rejected? Date: Tue, 1 Sep 2015 19:23:35 +0200 > > It has other benefits. Those big providers see a huge amount of exit > > traffic and can potentially do correlation against that. > > I disagree on 'huge'. > If you worry about i.e. Amazon hosting to much exit bandwidth you have > to worry about many other* ASes first, and even then, banning them all > completely (exit prob = 0) isn't probably a wise strategy. I'm not talking about those providers hosting exit nodes. I'm talking about general web sites and resources hosted by them and the traffic that goes there.

2 1

Re: [tor-dev] Should cloud-hosted relays be rejected?
by tordev123＠Safe-mail.net 01 Sep '15

01 Sep '15

From: nusenu <nusenu(a)openmailbox.org> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Should cloud-hosted relays be rejected? Date: Tue, 1 Sep 2015 00:58:05 +0200 > I don't think banning GCE, AWS and MS Azure is an efficient method to > significantly increase the cost of attacks because it is trivial for an > attacker to quickly spin up "a large number of disposable machines" at > other ISPs as well. It has other benefits. Those big providers see a huge amount of exit traffic and can potentially do correlation against that.

3 2

Should cloud-hosted relays be rejected?
by Philipp Winter 01 Sep '15

01 Sep '15

We sometimes see attacks from relays that are hosted on cloud platforms. I have been wondering if the benefit of having cloud-hosted relays outweighs the abuse we see from them. To get an idea of the benefit, I analysed the bandwidth that is contributed by cloud-hosted relays. I first obtained the network blocks owned by three cloud providers (Amazon AWS, Google Cloud, Microsoft Azure), and determined the percent of bandwidth they contributed in July 2015. The results show that there were typically ~200 cloud-hosted relays online: <https://nymity.ch/sybilhunting/png/cloud-hosted_relays_2015-07.png> The spike shortly after hour 200 was caused by a lot of Amazon relays named "DenkoNet". The spike at the very beginning was caused by a number of relays that might very well belong together, too, based on their uptime pattern. What counts, however, is bandwidth. Here's the total bandwidth fraction contributed by cloud-hosted relays over July 2015: <https://nymity.ch/sybilhunting/png/cloud-hosted_bandwidth_2015-07.png> There were no Google Cloud relays to contribute any bandwidth. Amazon AWS-powered relays contributed the majority of bandwidth, followed by Microsoft Azure-powered relays. Here's a summary of the time series in percent: Min. Mean Median Max. 0.2% 0.8% 0.79% 1.5% In an average consensus in July 2015, cloud-hosted relays contributed only around 0.8% of bandwidth. Note, however, that this is just a lower bound. The netblocks I used for the analysis could have changed, and I didn't consider providers other than Google, Amazon, and Microsoft. There are also cloud-hosted bridges. Tor Cloud, however, has shut down, and the number of EC2 bridges is declining: <https://metrics.torproject.org/cloudbridges.html?graph=cloudbridges&start=2…> The harm caused by cloud-hosted relays is more difficult to quantify. Getting rid of them also wouldn't mean getting rid of any attacks. At best, attackers would have to jump through more hoops. If we were to decide to permanently reject cloud-hosted relays, we would have to obtain the netblocks that are periodically published by all three (and perhaps more) cloud providers: <https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html> <https://msdn.microsoft.com/en-us/library/azure/Dn175718.aspx> <https://cloud.google.com/appengine/kb/general?hl=en#static-ip> Note that this should be done periodically because the netblocks are subject to change. Cheers, Philipp

6 7

Where are the GetTor downloads (e.g. GitHub)?
by David Fifield 01 Sep '15

01 Sep '15

Someone IRL asked me about mirrored downloads of Tor Browser on services like GitHub. I know that such services are planned (or already implemented?) for GetTor, and I know about these tickets: Integrate cloud services that are not blocked in mainland China https://bugs.torproject.org/14114 Automate upload of latest Tor Browser to cloud services https://bugs.torproject.org/14744 Script to upload Tor Browser to Github https://bugs.torproject.org/14835 My question is, is there a static URL on GitHub or similar that has the latest downloads? That is, one that people can access even without having used GetTor? Such a URL would be more useful than a typical mirror for many users. I was referred to Lantern's GitHub download page for comparison: https://github.com/getlantern/lantern/releases/tag/latest It has direct links to downloads under githubusercontent.com: https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lanter… https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lanter… https://raw.githubusercontent.com/getlantern/lantern-binaries/master/lanter…

2 2

New Onionoo version 2.6 adds new "alleged_family" and "indirect_family" fields
by Karsten Loesing 31 Aug '15

31 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Onionoo users, I just merged and deployed Onionoo protocol version 2.6 which adds two new fields related to relay families and marks the current "family" field as deprecated. The idea of adding three fields for relay families is that we want to support different use cases: - Atlas and Globe want to list all relays that a relay has configured as its family ("effective_family" + "alleged_family"). - Atlas and Globe may further want to mark ineffective family relationships in red ("alleged_family") and effective family relationships in blue ("effective_family"). - Roster needs a family definition that includes family members that are either in a direct family relationship with a relay ("effective_family") or that can be reached by following effective family relationships ("indirect_family"). The current "family" field will stay available until Atlas and Globe are updated. If I should also wait for other clients to be updated, please let me know. We shouldn't wait too long, because all those fingerprints increase the size of Onionoo results for everyone. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV5JJAAAoJEJD5dJfVqbCrlw0IAJ3NxbTE00M72EN/DLcJw2FD /KMV2vpyQqi6tharTNGtZmZrm7HMZ/RTRhR5qlkmcKE18UDKxF0sX5ezT6+1R0QV dNmUhYspP5cKcF6nqReMdd26dp4am6I5PSWqEmsMiC5vmxZbvp+B3st/9MNfYExE qTQV8rkzsWIGTGSojxXLAjzjQwy9EBXdLrMrchH+jL0igbWmWLeshDSou/N0te1g B6TBnA2LlRLKhLoAtwjjF1TREZN6Tkk9djQ8zHRjppZzu004I8bqPWiJ36qLDEqi UVmuo5zrJUQxQEQ/n+AkRBoVNblVDY7/xeGh35ENhCzs+Ls75jCQzrkzx+7upPw= =yTnY -----END PGP SIGNATURE-----

2 2

[Measurement Team] Next IRC meeting happens on Wednesday, Sep 2, 14:00 UTC in #tor-project
by Karsten Loesing 31 Aug '15

31 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, September 2, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150902T14 Talk to you on Wednesday! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV5JhmAAoJEJD5dJfVqbCr69YH/3bpRZnJTfeavkfKKQDog8oq J6uqlFyEKpSl4S2uSc6jT/gwDfUfUuEwWMpXrOUrRzrFSCSQQcMQF8Hiu6Mk5+SD JN398wHGp2gTYp+y6xb6z8TzZfNmEEnJTcSAZtctQrB6kaj3jT29abMqIlsjQW9i F91uCJLJVJWrBhYvqvvFhUbdDhn3S8HYCEx0u6B8Gdd8q1p/Swi5IuSvkpStBHZJ diFGUsrj8HE73RKwOSl1gJcdLIGti3fayDhJZVVuTdV5weS4QF/I96XPJxnPwNqR ek2azn2RteYSMX3vhglkp86z7jKFM9V4sgDXU72S8jp0wWaXXYmbgpY4+v3G7EY= =9+9n -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Remove NULL checks for *_free() calls
by tordev123＠Safe-mail.net 31 Aug '15

31 Aug '15

-------- Original Message -------- From: Zack Weinberg <zackw(a)panix.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Remove NULL checks for *_free() calls Date: Mon, 31 Aug 2015 10:29:31 -0400 > > But you did find some places they forgot to assign NULL after free. > > Unfortunately, setting pointers to 0 after free doesn't help avoid > double free bugs in practice. Double frees happen when there are two > different pointers to the same memory block and both holders think > it's their responsibility to deallocate the object. Clearing one > pointer does precisely nothing to the *other* pointer. Double free is relatively harmless, you usually get a nice crash or noticable memory corruption. What zeroing deleted pointers also gives you is protection against some dangling pointer bugs. Those can be very difficult to track down when the dangling pointer usage is only brief after the free and the bug only manifests itself every full moon. Tor itself is small and fast enough to be run with a memory debugger. Someone is hopefully doing that and this is a moot point.

1 0

Remove NULL checks for *_free() calls
by Michael McConville 31 Aug '15

31 Aug '15

free() is specified to be NULL-safe, and I don't know of any implementations that violate this. Tor's *_free() functions conform, although relaycache_free() prints a warning (which I remove in the below diff). I checked every *_free() function for NULL-safety before removing conditions for it. This includes an OpenSSL function or two. This is only a first pass. I got bored, and I wanted to make sure that there's interest in committing this. :) diff --git a/src/common/backtrace.c b/src/common/backtrace.c index a2d5378..0aa8a17 100644 --- a/src/common/backtrace.c +++ b/src/common/backtrace.c @@ -176,8 +176,7 @@ install_bt_handler(void) char **symbols; int depth = backtrace(cb_buf, MAX_DEPTH); symbols = backtrace_symbols(cb_buf, depth); - if (symbols) - free(symbols); + free(symbols); } return rv; diff --git a/src/common/torgzip.c b/src/common/torgzip.c index 4f23407..3158b96 100644 --- a/src/common/torgzip.c +++ b/src/common/torgzip.c @@ -403,9 +403,7 @@ tor_gzip_uncompress(char **out, size_t *out_len, inflateEnd(stream); tor_free(stream); } - if (*out) { - tor_free(*out); - } + tor_free(*out); return -1; } diff --git a/src/common/tortls.c b/src/common/tortls.c index 7447822..23b1dcf 100644 --- a/src/common/tortls.c +++ b/src/common/tortls.c @@ -625,10 +625,8 @@ tor_tls_create_certificate(crypto_pk_t *rsa, goto done; error: - if (x509) { - X509_free(x509); - x509 = NULL; - } + X509_free(x509); + x509 = NULL; done: tls_log_errors(NULL, LOG_WARN, LD_NET, "generating certificate"); if (sign_pkey) @@ -722,8 +720,7 @@ tor_x509_cert_free(tor_x509_cert_t *cert) { if (! cert) return; - if (cert->cert) - X509_free(cert->cert); + X509_free(cert->cert); tor_free(cert->encoded); memwipe(cert, 0x03, sizeof(*cert)); tor_free(cert); @@ -1328,12 +1325,9 @@ tor_tls_context_new(crypto_pk_t *identity, unsigned int key_lifetime, crypto_pk_free(rsa_auth); if (result) tor_tls_context_decref(result); - if (cert) - X509_free(cert); - if (idcert) - X509_free(idcert); - if (authcert) - X509_free(authcert); + X509_free(cert); + X509_free(idcert); + X509_free(authcert); return NULL; } @@ -2035,8 +2029,7 @@ tor_tls_finish_handshake(tor_tls_t *tls) "a v2 handshake on %p.", tls); tls->wasV2Handshake = 1; } - if (cert) - X509_free(cert); + X509_free(cert); #endif if (SSL_set_cipher_list(tls->ssl, SERVER_CIPHER_LIST) == 0) { tls_log_errors(NULL, LOG_WARN, LD_HANDSHAKE, "re-setting ciphers"); @@ -2319,8 +2312,7 @@ tor_tls_verify(int severity, tor_tls_t *tls, crypto_pk_t **identity_key) r = 0; done: - if (cert) - X509_free(cert); + X509_free(cert); if (id_pkey) EVP_PKEY_free(id_pkey); @@ -2353,8 +2345,7 @@ tor_tls_check_lifetime(int severity, tor_tls_t *tls, r = 0; done: - if (cert) - X509_free(cert); + X509_free(cert); /* Not expected to get invoked */ tls_log_errors(tls, LOG_WARN, LD_NET, "checking certificate lifetime"); diff --git a/src/common/util.h b/src/common/util.h index 8bb4505..9ba9d9a 100644 --- a/src/common/util.h +++ b/src/common/util.h @@ -107,8 +107,8 @@ extern int dmalloc_free(const char *file, const int line, void *pnt, STMT_END #else /** Release memory allocated by tor_malloc, tor_realloc, tor_strdup, etc. - * Unlike the free() function, tor_free() will still work on NULL pointers, - * and it sets the pointer value to NULL after freeing it. + * Unlike the free() function, tor_free() sets the pointer value to NULL + * after freeing it. * * This is a macro. If you need a function pointer to release memory from * tor_malloc(), use tor_free_(). diff --git a/src/ext/eventdns.c b/src/ext/eventdns.c index a0c7ff2..cfc3344 100644 --- a/src/ext/eventdns.c +++ b/src/ext/eventdns.c @@ -1923,9 +1923,7 @@ server_request_free(struct server_request *req) rc = --req->port->refcnt; } - if (req->response) { - mm_free(req->response); - } + mm_free(req->response); server_request_free_answers(req); @@ -3216,8 +3214,7 @@ load_nameservers_with_getnetworkparams(void) } done: - if (buf) - mm_free(buf); + mm_free(buf); if (handle) FreeLibrary(handle); return status; diff --git a/src/ext/tinytest_demo.c b/src/ext/tinytest_demo.c index c07f099..7279216 100644 --- a/src/ext/tinytest_demo.c +++ b/src/ext/tinytest_demo.c @@ -169,8 +169,7 @@ test_memcpy(void *ptr) end: /* This time our end block has something to do. */ - if (mem) - free(mem); + free(mem); } void diff --git a/src/or/buffers.c b/src/or/buffers.c index 85fcbc6..e5d2894 100644 --- a/src/or/buffers.c +++ b/src/or/buffers.c @@ -1014,7 +1014,7 @@ fetch_var_cell_from_evbuffer(struct evbuffer *buf, var_cell_t **out, result = 1; done: - if (free_hdr && hdr) + if (free_hdr) tor_free(hdr); return result; } @@ -2410,8 +2410,7 @@ generic_buffer_set_to_copy(generic_buffer_t **output, } } #else - if (*output) - buf_free(*output); + buf_free(*output); *output = buf_copy(input); #endif return 0; diff --git a/src/or/channel.c b/src/or/channel.c index af09502..b1dc63e 100644 --- a/src/or/channel.c +++ b/src/or/channel.c @@ -917,10 +917,8 @@ channel_force_free(channel_t *chan) channel_clear_remote_end(chan); /* Get rid of cmux */ - if (chan->cmux) { - circuitmux_free(chan->cmux); - chan->cmux = NULL; - } + circuitmux_free(chan->cmux); + chan->cmux = NULL; /* We might still have a cell queue; kill it */ TOR_SIMPLEQ_FOREACH_SAFE(cell, &chan->incoming_queue, next, cell_tmp) { diff --git a/src/or/config.c b/src/or/config.c index 6e782de..e3d7721 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -7263,11 +7263,9 @@ init_cookie_authentication(const char *fname, const char *header, goto done; } - /* If we've already set the cookie, free it before re-setting - it. This can happen if we previously generated a cookie, but - couldn't write it to a disk. */ - if (*cookie_out) - tor_free(*cookie_out); + /* Free this cookie before re-setting it. This can happen if we + * previously generated a cookie, but couldn't write it to a disk. */ + tor_free(*cookie_out); /* Generate the cookie */ *cookie_out = tor_malloc(cookie_len); diff --git a/src/or/ext_orport.c b/src/or/ext_orport.c index e8c8aa6..b4f4cab 100644 --- a/src/or/ext_orport.c +++ b/src/or/ext_orport.c @@ -476,9 +476,7 @@ connection_ext_or_handle_cmd_useraddr(connection_t *conn, /* record the address */ tor_addr_copy(&conn->addr, &addr); conn->port = port; - if (conn->address) { - tor_free(conn->address); - } + tor_free(conn->address); conn->address = tor_dup_addr(&addr); return 0; @@ -509,11 +507,8 @@ connection_ext_or_handle_cmd_transport(or_connection_t *conn, return -1; } - /* If ext_or_transport is already occupied (because the PT sent two - * TRANSPORT commands), deallocate the old name and keep the new - * one */ - if (conn->ext_or_transport) - tor_free(conn->ext_or_transport); + /* deallocate the ext_or_transport's old name and keep the new one */ + tor_free(conn->ext_or_transport); conn->ext_or_transport = transport_str; return 0; @@ -643,7 +638,6 @@ connection_ext_or_start_auth(or_connection_t *or_conn) void ext_orport_free_all(void) { - if (ext_or_auth_cookie) /* Free the auth cookie */ - tor_free(ext_or_auth_cookie); + tor_free(ext_or_auth_cookie); } diff --git a/src/or/onion_tap.c b/src/or/onion_tap.c index 487cbee..4645ca4 100644 --- a/src/or/onion_tap.c +++ b/src/or/onion_tap.c @@ -75,7 +75,7 @@ onion_skin_TAP_create(crypto_pk_t *dest_router_key, return 0; err: memwipe(challenge, 0, sizeof(challenge)); - if (dh) crypto_dh_free(dh); + crypto_dh_free(dh); return -1; } diff --git a/src/or/rendservice.c b/src/or/rendservice.c index db6bc4b..1fb5245 100644 --- a/src/or/rendservice.c +++ b/src/or/rendservice.c @@ -1746,7 +1746,7 @@ rend_service_receive_introduction(origin_circuit_t *circuit, (unsigned)circuit->base_.n_circ_id); err: status = -1; - if (dh) crypto_dh_free(dh); + crypto_dh_free(dh); if (launched) { circuit_mark_for_close(TO_CIRCUIT(launched), reason); } diff --git a/src/or/replaycache.c b/src/or/replaycache.c index 569e073..f327fa7 100644 --- a/src/or/replaycache.c +++ b/src/or/replaycache.c @@ -18,10 +18,8 @@ void replaycache_free(replaycache_t *r) { - if (!r) { - log_info(LD_BUG, "replaycache_free() called on NULL"); + if (!r) return; - } if (r->digests_seen) digestmap_free(r->digests_seen, tor_free_); diff --git a/src/or/routerparse.c b/src/or/routerparse.c index c2206f1..71bcb7e 100644 --- a/src/or/routerparse.c +++ b/src/or/routerparse.c @@ -3840,8 +3840,7 @@ assert_addr_policy_ok(smartlist_t *lst) static void token_clear(directory_token_t *tok) { - if (tok->key) - crypto_pk_free(tok->key); + crypto_pk_free(tok->key); } #define ALLOC_ZERO(sz) memarea_alloc_zero(area,sz) diff --git a/src/test/test.c b/src/test/test.c index e10e260..d978f78 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -572,14 +572,10 @@ test_rend_fns(void *arg) rend_encoded_v2_service_descriptor_free(smartlist_get(descs, i)); smartlist_free(descs); } - if (parsed) - rend_service_descriptor_free(parsed); - if (generated) - rend_service_descriptor_free(generated); - if (pk1) - crypto_pk_free(pk1); - if (pk2) - crypto_pk_free(pk2); + rend_service_descriptor_free(parsed); + rend_service_descriptor_free(generated); + crypto_pk_free(pk1); + crypto_pk_free(pk2); tor_free(intro_points_encrypted); } diff --git a/src/test/test_buffers.c b/src/test/test_buffers.c index e8fce12..8cc1b61 100644 --- a/src/test/test_buffers.c +++ b/src/test/test_buffers.c @@ -189,10 +189,8 @@ test_buffers_basic(void *arg) } done: - if (buf) - buf_free(buf); - if (buf2) - buf_free(buf2); + buf_free(buf); + buf_free(buf2); } static void @@ -362,10 +360,8 @@ test_buffer_copy(void *arg) } done: - if (buf) - generic_buffer_free(buf); - if (buf2) - generic_buffer_free(buf2); + generic_buffer_free(buf); + generic_buffer_free(buf2); } static void diff --git a/src/test/test_crypto.c b/src/test/test_crypto.c index dbaec61..71a94f8 100644 --- a/src/test/test_crypto.c +++ b/src/test/test_crypto.c @@ -269,10 +269,8 @@ test_crypto_aes(void *arg) done: tor_free(mem_op_hex_tmp); - if (env1) - crypto_cipher_free(env1); - if (env2) - crypto_cipher_free(env2); + crypto_cipher_free(env1); + crypto_cipher_free(env2); tor_free(data1); tor_free(data2); tor_free(data3); @@ -412,10 +410,8 @@ test_crypto_sha(void *arg) tt_mem_op(d_out1,OP_EQ, d_out2, DIGEST_LEN); done: - if (d1) - crypto_digest_free(d1); - if (d2) - crypto_digest_free(d2); + crypto_digest_free(d1); + crypto_digest_free(d2); tor_free(mem_op_hex_tmp); } diff --git a/src/test/test_dir.c b/src/test/test_dir.c index 855746e..bf7ce59 100644 --- a/src/test/test_dir.c +++ b/src/test/test_dir.c @@ -346,20 +346,17 @@ test_dir_formats(void *arg) dirserv_free_fingerprint_list(); done: - if (r1) - routerinfo_free(r1); - if (r2) - routerinfo_free(r2); - if (rp2) - routerinfo_free(rp2); + routerinfo_free(r1); + routerinfo_free(r2); + routerinfo_free(rp2); tor_free(rsa_cc); tor_free(buf); tor_free(pk1_str); tor_free(pk2_str); - if (pk1) crypto_pk_free(pk1); - if (pk2) crypto_pk_free(pk2); - if (rp1) routerinfo_free(rp1); + crypto_pk_free(pk1); + crypto_pk_free(pk2); + routerinfo_free(rp1); tor_free(dir1); /* XXXX And more !*/ tor_free(dir2); /* And more !*/ } @@ -2315,32 +2312,19 @@ test_a_networkstatus( tor_free(consensus_text); tor_free(consensus_text_md); - if (vote) - networkstatus_vote_free(vote); - if (v1) - networkstatus_vote_free(v1); - if (v2) - networkstatus_vote_free(v2); - if (v3) - networkstatus_vote_free(v3); - if (con) - networkstatus_vote_free(con); - if (con_md) - networkstatus_vote_free(con_md); - if (sign_skey_1) - crypto_pk_free(sign_skey_1); - if (sign_skey_2) - crypto_pk_free(sign_skey_2); - if (sign_skey_3) - crypto_pk_free(sign_skey_3); - if (sign_skey_leg1) - crypto_pk_free(sign_skey_leg1); - if (cert1) - authority_cert_free(cert1); - if (cert2) - authority_cert_free(cert2); - if (cert3) - authority_cert_free(cert3); + networkstatus_vote_free(vote); + networkstatus_vote_free(v1); + networkstatus_vote_free(v2); + networkstatus_vote_free(v3); + networkstatus_vote_free(con); + networkstatus_vote_free(con_md); + crypto_pk_free(sign_skey_1); + crypto_pk_free(sign_skey_2); + crypto_pk_free(sign_skey_3); + crypto_pk_free(sign_skey_leg1); + authority_cert_free(cert1); + authority_cert_free(cert2); + authority_cert_free(cert3); tor_free(consensus_text2); tor_free(consensus_text3); @@ -2348,18 +2332,12 @@ test_a_networkstatus( tor_free(consensus_text_md3); tor_free(detached_text1); tor_free(detached_text2); - if (con2) - networkstatus_vote_free(con2); - if (con3) - networkstatus_vote_free(con3); - if (con_md2) - networkstatus_vote_free(con_md2); - if (con_md3) - networkstatus_vote_free(con_md3); - if (dsig1) - ns_detached_signatures_free(dsig1); - if (dsig2) - ns_detached_signatures_free(dsig2); + networkstatus_vote_free(con2); + networkstatus_vote_free(con3); + networkstatus_vote_free(con_md2); + networkstatus_vote_free(con_md3); + ns_detached_signatures_free(dsig1); + ns_detached_signatures_free(dsig2); } /** Run unit tests for generating and parsing V3 consensus networkstatus diff --git a/src/test/test_replay.c b/src/test/test_replay.c index a02c160..538b2df 100644 --- a/src/test/test_replay.c +++ b/src/test/test_replay.c @@ -27,7 +27,7 @@ test_replaycache_alloc(void *arg) tt_assert(r != NULL); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -51,7 +51,7 @@ test_replaycache_badalloc(void *arg) tt_assert(r == NULL); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -90,7 +90,7 @@ test_replaycache_miss(void *arg) tt_int_op(result,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -116,7 +116,7 @@ test_replaycache_hit(void *arg) tt_int_op(result,OP_EQ, 1); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -147,7 +147,7 @@ test_replaycache_age(void *arg) tt_int_op(result,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -175,7 +175,7 @@ test_replaycache_elapsed(void *arg) tt_int_op(elapsed,OP_EQ, 100); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -206,7 +206,7 @@ test_replaycache_noexpire(void *arg) tt_int_op(result,OP_EQ, 1); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -248,7 +248,7 @@ test_replaycache_scrub(void *arg) tt_int_op(digestmap_size(r->digests_seen),OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -292,7 +292,7 @@ test_replaycache_future(void *arg) tt_int_op(elapsed,OP_EQ, 0); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } @@ -335,7 +335,7 @@ test_replaycache_realtime(void *arg) replaycache_scrub_if_needed(r); done: - if (r) replaycache_free(r); + replaycache_free(r); return; } diff --git a/src/test/test_routerset.c b/src/test/test_routerset.c index 9bd0c12..b13ec40 100644 --- a/src/test/test_routerset.c +++ b/src/test/test_routerset.c @@ -1144,8 +1144,7 @@ NS(test_main)(void *arg) tt_int_op(r, OP_EQ, 0); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t @@ -1186,8 +1185,7 @@ NS(test_main)(void *arg) tt_int_op(smartlist_contains_string(set->list, "{??}"), OP_EQ, 1); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t @@ -1249,8 +1247,7 @@ NS(test_main)(void *arg) tt_int_op(smartlist_contains_string(set->list, "{a1}"), OP_EQ, 1); done: - if (set != NULL) - routerset_free(set); + routerset_free(set); } country_t diff --git a/src/test/test_status.c b/src/test/test_status.c index cbc8af1..7e18b5d 100644 --- a/src/test/test_status.c +++ b/src/test/test_status.c @@ -145,8 +145,7 @@ NS(test_main)(void *arg) tor_free(actual); done: - if (actual != NULL) - tor_free(actual); + tor_free(actual); } #undef NS_SUBMODULE @@ -226,8 +225,7 @@ NS(test_main)(void *arg) tor_free(actual); done: - if (actual != NULL) - tor_free(actual); + tor_free(actual); } #undef NS_SUBMODULE diff --git a/src/test/test_util.c b/src/test/test_util.c index 0a5783e..a4341d9 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1707,8 +1707,7 @@ test_util_gzip(void *arg) tt_int_op(21,OP_EQ, len2); done: - if (state) - tor_zlib_free(state); + tor_zlib_free(state); tor_free(buf2); tor_free(buf3); tor_free(buf1);

4 4

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing
by ncl＠cock.li 30 Aug '15

30 Aug '15

I came across this thread from the weekly news post for this week, so please excuse me if I've missed some from just skimming through the posts. Having randomart/gravatars/poems/etc seems like a rather interesting topic, but seriously adding it to tor, there seems to be a few problems in my mind: a) This doesn't stop someone from phishing if the target has never seen the hs address before. (proving identities is another issue though I guess, the focus on this discussion being how to implement TOFU.) b) People's memories are imperfect and even if with a system that may generate wildly distinct results even with similar addresses, remembering a number of those will become a blur. c) This all seems rather complicated. Since the point seems to just be keeping a record that addresses match once you're reasonably sure you've found the right one, wouldn't something of an "address book" be much simpler and easier? It might not even need to be a feature of tor/tbb, but maybe just a tip to users. It could be something as simple as a gpg-encrypted text file if you're worried about leaking sites you visit. (I hope I don't get much about using "gpg" and "simple" in the same sentence.) Another few things popped up in my mind while thinking about this: - Should tbb distribute hsts preload-like lists for HS's (eg for securedrops?) - A set of guidelines should be published on how an HS owner should prove their identity. (wouldn't want another sigaint incident!) - Can/should a system be set up to monitor HS addresses that are similar to existing ones? - For HS's which do not need to be as anonymous, should a tor-specific CA be created, or be encouraged to try and use a CA as a means of extra verification? A tor-specific CA might be better, since an attacker might be able to get their phishing cert signed. If the previous point is implemented, more precautions could be put in place to verify an HS's identity.

1 0

7th and last status report for OnioNS
by Jesse V 28 Aug '15

28 Aug '15

Happy Friday everyone, This is my last status report for the Summer of Privacy program, but I think I can end my reports on a good note. * At the suggestion of several people, I rewrote the networking infrastructure. Before, OnioNS-client and OnioNS-HS contacted the servers over Tor circuits, and OnioNS-server sent messages to each other over unencrypted TCP/IP links P2P-style. Now, the servers bind to localhost and are powered by hidden services, so all server-server communication occurs Ricochet-style. This is superior because it provides a significant increase to network attacks, works around the problem of distributing another TCP port in the consensus, and allows Tor relay administrators to run OnioNS servers without having to punch yet another hole in their firewall. I don't need anonymity for server P2P communication, so I will certainly be using the single onion service infrastructure when it becomes available. * All OnioNS servers now manage Ed25519 keypairs. In my design, authoritative Quorum servers will use their key for authenticated denial-of-existence and to prevent regular name servers from forging responses, but this infrastructure is not fully in place yet. When OnioNS merges into Tor, this keypair would be each router's signing key or at least a keypair signed by the signing key. * Servers now save newly-received Records to disk to prevent them. The cache file is loaded when the server starts up. * OnioNS-HS now saves newly-validated Records to disk before attempting to upload them. This is incredibly handy to prevent having to re-preform all the proof-of-work if the upload fails. * OnioNS-HS no longer has a dependency on little-t-tor. As s7r wisely points out, some people may have installed tor from git. I also added a flag to specify the number of worker threads, which can help reduce the system requirements if the HS is hosted on a VM with minimal system resources. * OnioNS-client no longer logs all Tor Browser activity. I used this for debugging, but it's no longer worth compromising user privacy. The software also correctly shuts down when the Tor Browser closes; in the process of fixing this I also discovered that it's not a good idea to misinterpret the documentation and run an application containing "kill(0, SIGTERM);". The result was quite unexpected. * In addition to intercepting all *.tor domains, OnioNS-client now rewrites "check.torproject.org" to another domain that shows that OnioNS is enabled in the browser. Before, users had to visit "example.tor" to confirm that the OnioNS software is running, but this was problematic because if OnioNS wasn't running, they get an error message because their exit node cannot resolve "example.tor" on the Internet DNS. Now these failures no longer leak. * I've stopped packaging my own build of jsoncpp, so I added a dependency for a system installation. Fortunately, Ubuntu/Mint, Debian, and Fedora all have that library in their repositories. * Logs now include the date and time, which is quite handy. * Numerous bugfixes, most notably I fixed the bug where the recipient would fail to understand a message longer than 500 bytes. To summarize the state of the project at the end of the SoP program: * All of the infrastructure for OnioNS is in place. There are still a few protocols left to finish off, but all big tasks are complete. The client-side and HS-side software is pretty reliable and stable at this point. * Although the software lacks in-line documentation, I have gone to great lengths to increase its readability and overall organization. * OnioNS runs just fine on Debian, Ubuntu, Mint, and Fedora, although I do not have any support for Windows or OS X. I'm asking for help from any Windows developer to help port the client software over there, please talk to me about that. * I have full intentions of continuing to maintain the OnioNS project. Please keep an eye on https://github.com/Jesse-V?tab=repositories and I will post here when I push out releases. I'm very close to the next beta test. * Once the OnioNS software is fully ready, no modifications to Tor should be necessary to merge OnioNS into the Tor network. Thanks everyone for the help, it's been a great summer project! Jesse V.

1 0

patch to improve consensus download decompress performance
by starlight.2015q3＠binnacle.cx 28 Aug '15

28 Aug '15

3 2

Triaged some TorCoreTeam201508 tickets; please review
by Nick Mathewson 26 Aug '15

26 Aug '15

Hi! I've moved all the TorCoreTeam201508 tickets to TorCoreTeam201509 or out entirely. I've also moved some of them to the 0.2.8 milestone, and tentatively assigned the PostFreeze027 ticket to others. If I'm wrong about any of those, please feel free to fix 'em! Now I'm moving on to the 0.2.7 milestone as a whole. In general, any ticket in 0.2.7 that isn't tagged with PostFreeze027 is not going to be a candidate for merge after 1 Sep, so please keep that in mind. (You can add the tag to your own tickets if you want, but please do so judiciously and in moderation.) cheers, -- Nick

1 1

FSCONS CFP extended
by tordevmuc＠encambio.com 26 Aug '15

26 Aug '15

Hello list, Organizers of the Free Society Conference and Nordic Summit (FSCONS) taking place in Goeteborg, Sweden on 7-8 November have extended the CFP and seek speakers [1] for the event. Particularly relevant to us is the track: Everyday Crypto ...and being that at least one group friendly to Tor is already scheduled, it would be a welcome gesture to have a Tor lecture or workshop as well. Anyone interested in this should contact Stian (in Cc) with a speaking/workshop proposal. [1] https://fscons.org/2015/cfp.html Cheers, Michael

1 0

Hash Visualizations to Protect Against Onion Phishing
by George Kadianakis 26 Aug '15

26 Aug '15

Hello, this mail lays down an idea for a TBB UI feature that will make it slightly harder to launch phishing attacks against hidden services. The idea is based on hash visualizations like randomart [0] and key poems: ------------------- | o=. | | o o++E | | + . Ooo. | | + O B.. | | = *S. | | o | | | | | | | ------------------- The idea came up during a discussion with Jeff Burdges in CCC camp. This is a heavily experimental idea and there are various unresolved research and UX issues here, but we hope that we will motivate further study. The aim is to make it harder to phish people who click untrusted onion links. Think of when you click an onion link on a forum, or when a friend sends you an onion URL. The problem is that many people don't verify the whole onion address, they just trust the onion link or verify the first few characters. This is bad since an attacker can create a hidden service with a similar onion address very easily. There are currently ready-made scripts that people have been using to launch impersonation attacks against real hidden services. The suggested improvement here is for TBB to provide additional visual fingerprints that people can use to verify the authenticity of a hidden service. So when TBB connects to a hidden service, it uses the onion address to generate a randomart or key poem and makes them available for the user to examine. Here is an experimental mockup just to illustrate the idea: https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png The idea is that you hash (or scrypt!) the onion address, and then you make a visualization using the hash output. This forces the phishing attacker to generate a similar onion address _and_ similar hash visualizations. We assume that this will be harder to do than simply faking a similar onion address, which increases the startup cost for such an attacker. This is the basic concept. Now, here are some thoughts: - What hash visualizations can we use here? The SSH randomart is an obvious idea, and we can even have it colored since we are not in a terminal. Then we have the key poem idea, which generates a poem from a key. I don't think this is used by a deployed system currently. Then we could imagine music-based hash fingerprints, where the onion address corresponds to a small tune that is played when you visit an onion. Then there are even more crazy ideas like the "Dynamic Security Skins" paper [1]. So for example, TBB could generate a unique UI theme for each hidden service. - Of course, none of the above ideas is perfect. Actually most of them suck. For example, when it comes to randomart, many people are colorblind to some degree and most people are not good at recognizing subtle color differences. Furthermore, given a randomart, it's easy [2] to generate similar randomarts. However we hope that most of those similar randomarts will not correspond to a public key that is similar to the original one. When it comes to key poems, given even a moderately sized dictionary leads to pretty big poems. We are talking about poems of 24 random words, which is not something that most people can remember. Much more research needs to be done here. - Even though all these techniques are flawed in some way or another, we hope that by deploying them we increase the cost of the attacker. If a few of these techniques are implemented, a phishing attacker will have to spend time generating similar visualizations, because she does not know whether the user actually looks at them and which one the user prefers. Also, this feature only requires a TBB addon/patch and no modifications to the Tor protocol whatsoever, which makes it slightly easier to prototype and experiment with. - On the other hand, this might be a terrible idea for multiple reasons. From the UX perspective, it will confuse people who don't expect to see crazy visuals or poems on their browser. Our hope here is that this feature will be hidden by most users, and will only be used by people who understand it. However, this exact logic is what causes bad UI. Also, from a security perspective this might encourage people to not spend time to verify the whole onion address (currently 16 chars, but will be extended to 54 chars or so with prop224), and instead rely on the stupid randomart. Some real UX research needs to be done here, before we decide something terrible. - Finally, a positive thing with this idea is that it nicely complements directories of onion addresses like search engines and human-memorable systems. In the future, people who visit the same onion address using a search engine all the time, will have an extra way of verifying its authenticity. In any case, this is just a crazy pants idea, so please send your feedback to make it more useful, or to kill it completely! Cheers!~ [0]: http://undeadly.org/cgi?action=article&sid=20080615022750 http://users.ece.cmu.edu/~adrian/projects/validation/validation.pdf [1]: http://www.eecs.berkeley.edu/~tygar/papers/Phishing/Battle_against_phishing… [2]: http://www.dirk-loss.de/sshvis/drunken_bishop.pdf

9 11

Design for onionsite certification and use with Let's Encrypt
by Paul Syverson 26 Aug '15

26 Aug '15

Hi Alec, Seth, Peter, Mike, all, I'm enthused about the progress Alec reported about the Onion RFC for certs for onion addresses in recent tor-dev posts and elsewhere. I wanted to further discuss a design for binding .onion addresses with registered (route-insecure) addresses. This ties in to in-person discussions had with Seth, Peter, and Mike back in June about how this all dovetails with Let's Encrypt and Tor Browser, which is why I am also addressing this message to them directly. I hope they can comment on whether this design seems realistic in that regard and any major caveats, stumbling blocks, etc. I'll start with a description of goals and complementarity comments about readability of onion addresses themselves, and other recent tor-dev discussion topics. I did a partially related post to tor-assistants on one-sided onion services back in June that covered perhaps too many alternatives concerning onion services and too many goals and too much of the motivation, and none of that adequately separated. I think it left most scratching their heads. This is an attempt to be a bit narrower and hopefully clearer. Those not interested in even the briefly described motivations and background set out here can skip below to the high-level design itself. Goals, Caveats, Complementarity to other recently discussed related topics A main goal is to give people a way to provide route-secure access to their websites in somewhat the same way that the current certificate and https protocol infrastructure lets them provide data-secure access to their website. I would really like to have a version of this be an offering as part of obtaining a certificate from Let's Encrypt because I would like it to encourage people to offer route-secure versions of their sites in the same way that Let's Encrypt as currently put forth is meant to encourage them to offer data-secure versions of their sites. Having this built into something like Let's Encrypt should make it easy for users to set up onionsites to provide security for their websites. The design should to be neutral between double onion services (services where connections involve a Tor circuit from the client and a Tor circuit from the server, such as the currently deployed design) and single onion services (basically just having a Tor circuit from the client). There's a draft Tor Proposal by John Brooks, Roger Dingeldine, and me on single onion services that I believe John should be making available soon, but I want to leave such details aside. I'm taking single onion services as the paradigmatic typical case, but unless it creates a big problem I would like to assume both single and double onion services will be compatible. Obviously an onion service tied to a registered domain doesn't cover many important uses of onion services, but it should cover many existing use cases. Note also that wanting to offer network-location protection for a service can be compatible with having a registered domain name for that service (and whether or not there was any attempt to obscure information about the registrant of the domain name). In some cases it is not compatible, but not necessarily. I think this is basically complementary to ways to make onion addresses more readable, recognizable. I'm OK with whatever an address is that will be acceptable to the RFC and that maintains the current self-authenticating property (not getting into quibbles about computational strength of that self-authentication), as long as it remains something that will fit into a cert as described below. I'm also leaving as an extension mentioned at the end below, offering an onion service for someone's site but not associated with a domain name she has registered. (E.g. an onionsite tied to Mary's Wordpress Blog, with, e.g., the goal being more about guarantees of binding to Mary than about guarantees of binding Wordpress.) I think that is another important and useful case, which we discussed in our W2SP paper, but I'd like to mostly leave it aside for now. High-level Design Creating the DV Cert At least the same DV level of checking should occur as for existing registered domain names. So the email check should include the onion name that is being bound as well as the route-insecure name(s). For simplicity, I am assuming a single onion address and possibly a small number of registered domain names, although I'm guessing doing this for a similarly small number of onion addresses might be made to work as well. (I'm assuming no wildcards, but maybe I'm not being ambitious enough.) Besides a check at the registered-domain name(s) a check should also be made that the onionsite verifies association with the registered-domain site(s). It is not as reasonable to assume email infrastructure exists corresponding to the onion address is in place. Instead a validation query protocol will be needed that simply connects to the onionsite and asks if it is acceptable to certify association of the onionsite with the registered-domain(s). Only if all DV checks complete successfully should the CA be willing to issue the Cert. The cert obtained will have the onion address listed as a SAN (subjectAltName) in the certificate. Connecting to an onionsite by the client I assume that the default HTTPS-everywhere ruleset will be updated to include a direction of route-insecure addresses to onion addresses for sites that hold appropriate certificates. It would be reasonable to have this update occur initially along with the certification process. HTTPS-everywhere rules should differentiate whether they are being requested by Tor Browser or another browser. If by Tor Browser, I assume(?) the redirection is straightforward: If a Tor-Browser request is to connect to a route-insecure address, HTTPS-everywhere should redirect this to an onion address. At that point everything should proceed as normal for connecting to an onion address. If another browser it could be a setup config option whether clients can choose to be redirected via tor2web or simply always sent to a route-insecure address. I will assume for simplicity that all requests for route-insecure addresses by other browsers simply send to a route-insecure HTTPS address in the ruleset (if available). I'm going to also assume that requests for onion addresses for other browsers simply fail, although if the tor2web option was available and chosen at the time of setup, then there is another question how to offer this to the client, perhaps as an HTTPS Everywhere setting. Comments on the feasibility, usefulness, design etc. of the tor2web option would be bonus, but of course I'm most wanting to know about the viability of the most basic version of things. If the Tor-Browser request is to connect to an onion address, proceed as normal except that it can now be redirected by HTTPS Everywhere to an https connection to the address. Certified connection to such an onionsite should work and be indicated as normal for any site with a DV Cert. End basic description Web of trust extension W had suggested in the w2sp paper that people could bind their route-insecure address to their onion address with a gpg key. One rationale is that there is an existing web of trust that can be leveraged, and existing mechanisms to do the verification. This would allow not just securing of human-meaningful addresses and connections but also certification by more human-meaningful trust relations than the usual CA. It also allows things like binding a wordpress blog to an onion address as mentioned above so people need not have a registered domain to have a human-meaningful address for a route-insecure site for which they would like to offer a route-secure alternative. Drawbacks include: 1. There is no simple automated significant infrastructure to support this. The Monkeysphere plugin is out there, and would probably be leveraged to support something like this, but... 2. PGP/GPG remains something of a geek tool. That is possibly changing slowly, but perhaps it would be better not to wait for that. Also, it's yet another thing to learn about, so... If onion keys could be themselves linked in a PGP-like web of trust, then this could be more directly relevant and meaning to people operating on the web, especially those unfamiliar with PGP-like notions. This would of course require things like the check and indication being either built into the browser or as a plugin. And it would similarly for people deciding when to sign another's key require an easy interface and easy to understand criteria as well as mechanisms for that to all happen securely. I think this holds more hope for successful widespread web of trust to complement the X.509 type trust hierarchy that the PGP plan would support. How to decide whether a site is trusted depending what each of these trust mechanisms indicate would also need to be worked out and might again be configurable with standard defaults.

3 3