tor-commits April 2014

tor-commits@lists.torproject.org

22 participants
2020 discussions

[orbot/master] update to 13.0.6-BETA-7
by n8fr8＠torproject.org 08 Apr '14

08 Apr '14

commit ed76f8b53b37f45500271c1becc8749d2aad3e2b Author: Nathan Freitas <nathan(a)freitas.net> Date: Tue Apr 8 16:10:10 2014 -0400 update to 13.0.6-BETA-7 --- AndroidManifest.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/AndroidManifest.xml b/AndroidManifest.xml index 1808815..a9afaba 100644 --- a/AndroidManifest.xml +++ b/AndroidManifest.xml @@ -1,8 +1,8 @@ <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="org.torproject.android" - android:versionName="13.0.6-BETA-6" - android:versionCode="76" + android:versionName="13.0.6-BETA-7" + android:versionCode="77" android:installLocation="auto" >

1 0

[tor/master] Merge branch 'bug2454_025_squashed'
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit 689863d0a9432250f2c9a67e3e7ba2c4e5dae4c6 Merge: b933fdc 2d5a7b1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 8 15:37:15 2014 -0400 Merge branch 'bug2454_025_squashed' changes/bug2454 | 6 ++++++ src/or/circuitstats.c | 12 +++++++++++- src/or/main.c | 13 ++++++++++++- src/or/main.h | 1 + 4 files changed, 30 insertions(+), 2 deletions(-)

1 0

[tor/master] Check for new IP addr after circuit liveliness returns
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit 2d5a7b1842b3dad522166659ff3a88e418f36d13 Author: Matthew Finkel <matthew.finkel(a)gmail.com> Date: Tue Apr 1 17:30:20 2014 -0400 Check for new IP addr after circuit liveliness returns When we successfully create a usable circuit after it previously timed out for a certain amount of time, we should make sure that our public IP address hasn't changed and update our descriptor. --- changes/bug2454 | 6 ++++++ src/or/circuitstats.c | 12 +++++++++++- src/or/main.c | 13 ++++++++++++- src/or/main.h | 1 + 4 files changed, 30 insertions(+), 2 deletions(-) diff --git a/changes/bug2454 b/changes/bug2454 new file mode 100644 index 0000000..18e327b --- /dev/null +++ b/changes/bug2454 @@ -0,0 +1,6 @@ + o Enhancement: + - If a circuit timed out for at least 3 minutes check if we have a new + external IP address the next time we run our routine checks. If our + IP address has changed, then publish a new descriptor with the new + IP address. Resolves ticket 2454. + diff --git a/src/or/circuitstats.c b/src/or/circuitstats.c index c093ecd..e362b1b 100644 --- a/src/or/circuitstats.c +++ b/src/or/circuitstats.c @@ -12,6 +12,7 @@ #include "config.h" #include "confparse.h" #include "control.h" +#include "main.h" #include "networkstatus.h" #include "statefile.h" @@ -1185,6 +1186,12 @@ circuit_build_times_needs_circuits_now(const circuit_build_times_t *cbt) } /** + * How long should we be unreachable before we think we need to check if + * our published IP address has changed. + */ +#define CIRCUIT_TIMEOUT_BEFORE_RECHECK_IP (60*3) + +/** * Called to indicate that the network showed some signs of liveness, * i.e. we received a cell. * @@ -1199,12 +1206,15 @@ circuit_build_times_network_is_live(circuit_build_times_t *cbt) { time_t now = approx_time(); if (cbt->liveness.nonlive_timeouts > 0) { + time_t time_since_live = now - cbt->liveness.network_last_live; log_notice(LD_CIRC, "Tor now sees network activity. Restoring circuit build " "timeout recording. Network was down for %d seconds " "during %d circuit attempts.", - (int)(now - cbt->liveness.network_last_live), + (int)time_since_live, cbt->liveness.nonlive_timeouts); + if (time_since_live > CIRCUIT_TIMEOUT_BEFORE_RECHECK_IP) + reschedule_descriptor_update_check(); } cbt->liveness.network_last_live = now; cbt->liveness.nonlive_timeouts = 0; diff --git a/src/or/main.c b/src/or/main.c index feca35c..86f3437 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -1162,6 +1162,18 @@ get_signewnym_epoch(void) return newnym_epoch; } +static time_t time_to_check_descriptor = 0; +/** + * Update our schedule so that we'll check whether we need to update our + * descriptor immediately, rather than after up to CHECK_DESCRIPTOR_INTERVAL + * seconds. + */ +void +reschedule_descriptor_update_check(void) +{ + time_to_check_descriptor = 0; +} + /** Perform regular maintenance tasks. This function gets run once per * second by second_elapsed_callback(). */ @@ -1171,7 +1183,6 @@ run_scheduled_events(time_t now) static time_t last_rotated_x509_certificate = 0; static time_t time_to_check_v3_certificate = 0; static time_t time_to_check_listeners = 0; - static time_t time_to_check_descriptor = 0; static time_t time_to_download_networkstatus = 0; static time_t time_to_shrink_memory = 0; static time_t time_to_try_getting_descriptors = 0; diff --git a/src/or/main.h b/src/or/main.h index df302ff..a2f03d9 100644 --- a/src/or/main.h +++ b/src/or/main.h @@ -50,6 +50,7 @@ void directory_info_has_arrived(time_t now, int from_cache); void ip_address_changed(int at_interface); void dns_servers_relaunch_checks(void); +void reschedule_descriptor_update_check(void); long get_uptime(void); unsigned get_signewnym_epoch(void);

1 0

[torspec/master] Proposal 231: Migrating authority RSA1024 identity keys
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit df51057a3f437ca69df026c0da66a3e280bb44e8 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 8 15:20:27 2014 -0400 Proposal 231: Migrating authority RSA1024 identity keys --- proposals/000-index.txt | 2 + proposals/231-migrate-authority-rsa1024-ids.txt | 68 +++++++++++++++++++++++ 2 files changed, 70 insertions(+) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 4e74fed..bec7a14 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -151,6 +151,7 @@ Proposals by number: 228 Cross-certifying identity keys with onion keys [OPEN] 229 Further SOCKS5 extensions [DRAFT] 230 How to change RSA1024 relay identity keys [DRAFT] +231 Migrating authority RSA1024 identity keys [DRAFT] Proposals by status: @@ -171,6 +172,7 @@ Proposals by status: 225 Strawman proposal: commit-and-reveal shared rng 229 Further SOCKS5 extensions 230 How to change RSA1024 relay identity keys [for 0.2.?] + 231 Migrating authority RSA1024 identity keys [for 0.2.?] NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret diff --git a/proposals/231-migrate-authority-rsa1024-ids.txt b/proposals/231-migrate-authority-rsa1024-ids.txt new file mode 100644 index 0000000..88c78e1 --- /dev/null +++ b/proposals/231-migrate-authority-rsa1024-ids.txt @@ -0,0 +1,68 @@ +Filename: 231-migrate-authority-rsa1024-ids.txt +Title: Migrating authority RSA1024 identity keys +Authors: Nick Mathewson +Created: 8 April 2014 +Target: 0.2.? +Status: Draft + +1. Intro and motivation + + We'd like for RSA1024 identity keys to die out entirely. But we + may need to migrate authority identity keys before that happens. + + This is especially important because proposal 220 ("Migrate + server identity keys to Ed25519") is not yet implemented, and so + server identity keys are not kept offline. So when an OpenSSL + bug like CVE-2014-0160 makes memory-reading attacks a threat to + identity keys, we need a way for authorities to migrate ASAP. + + Migrating authority ID keys is a trickier problem than migrating + router ID keys, since the authority RSA1024 keys are hardwired in the + source. We use them to authenticate encrypted OR connections to + authorities that we use to publish and retrieve directory + information. + + This proposal does not cover migrating RSA1024 OR identity keys for + other nodes; for that, see proposal 230. + +2. Design + + When an authority is using a new RSA1024 key, it retains the old one + in a "legacy_link_id_key" file. It uses this key to perform link + protocol handshakes at its old address:port, and it uses the new key + to perform link protocol handshakes at a new address:port. + + This should be sufficient for all clients that expect the old + address:port:fingerprint to work, while allowing new clients to use + the correct address:port:fingerprint. + + Authorities will sign their own router descriptors with their new + identity key, and won't advertise the old port or fingerprint at all + in their descriptors. This shouldn't break anything, so far as I + know. + +3. Implementation + + We'll have a new flag on an ORPort: "LegacyIDKey". It implies + NoAdvertise. If it is present, we use our LegacyIDKey for that + ORPort and that ORPort, for all of: + + * The TLS certificate chains used in the v1 and v2 link protocol + handshake. + + * The certificate chains and declared identity in the v3 link + handshake. + + * Accepting ntor cells. + +4. Open questions + + On ticket #11448, Robert Ransom suggests that authorities may need to + publish extra server descriptors for themselves, signed with the old + identity key too. We should investigate whether clients will + misbehave if they can't find such descriptors. + + If that's the case, authorities should generate these descriptors, + but not include them in votes or the consensus; or if they are + included, don't assign them flags that will get them used. +

1 0

[torspec/master] Draft proposal for how to migrate a bunch of router identity keys
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit ea5677f354a55d4a4b389b65045c60531cbcbab3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 7 19:02:53 2014 -0400 Draft proposal for how to migrate a bunch of router identity keys We might decide to do this as part of a CVE-2014-0160 response. --- proposals/xxx-rsa1024-relay-id-migration.txt | 83 ++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt new file mode 100644 index 0000000..30419c0 --- /dev/null +++ b/proposals/xxx-rsa1024-relay-id-migration.txt @@ -0,0 +1,83 @@ +Filename: xxx-rsa1024-relay-id-maigration.txt +Title: How to change RSA1024 relay identity keys +Authors: Nick Mathewson +Created: 7 April 2014 +Target: 0.2.? +Status: Draft + +1. Intro and motivation + + Some times, a relay would like to migrate from one RSA1024 + identity key to another without losing its previous status. + + This is especially important because proposal 220 ("Migrate + server identity keys to Ed25519") is not yet implemented, and so + server identity keys are not kept offline. So when an OpenSSL + bug like CVE-2014-0160 makes memory-reading attacks a threat to + identity keys, we need a way for routers to migrate ASAP. + + This proposal does not cover migrating RSA1024 OR identity keys + for authorities. + +2. Design + + I propose that when a relay changes its identity key, it should + include a "old-identity" field in its server descriptor for 60 days + after the migration. This old-identity would include the + old RSA1024 identity, a signature of the new identity key + with the old one, and the date when the migration occurred. + + This field would appear as an "old-id" field in microdescriptors, + containin a SHA1 fingerprint of the old identity key, if the + signature turned out to be value. + + Authorities would store old-identity => new-identity mappings, + and: + + * Treat history information (wfu, mtbf, [and what else?]) from + old identities as applying to new identities instead. + + * No longer accept any routers descriptors signed by the old + identity. + + Clients would migrate any guard entries for the old identity to + the new identity. + + (This will break clients connections for clients who try to + connect to the old identity key before learning about the new + one, but the window there won't be large for any single router.) + +3. Descriptor format details + + Router descriptors may contain these new elements: + + "old-rsa1024-id-key" NL RSA_KEY NL + + Contains an old RSA1024 identity key. If this appears, + old-rsa1024-id-migration must also appear. [At most once] + + "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL + + Contains a signature of: + The bytes "RSA1024 ID MIGRATION" [20 bytes] + The ISO-TIME field above as an 8 byte field [8 bytes] + A SHA256 hash of the new identity [32 bytes] + + If this appears, "old-rsa1024-id-key" must also appear. + [At most once]. + +4. Interface + + To use this feature, a router should rename its secret_id_key + file to secret_id_key_OLD. The first time that Tor starts and + finds a secret_id_key_OLD file, it generates a new ID key if one + is not present, and generates the text of the old-rsa-1024-id-key + and old-rsa1024-id-migration fields above. It stores them in a + new "old_id_key_migration" file, and deletes the + secret_id_key_OLD file. It includes them in its desecriptors. + + Sixty days after the stored timestamp, the router deletes the + "old_id_key_migration" file and stops including its contents in + the descriptor. + +

1 0

[torspec/master] spelling
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit 663401c9bc6e2ff7d1d55dead60bb3714a5476aa Author: Nick Mathewson <nickm(a)torproject.org> Date: Mon Apr 7 22:22:19 2014 -0400 spelling --- proposals/xxx-rsa1024-relay-id-migration.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt index 30419c0..45166f0 100644 --- a/proposals/xxx-rsa1024-relay-id-migration.txt +++ b/proposals/xxx-rsa1024-relay-id-migration.txt @@ -28,7 +28,7 @@ Status: Draft with the old one, and the date when the migration occurred. This field would appear as an "old-id" field in microdescriptors, - containin a SHA1 fingerprint of the old identity key, if the + containing a SHA1 fingerprint of the old identity key, if the signature turned out to be value. Authorities would store old-identity => new-identity mappings,

1 0

[torspec/master] Give the rsa1024-relay-id-migration.txt proposal a number
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit 8bc6db6a9f8ac4eb3d85cfe574653b1ef8f255d3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 8 14:44:33 2014 -0400 Give the rsa1024-relay-id-migration.txt proposal a number --- proposals/230-rsa1024-relay-id-migration.txt | 83 ++++++++++++++++++++++++++ proposals/xxx-rsa1024-relay-id-migration.txt | 83 -------------------------- 2 files changed, 83 insertions(+), 83 deletions(-) diff --git a/proposals/230-rsa1024-relay-id-migration.txt b/proposals/230-rsa1024-relay-id-migration.txt new file mode 100644 index 0000000..d2f3aff --- /dev/null +++ b/proposals/230-rsa1024-relay-id-migration.txt @@ -0,0 +1,83 @@ +Filename: 230-rsa1024-relay-id-maigration.txt +Title: How to change RSA1024 relay identity keys +Authors: Nick Mathewson +Created: 7 April 2014 +Target: 0.2.? +Status: Draft + +1. Intro and motivation + + Some times, a relay would like to migrate from one RSA1024 + identity key to another without losing its previous status. + + This is especially important because proposal 220 ("Migrate + server identity keys to Ed25519") is not yet implemented, and so + server identity keys are not kept offline. So when an OpenSSL + bug like CVE-2014-0160 makes memory-reading attacks a threat to + identity keys, we need a way for routers to migrate ASAP. + + This proposal does not cover migrating RSA1024 OR identity keys + for authorities. + +2. Design + + I propose that when a relay changes its identity key, it should + include a "old-identity" field in its server descriptor for 60 days + after the migration. This old-identity would include the + old RSA1024 identity, a signature of the new identity key + with the old one, and the date when the migration occurred. + + This field would appear as an "old-id" field in microdescriptors, + containing a SHA1 fingerprint of the old identity key, if the + signature turned out to be value. + + Authorities would store old-identity => new-identity mappings, + and: + + * Treat history information (wfu, mtbf, [and what else?]) from + old identities as applying to new identities instead. + + * No longer accept any routers descriptors signed by the old + identity. + + Clients would migrate any guard entries for the old identity to + the new identity. + + (This will break clients connections for clients who try to + connect to the old identity key before learning about the new + one, but the window there won't be large for any single router.) + +3. Descriptor format details + + Router descriptors may contain these new elements: + + "old-rsa1024-id-key" NL RSA_KEY NL + + Contains an old RSA1024 identity key. If this appears, + old-rsa1024-id-migration must also appear. [At most once] + + "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL + + Contains a signature of: + The bytes "RSA1024 ID MIGRATION" [20 bytes] + The ISO-TIME field above as an 8 byte field [8 bytes] + A SHA256 hash of the new identity [32 bytes] + + If this appears, "old-rsa1024-id-key" must also appear. + [At most once]. + +4. Interface + + To use this feature, a router should rename its secret_id_key + file to secret_id_key_OLD. The first time that Tor starts and + finds a secret_id_key_OLD file, it generates a new ID key if one + is not present, and generates the text of the old-rsa-1024-id-key + and old-rsa1024-id-migration fields above. It stores them in a + new "old_id_key_migration" file, and deletes the + secret_id_key_OLD file. It includes them in its desecriptors. + + Sixty days after the stored timestamp, the router deletes the + "old_id_key_migration" file and stops including its contents in + the descriptor. + + diff --git a/proposals/xxx-rsa1024-relay-id-migration.txt b/proposals/xxx-rsa1024-relay-id-migration.txt deleted file mode 100644 index 45166f0..0000000 --- a/proposals/xxx-rsa1024-relay-id-migration.txt +++ /dev/null @@ -1,83 +0,0 @@ -Filename: xxx-rsa1024-relay-id-maigration.txt -Title: How to change RSA1024 relay identity keys -Authors: Nick Mathewson -Created: 7 April 2014 -Target: 0.2.? -Status: Draft - -1. Intro and motivation - - Some times, a relay would like to migrate from one RSA1024 - identity key to another without losing its previous status. - - This is especially important because proposal 220 ("Migrate - server identity keys to Ed25519") is not yet implemented, and so - server identity keys are not kept offline. So when an OpenSSL - bug like CVE-2014-0160 makes memory-reading attacks a threat to - identity keys, we need a way for routers to migrate ASAP. - - This proposal does not cover migrating RSA1024 OR identity keys - for authorities. - -2. Design - - I propose that when a relay changes its identity key, it should - include a "old-identity" field in its server descriptor for 60 days - after the migration. This old-identity would include the - old RSA1024 identity, a signature of the new identity key - with the old one, and the date when the migration occurred. - - This field would appear as an "old-id" field in microdescriptors, - containing a SHA1 fingerprint of the old identity key, if the - signature turned out to be value. - - Authorities would store old-identity => new-identity mappings, - and: - - * Treat history information (wfu, mtbf, [and what else?]) from - old identities as applying to new identities instead. - - * No longer accept any routers descriptors signed by the old - identity. - - Clients would migrate any guard entries for the old identity to - the new identity. - - (This will break clients connections for clients who try to - connect to the old identity key before learning about the new - one, but the window there won't be large for any single router.) - -3. Descriptor format details - - Router descriptors may contain these new elements: - - "old-rsa1024-id-key" NL RSA_KEY NL - - Contains an old RSA1024 identity key. If this appears, - old-rsa1024-id-migration must also appear. [At most once] - - "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL - - Contains a signature of: - The bytes "RSA1024 ID MIGRATION" [20 bytes] - The ISO-TIME field above as an 8 byte field [8 bytes] - A SHA256 hash of the new identity [32 bytes] - - If this appears, "old-rsa1024-id-key" must also appear. - [At most once]. - -4. Interface - - To use this feature, a router should rename its secret_id_key - file to secret_id_key_OLD. The first time that Tor starts and - finds a secret_id_key_OLD file, it generates a new ID key if one - is not present, and generates the text of the old-rsa-1024-id-key - and old-rsa1024-id-migration fields above. It stores them in a - new "old_id_key_migration" file, and deletes the - secret_id_key_OLD file. It includes them in its desecriptors. - - Sixty days after the stored timestamp, the router deletes the - "old_id_key_migration" file and stops including its contents in - the descriptor. - -

1 0

[torspec/master] Merge branch 'rsa1024_migrate'
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit 42b4c0d96098167924dcf4694fcbdb68cd24e5dd Merge: 42b373a 8bc6db6 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 8 14:45:06 2014 -0400 Merge branch 'rsa1024_migrate' proposals/230-rsa1024-relay-id-migration.txt | 83 ++++++++++++++++++++++++++ 1 file changed, 83 insertions(+)

1 0

[torspec/master] fix typo and reindex
by nickm＠torproject.org 08 Apr '14

08 Apr '14

commit ce5420d0afe0062a0cd561069b0d0e324b6ca9e1 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Apr 8 14:47:37 2014 -0400 fix typo and reindex --- proposals/000-index.txt | 2 ++ proposals/230-rsa1024-relay-id-migration.txt | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index a7a4287..4e74fed 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -150,6 +150,7 @@ Proposals by number: 227 Include package fingerprints in consensus documents [OPEN] 228 Cross-certifying identity keys with onion keys [OPEN] 229 Further SOCKS5 extensions [DRAFT] +230 How to change RSA1024 relay identity keys [DRAFT] Proposals by status: @@ -169,6 +170,7 @@ Proposals by status: 224 Next-Generation Hidden Services in Tor 225 Strawman proposal: commit-and-reveal shared rng 229 Further SOCKS5 extensions + 230 How to change RSA1024 relay identity keys [for 0.2.?] NEEDS-REVISION: 131 Help users to verify they are using Tor 190 Bridge Client Authorization Based on a Shared Secret diff --git a/proposals/230-rsa1024-relay-id-migration.txt b/proposals/230-rsa1024-relay-id-migration.txt index d2f3aff..efdbdff 100644 --- a/proposals/230-rsa1024-relay-id-migration.txt +++ b/proposals/230-rsa1024-relay-id-migration.txt @@ -1,4 +1,4 @@ -Filename: 230-rsa1024-relay-id-maigration.txt +Filename: 230-rsa1024-relay-id-migration.txt Title: How to change RSA1024 relay identity keys Authors: Nick Mathewson Created: 7 April 2014

1 0

[translation/tor-launcher-properties_completed] Update translations for tor-launcher-properties_completed
by translation＠torproject.org 08 Apr '14

08 Apr '14

commit 4077d2b18bca51c2f6035f8a6af173a23866af55 Author: Translation commit bot <translation(a)torproject.org> Date: Tue Apr 8 18:45:36 2014 +0000 Update translations for tor-launcher-properties_completed --- da/torlauncher.properties | 1 + 1 file changed, 1 insertion(+) diff --git a/da/torlauncher.properties b/da/torlauncher.properties index 06e2988..143d876 100644 --- a/da/torlauncher.properties +++ b/da/torlauncher.properties @@ -55,3 +55,4 @@ torlauncher.bootstrapWarning.identity=identitet matcher ikke torlauncher.bootstrapWarning.timeout=forbindelse timeout torlauncher.bootstrapWarning.noroute=ingen rute til vært torlauncher.bootstrapWarning.ioerror=læs/skriv fejl +torlauncher.bootstrapWarning.pt_missing=mangler udskiftelig transport

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2014