[TWN team] Recent changes to the wiki pages
Lunar
lunar at torproject.org
Tue Apr 15 11:20:08 UTC 2014
===========================================================================
=== https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews/2014/15 ===
===========================================================================
version 32
Author: lunar
Date: 2014-04-15T10:42:02+00:00
write about meek bundles
--- version 31
+++ version 32
@@ -140,6 +140,15 @@
[XXX]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032642.html
+David Fifield released new browser bundles configured to use the meek [XXX]
+transport automatically. These bundles “use a web browser extension to make the
+HTTPS requests, so that the TLS layer looks like Firefox” — because it is
+Firefox [XXX]. Meek is a promising censorship circumvention solution, so please
+try them!
+
+ [XXX]: https://lists.torproject.org/pipermail/tor-qa/2014-April/000390.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006662.html
+
The Tails developers announced [XXX] that Tchou’s proposal is the winner
of the recent Tails logo contest: “in the coming days we will keep on
fine-tuning it and integrating it in time for Tails 1.0. So don't
@@ -230,7 +239,3 @@
[XXX]: https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews
[XXX]: https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team
}}}
-
-Possible items:
-
- * How to run a headless second Firefox instance? https://lists.torproject.org/pipermail/tor-dev/2014-April/006662.html
version 31
Author: lunar
Date: 2014-04-15T10:34:55+00:00
reorder misc items
--- version 30
+++ version 31
@@ -134,18 +134,18 @@
Miscellaneous news
------------------
+CVE-2014-0160 prompted Anthony Basile to release version 20140409 [XXX] of
+Tor-ramdisk. OpenSSL has been updated and so was the kernel. Upgrading is
+strongly recommended.
+
+ [XXX]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032642.html
+
The Tails developers announced [XXX] that Tchou’s proposal is the winner
of the recent Tails logo contest: “in the coming days we will keep on
fine-tuning it and integrating it in time for Tails 1.0. So don't
hesitate to comment on it.”
[XXX]: https://tails.boum.org/news/and_the_winner_is/
-
-CVE-2014-0160 prompted Anthony Basile to release version 20140409 [XXX] of
-Tor-ramdisk. OpenSSL has been updated and so was the kernel. Upgrading is
-strongly recommended.
-
- [XXX]: https://lists.torproject.org/pipermail/tor-talk/2014-April/032642.html
Andrew Lewman reported on his week in Stockholm [XXX] for the Civil Rights
Defender’s [XXX] Defender’s Days where he trained activists and “learned more
version 30
Author: lunar
Date: 2014-04-15T10:31:12+00:00
remove item: at least wait for the outcome of the discussion, it feels
too internal to be relevant
--- version 29
+++ version 30
@@ -234,4 +234,3 @@
Possible items:
* How to run a headless second Firefox instance? https://lists.torproject.org/pipermail/tor-dev/2014-April/006662.html
- * TBB versions file https://lists.torproject.org/pipermail/tbb-dev/2014-April/000045.html
version 29
Author: lunar
Date: 2014-04-15T10:19:00+00:00
fix links
--- version 28
+++ version 29
@@ -41,16 +41,16 @@
The “Heartbleed” issue forces system administrators to consider private
keys of network facing application affected by the bug as compromised.
-As Tor has no shortage of private keys in its design [XXX], a serious amount
-of new keys have to be generated.
+As Tor has no shortage of private keys in its design [XXX], a serious
+amount of new keys have to be generated.
Roger Dingledine prompted relay operators to get new identity keys,
“especially from the big relays, and we'll be happier tolerating a
-couple of bumpy days while the network recovers.” [XXX]. Switching
-to a new relay identity key means that the relay is seen as new [XXX] to
-the authorities again: they will loose their Guard status and bandwidth
-measurement. It seems that a number of operators followed the advice,
-as the network lost around 1 Gbit/s of advertised capacity between April
+couple of bumpy days while the network recovers.” [XXX]. Switching to a
+new relay identity key means that the relay is seen as new [XXX] to the
+authorities again: they will loose their Guard status and bandwidth
+measurement. It seems that a number of operators followed the advice, as
+the network lost around 1 Gbit/s of advertised capacity between April
7th and April 10th [XXX].
For a brighter future if such massive RSA1024 relay key migration was in
@@ -59,12 +59,12 @@
authorities and clients.
Directory authorities can currently tie relay's nickname to its identity
-key with the Named flag. That feature proven to be less helpful than
-it seemed and can subject its users to impersonation attacks. As relays
+key with the Named flag. That feature proven to be less helpful than it
+seemed and can subject its users to impersonation attacks. As relays
switch to new identity key, those who keep the same name will loose
their Named flag for the next six months. So now seems a good time to
-“throw out the Named and Unnamed flags entirely” [XXX]. Sebsatian
-Hahn acted on the idea and started a draft proposal [XXX].
+“throw out the Named and Unnamed flags entirely” [XXX]. Sebsatian Hahn
+acted on the idea and started a draft proposal [XXX].
How should potentially compromised relays which have not switched to a
new key be handled? On April 8th, grarpamp observed [XXX] that more than
@@ -73,25 +73,25 @@
key since. Andrea Shepard has been working on a survey [XXX] to identify
them. What is known though are relays that are unfortunately still
vulnerable. Sina Rabbani has set up a visible list for guards and
-exits [XXX]. To protect Tor users, directory authority operators
-have started to remove the Valid flag for vulnerable relays (XXX --
-Roger owes a mail about this).
-
-The identity key for directory authorities are kept offline. But they are
-used to certify medium-term signing keys. Roger Dingledine's analysis reports
-“two (moria1 and urras) of the directory authorities were unaffected by the
-openssl bug, and seven were affected”.
+exits [XXX]. To protect Tor users, directory authority operators have
+started to remove the Valid flag for vulnerable relays [XXX].
+
+The identity key for directory authorities are kept offline. But they
+are used to certify medium-term signing keys. Roger Dingledine's
+analysis [XXX] reports “two (moria1 and urras) of the directory
+authorities were unaffected by the openssl bug, and seven were
+affected”.
At the time of writing, five of the seven affected authorities got new
signing keys. In the meantime, Nick and Andrea have been busy writing
code to prevent the old keys from being accepted by Tor clients [XXX].
-Changing the relay identity keys of the directory authorities has not been
-do so far “because current clients expect them to be at their current
-IP:port:fingerprint and would scream in their logs and refuse to connect if the
-relay identity key changes”. The specification of the missing piece of code
-to allow a smoother transition has been written by Nick Mathewson in
-proposal 231 [XXX].
+Changing the relay identity keys of the directory authorities has not
+been do so far “because current clients expect them to be at their
+current IP:port:fingerprint and would scream in their logs and refuse to
+connect if the relay identity key changes”. The specification of the
+missing piece of code to allow a smoother transition has been written by
+Nick Mathewson in proposal 231 [XXX].
Finally, hidden service operators are also generating new keys [XXX].
Unfortunately, this forces every users of the service to update the
@@ -103,15 +103,16 @@
[XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004256.html
[XXX]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
[XXX]: https://metrics.torproject.org/network.html?graph=bandwidth&start=2014-04-01&end=2014-04-15#bandwidth
- [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004259.html
- [XXX]: https://encrypted.redteam.net/bleeding_edges/
- [XXX]: http://charon.persephoneslair.org/~andrea/private/tor-heartbleed-survey/
[XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/230-rsa1024-relay-id-migration.txt
[XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004254.html
[XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006671.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004259.html
+ [XXX]: http://charon.persephoneslair.org/~andrea/private/tor-heartbleed-survey/
+ [XXX]: https://encrypted.redteam.net/bleeding_edges/
+ [XXX]: (XXX -- Roger owes a mail about this ; plan B is to link to consusus-health).
[XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html
- [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006660.html
[XXX]: https://bugs.torproject.org/11464
+ [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/231-migrate-authority-rsa1024-ids.txt
[XXX]: https://twitter.com/freenodestaff/status/455425032203022337
Monthly status reports for March 2014
version 28
Author: lunar
Date: 2014-04-15T10:10:35+00:00
finish writing about key rotation
--- version 27
+++ version 28
@@ -77,15 +77,25 @@
have started to remove the Valid flag for vulnerable relays (XXX --
Roger owes a mail about this).
-
-dirauths
- * Implications of openssl bug on directory authorities https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html
- * Proposal 231: Migrating authority RSA1024 identity keys https://lists.torproject.org/pipermail/tor-dev/2014-April/006660.html
-
-hidden services are changing names…
-https://twitter.com/freenodestaff/status/455425032203022337
-
-XXXXXXXXX will continue later — Lunar
+The identity key for directory authorities are kept offline. But they are
+used to certify medium-term signing keys. Roger Dingledine's analysis reports
+“two (moria1 and urras) of the directory authorities were unaffected by the
+openssl bug, and seven were affected”.
+
+At the time of writing, five of the seven affected authorities got new
+signing keys. In the meantime, Nick and Andrea have been busy writing
+code to prevent the old keys from being accepted by Tor clients [XXX].
+
+Changing the relay identity keys of the directory authorities has not been
+do so far “because current clients expect them to be at their current
+IP:port:fingerprint and would scream in their logs and refuse to connect if the
+relay identity key changes”. The specification of the missing piece of code
+to allow a smoother transition has been written by Nick Mathewson in
+proposal 231 [XXX].
+
+Finally, hidden service operators are also generating new keys [XXX].
+Unfortunately, this forces every users of the service to update the
+address in their bookmarks or configuration.
As Roger summarized it: “fun times”.
@@ -99,6 +109,10 @@
[XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/230-rsa1024-relay-id-migration.txt
[XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004254.html
[XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006671.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006660.html
+ [XXX]: https://bugs.torproject.org/11464
+ [XXX]: https://twitter.com/freenodestaff/status/455425032203022337
Monthly status reports for March 2014
-------------------------------------
version 27
Author: lunar
Date: 2014-04-15T09:43:00+00:00
write more about keys
--- version 26
+++ version 27
@@ -41,30 +41,64 @@
The “Heartbleed” issue forces system administrators to consider private
keys of network facing application affected by the bug as compromised.
-As Tor has no shortage of private keys in its design, a serious amount
+As Tor has no shortage of private keys in its design [XXX], a serious amount
of new keys have to be generated.
-Relay operators have…
-“I think we probably want new identity keys asap, *especially* from the
-big relays, and we'll be happier tolerating a couple of bumpy days while
-the network recovers.”
-“Fun times”
-https://lists.torproject.org/pipermail/tor-relays/2014-April/004256.html
-https://lists.torproject.org/pipermail/tor-relays/2014-April/004259.html
- * Proposal 230: How to change RSA1024 identity keys https://lists.torproject.org/pipermail/tor-dev/2014-April/006658.html
+Roger Dingledine prompted relay operators to get new identity keys,
+“especially from the big relays, and we'll be happier tolerating a
+couple of bumpy days while the network recovers.” [XXX]. Switching
+to a new relay identity key means that the relay is seen as new [XXX] to
+the authorities again: they will loose their Guard status and bandwidth
+measurement. It seems that a number of operators followed the advice,
+as the network lost around 1 Gbit/s of advertised capacity between April
+7th and April 10th [XXX].
+
+For a brighter future if such massive RSA1024 relay key migration was in
+order, Nick Mathewson wrote proposal 230 [XXX]. The proposal describes a
+mechanism for relays to advertise their old identity to directory
+authorities and clients.
+
+Directory authorities can currently tie relay's nickname to its identity
+key with the Named flag. That feature proven to be less helpful than
+it seemed and can subject its users to impersonation attacks. As relays
+switch to new identity key, those who keep the same name will loose
+their Named flag for the next six months. So now seems a good time to
+“throw out the Named and Unnamed flags entirely” [XXX]. Sebsatian
+Hahn acted on the idea and started a draft proposal [XXX].
+
+How should potentially compromised relays which have not switched to a
+new key be handled? On April 8th, grarpamp observed [XXX] that more than
+3000 relays had been restarted — hopefully to use the fixed version of
+OpenSSL. It is unknown how many of those relays have switched to a new
+key since. Andrea Shepard has been working on a survey [XXX] to identify
+them. What is known though are relays that are unfortunately still
+vulnerable. Sina Rabbani has set up a visible list for guards and
+exits [XXX]. To protect Tor users, directory authority operators
+have started to remove the Valid flag for vulnerable relays (XXX --
+Roger owes a mail about this).
+
dirauths
* Implications of openssl bug on directory authorities https://lists.torproject.org/pipermail/tor-dev/2014-April/006663.html
* Proposal 231: Migrating authority RSA1024 identity keys https://lists.torproject.org/pipermail/tor-dev/2014-April/006660.html
-throwing out Named and Unnamed
-https://lists.torproject.org/pipermail/tor-relays/2014-April/004254.html
- * Proposal idea: Stop assigning (and eventually supporting) the Named flag https://lists.torproject.org/pipermail/tor-dev/2014-April/006671.html
-
hidden services are changing names…
https://twitter.com/freenodestaff/status/455425032203022337
XXXXXXXXX will continue later — Lunar
+
+As Roger summarized it: “fun times”.
+
+ [XXX]: https://gitweb.torproject.org/torspec.git
+ [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004256.html
+ [XXX]: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
+ [XXX]: https://metrics.torproject.org/network.html?graph=bandwidth&start=2014-04-01&end=2014-04-15#bandwidth
+ [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004259.html
+ [XXX]: https://encrypted.redteam.net/bleeding_edges/
+ [XXX]: http://charon.persephoneslair.org/~andrea/private/tor-heartbleed-survey/
+ [XXX]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/230-rsa1024-relay-id-migration.txt
+ [XXX]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004254.html
+ [XXX]: https://lists.torproject.org/pipermail/tor-dev/2014-April/006671.html
Monthly status reports for March 2014
-------------------------------------
--
Your friendly TWN monitoring script
In case of malfunction, please reach out for lunar at torproject.org
or for the worst cases, tell weasel at torproject.org to kill me.
More information about the news-team
mailing list