November 2015 - tor-commits - lists.torproject.org

[torspec/master] Give rend-single-onion a number (260)
by nickm＠torproject.org 21 Nov '15

21 Nov '15

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

1 0

[tor-messenger-build/master] Rebase preferences.patch
by sukhbir＠torproject.org 20 Nov '15

20 Nov '15

commit a9c422ed3d1ddde30e654dc7eda31d51e1aa8831 Author: Sukhbir Singh <sukhbir(a)torproject.org> Date: Fri Nov 20 16:18:10 2015 -0500 Rebase preferences.patch --- projects/instantbird/preferences.patch | 91 ++++++++++++++++++++++++++++---- 1 file changed, 80 insertions(+), 11 deletions(-) diff --git a/projects/instantbird/preferences.patch b/projects/instantbird/preferences.patch index 72f2ab0..9af290b 100644 --- a/projects/instantbird/preferences.patch +++ b/projects/instantbird/preferences.patch @@ -1,7 +1,12 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird.js --- a/im/app/profile/all-instantbird.js +++ b/im/app/profile/all-instantbird.js -@@ -64,9 +64,6 @@ +@@ -59,19 +59,16 @@ pref("extensions.mintrayr.startMinimized + // For Linux, use single click. + pref("extensions.mintrayr.singleClickRestore", true); + #else + // For Windows, use double click. + pref("extensions.mintrayr.singleClickRestore", false); #endif #endif @@ -11,7 +16,17 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. // Specifies whether each message event should trigger a sound for incoming // and outgoing messages, or when your nickname is mentioned in a chat. pref("messenger.options.playSounds.outgoing", true); -@@ -114,14 +111,6 @@ + pref("messenger.options.playSounds.incoming", true); + pref("messenger.options.playSounds.alert", true); + // Whether contact list related sounds should be played at all. If this is + // enabled then the more specific prefs are checked as well. + pref("messenger.options.playSounds.blist", false); +@@ -109,41 +106,33 @@ pref("browser.preferences.animateFadeIn" + pref("browser.zoom.full", true); + pref("conversation.zoomLevel", "1.0"); + + pref("accessibility.typeaheadfind", false); + pref("accessibility.typeaheadfind.timeout", 5000); pref("accessibility.typeaheadfind.linksonly", false); pref("accessibility.typeaheadfind.flashBar", 1); @@ -26,7 +41,16 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. // Defines how the Application Update Service notifies the user about updates: // // AUM Set to: Minor Releases: Major Releases: -@@ -138,7 +127,7 @@ + // 0 download no prompt download no prompt + // 1 download no prompt download no prompt if no incompatibilities + // 2 download no prompt prompt + // + // See chart in nsUpdateService.js.in for more details + // + pref("app.update.mode", 1); + + // If set to true, the Update Service will present no UI for any event. + pref("app.update.silent", false); // If set to true, the Update Service will apply updates in the background // when it finishes downloading them. @@ -35,28 +59,55 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. // Update service URL: // You do not need to use all the %VAR% parameters. Use what you need, %PRODUCT%,%VERSION%,%BUILD_ID%,%CHANNEL% for example -@@ -198,9 +187,6 @@ + pref("app.update.url", "https://update.instantbird.org/1/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARG…"); + + // URL user can browse to manually if for some reason all update installation + // attempts fail. + pref("app.update.url.manual", "http://www.instantbird.com/download.html"); +@@ -194,17 +183,17 @@ pref("browser.search.defaultenginename", + // disable logging for the search service by default + pref("browser.search.log", false); + + // Ordering of Search Engines in the Engine list. pref("browser.search.order.1", "chrome://instantbird/locale/region.properties"); pref("browser.search.order.2", "chrome://instantbird/locale/region.properties"); --// send ping to the server to update + // send ping to the server to update -pref("browser.search.update", true); -- ++pref("browser.search.update", false); + // disable logging for the search service update system by default pref("browser.search.update.log", false); -@@ -219,10 +205,8 @@ + // Check whether we need to perform engine updates every 6 hours + pref("browser.search.updateinterval", 6); + + /* Extension manager */ +@@ -214,17 +203,17 @@ pref("xpinstall.dialog.progress.chrome", + pref("xpinstall.dialog.progress.type.skin", "Extension:Manager"); + pref("xpinstall.dialog.progress.type.chrome", "Extension:Manager"); + pref("extensions.dss.enabled", false); + pref("extensions.dss.switchPending", false); + pref("extensions.ignoreMTimeChanges", false); pref("extensions.logging.enabled", false); pref("general.skins.selectedSkin", "classic/1.0"); -pref("extensions.update.enabled", true); ++pref("extensions.update.enabled", false); pref("extensions.update.interval", 86400); pref("extensions.update.url", "https://addons.instantbird.org/services/update.php?reqVersion=%REQ_VERSION%…"); --pref("extensions.update.autoUpdateDefault", true); + pref("extensions.update.autoUpdateDefault", true); // Preferences for the Get Add-ons pane pref("extensions.getAddons.cache.enabled", false); -@@ -242,9 +226,9 @@ + pref("extensions.getAddons.browseAddons", "https://addons.instantbird.org/%LOCALE%/%APP%"); + pref("extensions.getAddons.maxResults", 5); +@@ -237,35 +226,32 @@ pref("extensions.webservice.discoverURL" + pref("extensions.getMoreExtensionsURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/extensions/"); + pref("extensions.getMoreThemesURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/themes/"); + pref("extensions.getMorePluginsURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/plugins/"); + pref("extensions.getMoreMessageStylesURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/messagestyles/"); + pref("extensions.getMoreEmoticonsURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/emoticons/"); pref("extensions.getMoreProtocolsURL", "https://add-ons.instantbird.org/%LOCALE%/%APP%/%VERSION%/protocols/"); // suppress external-load warning for standard browser schemes @@ -69,7 +120,13 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. // don't load links inside Instantbird pref("network.protocol-handler.expose-all", false); -@@ -258,9 +242,6 @@ + // Although we allow these to be exposed internally, there are various places + // (e.g. message pane) where we may divert them out to external applications. + pref("network.protocol-handler.expose.about", true); + pref("network.protocol-handler.expose.http", true); + pref("network.protocol-handler.expose.https", true); + + // expose javascript: so that message themes can use it. // javascript: links inside messages are filtered out. pref("network.protocol-handler.expose.javascript", true); @@ -79,7 +136,17 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. // The breakpad report server to link to in about:crashes pref("breakpad.reportURL", "http://crash-stats.instantbird.com/report/index/"); -@@ -297,14 +278,82 @@ + // We have an Error Console menu item by default so let's display chrome errors + pref("javascript.options.showInConsole", true); + #ifdef DEBUG + // In debug builds, also display warnings by default + pref("javascript.options.strict", true); +@@ -292,19 +278,89 @@ pref("browser.tabs.tabClipWidth", 140); + + // Where to show tab close buttons: + // 0 on active tab only + // 1 on all tabs until tabClipWidth is reached, then active tab only + // 2 no close buttons at all // 3 at the end of the tabstrip pref("browser.tabs.closeButtons", 1); @@ -165,3 +232,5 @@ diff --git a/im/app/profile/all-instantbird.js b/im/app/profile/all-instantbird. +pref("extensions.update.autoUpdateDefault", false); +// Do not send ping to the server to update +pref("browser.search.update", false); ++// Set baseURL to Firefox default to prevent console errors ++pref("app.support.baseURL", "https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/");

1 0

[translation/tor-messenger-fingerdtd] Update translations for tor-messenger-fingerdtd
by translation＠torproject.org 20 Nov '15

20 Nov '15

commit 5f9c9d4049ab1513d6e6a1e26217ff31ce53f338 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 20 20:46:22 2015 +0000 Update translations for tor-messenger-fingerdtd --- ar/finger.dtd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ar/finger.dtd b/ar/finger.dtd index 6189dac..a0f1cc2 100644 --- a/ar/finger.dtd +++ b/ar/finger.dtd @@ -1,7 +1,7 @@ <!ENTITY finger.title "بصمات معروفة"> <!ENTITY finger.screenName "اسم الشاشة"> <!ENTITY finger.status "الحاﻻت"> -<!ENTITY finger.verified "Verified"> +<!ENTITY finger.verified "تم التحقق"> <!ENTITY finger.fingerprint "البصمة"> <!ENTITY finger.account "الحساب"> <!ENTITY finger.protocol "Protocol">

1 0

[tor-launcher/master] Bug 17344: enumerate available langpacks for lang prompt
by brade＠torproject.org 20 Nov '15

20 Nov '15

commit 20f01697b19ce938b894634d3ca4e39218137ea4 Author: Kathy Brade <brade(a)pearlcrescent.com> Date: Fri Nov 20 15:26:56 2015 -0500 Bug 17344: enumerate available langpacks for lang prompt Remove the hard-coded list of languages and build the listbox items from the set of installed language packs. --- src/chrome/content/localePicker.xul | 19 +------ src/chrome/content/network-settings.js | 97 +++++++++++++++++++++++++++----- 2 files changed, 85 insertions(+), 31 deletions(-) diff --git a/src/chrome/content/localePicker.xul b/src/chrome/content/localePicker.xul index be82e14..5b93825 100644 --- a/src/chrome/content/localePicker.xul +++ b/src/chrome/content/localePicker.xul @@ -35,24 +35,7 @@ <vbox> <label class="question">&torlauncher.localePicker.prompt;</label> <separator/> - <listbox id="localeList" ondblclick="onLocaleListDoubleClick()"> - <listitem value="en-US" label="English" selected="true" /> - <listitem value="ar" label="العربية" /> - <listitem value="de" label="Deutsch" /> - <listitem value="es-ES" label="Español" /> - <listitem value="fa" label="فارسی" /> - <listitem value="fr" label="Français" /> - <listitem value="it" label="Italiano" /> - <listitem value="ja" label="日本語" /> - <listitem value="ko" label="한국어" /> - <listitem value="nl" label="Nederlands" /> - <listitem value="pl" label="Polski" /> - <listitem value="pt-PT" label="Português (Europeu)" /> - <listitem value="ru" label="Русский" /> - <listitem value="tr" label="Türkçe" /> - <listitem value="vi" label="Tiếng Việt" /> - <listitem value="zh-CN" label="简体字" /> - </listbox> + <listbox id="localeList" ondblclick="onLocaleListDoubleClick()"/> </vbox> </wizardpage> diff --git a/src/chrome/content/network-settings.js b/src/chrome/content/network-settings.js index 2382ea6..9d3cb60 100644 --- a/src/chrome/content/network-settings.js +++ b/src/chrome/content/network-settings.js @@ -247,27 +247,98 @@ function initLocaleDialog() if (nextBtn && doneBtn) doneBtn.label = nextBtn.label; - // Select the current language by default. + let { AddonManager } = Cu.import("resource://gre/modules/AddonManager.jsm"); + AddonManager.getAddonsByTypes(["locale"], function(aLangPackAddons) + { + populateLocaleList(aLangPackAddons); + resizeDialogToFitContent(); + TorLauncherLogger.log(2, "initLocaleDialog done"); + }); +} + + +function populateLocaleList(aLangPackAddons) +{ + let knownLanguages = { + "en-US" : "English", + "ar" : "\u0627\u0644\u0639\u0631\u0628\u064a\u0629", + "de" : "Deutsch", + "es-ES" : "Espa\u00f1ol", + "fa" : "\u0641\u0627\u0631\u0633\u06cc", + "fr" : "Fran\u00e7ais", + "it" : "Italiano", + "ja" : "\u65e5\u672c\u8a9e", + "ko" : "\ud55c\uad6d\uc5b4", + "nl" : "Nederlands", + "pl" : "Polski", + "pt-PT" : "Portugu\u00eas (Europeu)", + "ru" : "\u0420\u0443\u0441\u0441\u043a\u0438\u0439", + "tr" : "T\u00fcrk\u00e7e", + "vi" : "Ti\u1ebfng Vi\u1ec7t", + "zh-CN" : "\u7b80\u4f53\u5b57" + }; + + // Retrieve the current locale so we can select it within the list by default. + let curLocale; try { let chromeRegSvc = Cc["@mozilla.org/chrome/chrome-registry;1"] .getService(Ci.nsIXULChromeRegistry); - let curLocale = chromeRegSvc.getSelectedLocale("global").toLowerCase(); - let localeList = document.getElementById(kLocaleList); - for (let i = 0; i < localeList.itemCount; ++i) + curLocale = chromeRegSvc.getSelectedLocale("global").toLowerCase(); + } catch (e) {} + + // Build a list of language info objects (language code plus friendly name). + let foundCurLocale = false; + let langInfo = []; + for (let addon of aLangPackAddons) + { + let uri = addon.getResourceURI(""); + // The add-on IDs look like langpack-LANGCODE(a)firefox.mozilla.org + let matchResult = addon.id.match(/^langpack-(.*)@.*\.mozilla\.org/); + let code = (matchResult) ? matchResult[1] : addon.id; + if (code == "ja-JP-mac") + code = "ja"; + let name = knownLanguages[code]; + if (!name) { - let item = localeList.getItemAtIndex(i); - if (item.value.toLowerCase() == curLocale) - { - localeList.selectedIndex = i; - break; - } + // We do not have a name for this language pack. Use some heuristics. + name = addon.name; + let idx = name.lastIndexOf(" Language Pack"); + if (idx > 0) + name = name.substring(0, idx); } - } catch (e) {} + let isSelected = (curLocale && (code.toLowerCase() == curLocale)); + langInfo.push({ langCode: code, langName: name, isSelected: isSelected } ); + if (isSelected && !foundCurLocale) + foundCurLocale = true; + } - resizeDialogToFitContent(); + // Sort by language code. + langInfo.sort(function(aObj1, aObj2) { + if (aObj1.langCode == aObj2.langCode) + return 0; + + return (aObj1.langCode < aObj2.langCode) ? -1 : 1; + }); - TorLauncherLogger.log(2, "initLocaleDialog done"); + // Add en-US to the beginning of the list. + let code = "en-US"; + let name = knownLanguages[code]; + let isSelected = !foundCurLocale; // select English if nothing else matched + langInfo.splice(0, 0, + { langCode: code, langName: name, isSelected: isSelected }); + + // Populate the XUL listbox. + let localeList = document.getElementById(kLocaleList); + for (let infoObj of langInfo) + { + let listItem = document.createElement("listitem"); + listItem.setAttribute("value", infoObj.langCode); + listItem.setAttribute("label", infoObj.langName); + localeList.appendChild(listItem); + if (infoObj.isSelected) + localeList.selectedItem = listItem; + } }

1 0

[translation/tor-messenger-authproperties_completed] Update translations for tor-messenger-authproperties_completed
by translation＠torproject.org 20 Nov '15

20 Nov '15

commit d2e3703383a09e47906f0fc0571e01b3b5be4fa7 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 20 20:16:15 2015 +0000 Update translations for tor-messenger-authproperties_completed --- ar/auth.properties | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/ar/auth.properties b/ar/auth.properties new file mode 100644 index 0000000..dd4a21f --- /dev/null +++ b/ar/auth.properties @@ -0,0 +1,12 @@ +auth.title=مصادقة هوية S's% +auth.yourFingerprint=بصمتك، %S:\n%S +auth.theirFingerprint=البصمة المزعومة لـ %S:\n%S +auth.help=مصادقة جهة إتصال معينة تساعدك علي التأكد من أن الشخص المراد التحدث معه هو بفعل وليس محتال. +auth.helpTitle=مساعدة التصادق +auth.question=مساعدة التصادقهذا هو السؤال الذي يطرحه جهة الإتصال:\n\n%S\n\nأدخل الحل هنا (الحروف يجب أن تكون كما هي): +auth.secret=أدخل السر هنا: +auth.error=حدث خطأ أثناء المصادقة. +auth.success=تمت المصادقة بنجاح. +auth.successThem=تمت عملية المصادقة بنجاح مع صديقك. يستحسن أن ترسل له سؤال مختلف حتي يجاوب عليه وتصادقه. +auth.fail=عملية المصادقة فشلت. +auth.done=تم

1 0

[translation/tor-messenger-authproperties] Update translations for tor-messenger-authproperties
by translation＠torproject.org 20 Nov '15

20 Nov '15

commit 684321bf53c56db109ffeb1f0bc35720fa99b8c9 Author: Translation commit bot <translation(a)torproject.org> Date: Fri Nov 20 20:16:10 2015 +0000 Update translations for tor-messenger-authproperties --- ar/auth.properties | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ar/auth.properties b/ar/auth.properties index 268fc6b..dd4a21f 100644 --- a/ar/auth.properties +++ b/ar/auth.properties @@ -1,4 +1,4 @@ -auth.title=Verify %S's identity +auth.title=مصادقة هوية S's% auth.yourFingerprint=بصمتك، %S:\n%S auth.theirFingerprint=البصمة المزعومة لـ %S:\n%S auth.help=مصادقة جهة إتصال معينة تساعدك علي التأكد من أن الشخص المراد التحدث معه هو بفعل وليس محتال.

1 0

[webwml/staging] Fix donate redirect rules
by sebastian＠torproject.org 20 Nov '15

20 Nov '15

commit ac94eb4d8356daf484b7f925cd2d5d7e2d472d7d Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 20 17:42:16 2015 +0100 Fix donate redirect rules --- .htaccess | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/.htaccess b/.htaccess index 1b40159..a051529 100644 --- a/.htaccess +++ b/.htaccess @@ -52,8 +52,9 @@ RewriteRule ^easy-download(.*) /download/download-easy$1 [R=301,L] RewriteRule ^relays(.*) /getinvolved/relays [R=301,L] # Donation campagin -RewriteRule ^donate-twitter(.*) /donate/donate$1 [R=302,L] -RewriteRule ^donate-hp(.*) /donate/donate$1 [R=302,L] -RewriteRule ^donate-tbb(.*) /donate/donate$1 [R=302,L] -RewriteRule ^donate-banner(.*) /donate/donate$1 [R=302,L] -RewriteRule ^donate-download(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-twitter(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-hp(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-tbb(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-banner(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-download(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate/donate-button(.*) /donate/donate$1 [R=302,L]

1 0

[webwml/staging] One more redirect page
by sebastian＠torproject.org 20 Nov '15

20 Nov '15

commit 3e3228912f9e0644ce1daed0f3450779dc9c61ea Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 20 17:25:01 2015 +0100 One more redirect page --- 0 files changed diff --git a/donate/en/donate-button.wml b/donate/en/donate-button.wml new file mode 100644 index 0000000..e69de29

1 0

[webwml/staging] Try the donation redirect hack
by sebastian＠torproject.org 20 Nov '15

20 Nov '15

commit 1c3f8602692fd0baea1b335c83b3a0b31ce255df Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Fri Nov 20 17:13:31 2015 +0100 Try the donation redirect hack --- .htaccess | 7 +++++++ en/navigation.wmi | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/.htaccess b/.htaccess index 6cdca66..1b40159 100644 --- a/.htaccess +++ b/.htaccess @@ -50,3 +50,10 @@ RewriteRule ^easy-download(.*) /download/download-easy$1 [R=301,L] # Relays RewriteRule ^relays(.*) /getinvolved/relays [R=301,L] + +# Donation campagin +RewriteRule ^donate-twitter(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate-hp(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate-tbb(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate-banner(.*) /donate/donate$1 [R=302,L] +RewriteRule ^donate-download(.*) /donate/donate$1 [R=302,L] diff --git a/donate/en/donate-banner.wml b/donate/en/donate-banner.wml new file mode 100644 index 0000000..e69de29 diff --git a/donate/en/donate-download.wml b/donate/en/donate-download.wml new file mode 100644 index 0000000..e69de29 diff --git a/donate/en/donate-hp.wml b/donate/en/donate-hp.wml new file mode 100644 index 0000000..e69de29 diff --git a/donate/en/donate-tbb.wml b/donate/en/donate-tbb.wml new file mode 100644 index 0000000..e69de29 diff --git a/donate/en/donate-twitter.wml b/donate/en/donate-twitter.wml new file mode 100644 index 0000000..e69de29 diff --git a/en/navigation.wmi b/en/navigation.wmi index ce8b001..504f29d 100644 --- a/en/navigation.wmi +++ b/en/navigation.wmi @@ -22,7 +22,7 @@ my @calltoaction = ( 'download/download-easy' , 'Download', 'getinvolved/volunteer' , 'Volunteer', - 'donate/donate' , 'Donate', + 'donate/donate-button' , 'Donate', ); :>

1 0

[tor/master] Refactor policies_parse_exit_policy_internal
by nickm＠torproject.org 20 Nov '15

20 Nov '15

commit c73c5a293f645c9d5a15b3f17946e4d44245a58e Author: teor (Tim Wilson-Brown) <teor2345(a)gmail.com> Date: Mon Nov 16 13:58:26 2015 +1100 Refactor policies_parse_exit_policy_internal Move the code that rejects publicly routable exit relay addresses to policies_parse_exit_policy_reject_private. Add addr_policy_append_reject_addr_list and use it to reject interface addresses. This removes the duplicate reject checks on local_address and ipv6_local_address, but duplicates will be removed by exit_policy_remove_redundancies at the end of the function. This also removes the info-level logging on rejected interface addresses. Instead, log a debug-level message in addr_policy_append_reject_addr. This simplifies policies_parse_exit_policy_internal and prepares for reporting these addresses over the control port in #17183. --- src/or/policies.c | 161 ++++++++++++++++++++++++++++++----------------------- src/or/policies.h | 7 +++ 2 files changed, 98 insertions(+), 70 deletions(-) diff --git a/src/or/policies.c b/src/or/policies.c index 9c858ec..f534632 100644 --- a/src/or/policies.c +++ b/src/or/policies.c @@ -893,6 +893,20 @@ addr_policy_append_reject_addr(smartlist_t **dest, const tor_addr_t *addr) if (!*dest) *dest = smartlist_new(); smartlist_add(*dest, add); + log_debug(LD_CONFIG, "Adding a reject ExitPolicy 'reject %s:*'", + fmt_addr(addr)); + +} + +/** Add "reject addr:*" to dest, for each addr in addrs, creating the + * list as needed. */ +void +addr_policy_append_reject_addr_list(smartlist_t **dest, + const smartlist_t *addrs) +{ + SMARTLIST_FOREACH_BEGIN(addrs, tor_addr_t *, addr) { + addr_policy_append_reject_addr(dest, addr); + } SMARTLIST_FOREACH_END(addr); } /** Detect and excise "dead code" from the policy *dest. */ @@ -979,6 +993,76 @@ exit_policy_remove_redundancies(smartlist_t *dest) } } +/** Reject private helper for policies_parse_exit_policy_internal: rejects + * publicly routable addresses on this exit relay. + * + * Add reject entries to the linked list *dest: + * - if local_address is non-zero, treat it as a host-order IPv4 address, + * and prepend an entry that rejects it as a destination. + * - if ipv6_local_address is non-NULL, prepend an entry that rejects it as + * a destination. + * - if reject_interface_addresses is true, prepend entries that reject each + * public IPv4 and IPv6 address of each interface on this machine. + * + * IPv6 entries are only added if ipv6_exit is true. (All IPv6 addresses are + * already blocked by policies_parse_exit_policy_internal if ipv6_exit is + * false.) + * + * The list *dest is created as needed. + */ +void +policies_parse_exit_policy_reject_private(smartlist_t **dest, + int ipv6_exit, + uint32_t local_address, + tor_addr_t *ipv6_local_address, + int reject_interface_addresses) +{ + tor_assert(dest); + + /* Reject our local IPv4 address */ + if (local_address) { + tor_addr_t v4_local; + tor_addr_from_ipv4h(&v4_local, local_address); + addr_policy_append_reject_addr(dest, &v4_local); + log_info(LD_CONFIG, "Adding a reject ExitPolicy 'reject %s:*' for our " + "published IPv4 address", fmt_addr32(local_address)); + } + + /* Reject our local IPv6 address */ + if (ipv6_exit && ipv6_local_address != NULL) { + if (tor_addr_is_v4(ipv6_local_address)) { + log_warn(LD_CONFIG, "IPv4 address '%s' provided as our IPv6 local " + "address", fmt_addr(ipv6_local_address)); + } else { + addr_policy_append_reject_addr(dest, ipv6_local_address); + log_info(LD_CONFIG, "Adding a reject ExitPolicy 'reject [%s]:*' for " + "our published IPv6 address", fmt_addr(ipv6_local_address)); + } + } + + /* Reject local addresses from public netblocks on any interface. */ + if (reject_interface_addresses) { + smartlist_t *public_addresses = NULL; + + /* Reject public IPv4 addresses on any interface */ + public_addresses = get_interface_address6_list(LOG_INFO, AF_INET, 0); + addr_policy_append_reject_addr_list(dest, public_addresses); + free_interface_address6_list(public_addresses); + + if (ipv6_exit) { + /* Reject public IPv6 addresses on any interface */ + public_addresses = get_interface_address6_list(LOG_INFO, AF_INET6, 0); + addr_policy_append_reject_addr_list(dest, public_addresses); + free_interface_address6_list(public_addresses); + } + } + + /* If addresses were added multiple times, remove all but one of them. */ + if (*dest) { + exit_policy_remove_redundancies(*dest); + } +} + #define DEFAULT_EXIT_POLICY \ "reject *:25,reject *:119,reject *:135-139,reject *:445," \ "reject *:563,reject *:1214,reject *:4661-4666," \ @@ -986,16 +1070,12 @@ exit_policy_remove_redundancies(smartlist_t *dest) /** Parse the exit policy cfg into the linked list *dest. * - * If ipv6_exit is true, prepend "reject *6:*" to the policy. + * If ipv6_exit is false, prepend "reject *6:*" to the policy. * * If rejectprivate is true: * - prepend "reject private:*" to the policy. - * - if local_address is non-zero, treat it as a host-order IPv4 address, - * and prepend an entry that rejects it as a destination. - * - if ipv6_local_address is non-NULL, prepend an entry that rejects it as - * a destination. - * - if reject_interface_addresses is true, prepend entries that reject each - * public IPv4 and IPv6 address of each interface on this machine. + * - call policies_parse_exit_policy_reject_private to reject publicly + * routable addresses on this exit relay * * If cfg doesn't end in an absolute accept or reject and if * add_default_policy is true, add the default exit @@ -1022,69 +1102,10 @@ policies_parse_exit_policy_internal(config_line_t *cfg, smartlist_t **dest, if (rejectprivate) { /* Reject IPv4 and IPv6 reserved private netblocks */ append_exit_policy_string(dest, "reject private:*"); - /* Reject our local IPv4 address */ - if (local_address) { - char buf[POLICY_BUF_LEN]; - tor_snprintf(buf, sizeof(buf), "reject %s:*", fmt_addr32(local_address)); - append_exit_policy_string(dest, buf); - log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for our published " - "IPv4 address", buf); - } - /* Reject our local IPv6 address */ - if (ipv6_exit && ipv6_local_address != NULL) { - if (tor_addr_is_v4(ipv6_local_address)) { - log_warn(LD_CONFIG, "IPv4 address '%s' provided as our IPv6 local " - "address", fmt_addr(ipv6_local_address)); - } else { - char buf6[POLICY_BUF_LEN]; - tor_snprintf(buf6, sizeof(buf6), "reject [%s]:*", - fmt_addr(ipv6_local_address)); - append_exit_policy_string(dest, buf6); - log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for our " - "published IPv6 address", buf6); - } - } - /* Reject local addresses from public netblocks on any interface, - * but don't reject our published addresses twice */ - if (reject_interface_addresses) { - smartlist_t *public_addresses = NULL; - char bufif[POLICY_BUF_LEN]; - - /* Reject public IPv4 addresses on any interface, - * but don't reject our published IPv4 address twice */ - public_addresses = get_interface_address6_list(LOG_INFO, AF_INET, 0); - SMARTLIST_FOREACH_BEGIN(public_addresses, tor_addr_t *, a) { - if (!tor_addr_eq_ipv4h(a, local_address)) { - tor_snprintf(bufif, sizeof(bufif), "reject %s:*", - fmt_addr(a)); - append_exit_policy_string(dest, bufif); - log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for a local " - "interface's public IPv4 address", bufif); - } - } SMARTLIST_FOREACH_END(a); - free_interface_address6_list(public_addresses); - - if (ipv6_exit) { - /* Reject public IPv6 addresses on any interface, - * but don't reject our published IPv6 address (if any) twice */ - public_addresses = get_interface_address6_list(LOG_INFO, AF_INET6, 0); - SMARTLIST_FOREACH_BEGIN(public_addresses, tor_addr_t *, a) { - /* if we don't have an IPv6 local address, we won't have rejected - * it above. This could happen if a future release does IPv6 - * autodiscovery, and we are waiting to discover our external IPv6 - * address */ - if (ipv6_local_address == NULL - || !tor_addr_eq(ipv6_local_address, a)) { - tor_snprintf(bufif, sizeof(bufif), "reject6 [%s]:*", - fmt_addr(a)); - append_exit_policy_string(dest, bufif); - log_info(LD_CONFIG, "Adding a reject ExitPolicy '%s' for a local " - "interface's public IPv6 address", bufif); - } - } SMARTLIST_FOREACH_END(a); - free_interface_address6_list(public_addresses); - } - } + /* Reject IPv4 and IPv6 publicly routable addresses on this exit relay */ + policies_parse_exit_policy_reject_private(dest, ipv6_exit, local_address, + ipv6_local_address, + reject_interface_addresses); } if (parse_addr_policy(cfg, dest, -1)) return -1; diff --git a/src/or/policies.h b/src/or/policies.h index f200d7b..97350f5 100644 --- a/src/or/policies.h +++ b/src/or/policies.h @@ -58,9 +58,16 @@ int policies_parse_exit_policy(config_line_t *cfg, smartlist_t **dest, uint32_t local_address, tor_addr_t *ipv6_local_address, int reject_interface_addresses); +void policies_parse_exit_policy_reject_private(smartlist_t **dest, + int ipv6_exit, + uint32_t local_address, + tor_addr_t *ipv6_local_address, + int reject_interface_addresses); void policies_exit_policy_append_reject_star(smartlist_t **dest); void addr_policy_append_reject_addr(smartlist_t **dest, const tor_addr_t *addr); +void addr_policy_append_reject_addr_list(smartlist_t **dest, + const smartlist_t *addrs); void policies_set_node_exitpolicy_to_reject_all(node_t *exitrouter); int exit_policy_is_general_exit(smartlist_t *policy); int policy_is_reject_star(const smartlist_t *policy, sa_family_t family);

1 0