[tor-commits] [tor/master] fold in changes entries

[arma@xxxxxxxxxxxxxx]

commit 0eaebebffa4cb8e445e249db0bf6942e1a93bdee
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
Date:   Wed Oct 26 20:31:49 2011 -0400

    fold in changes entries
---
 ChangeLog                 |   27 ++++++++++++++++++++++++++-
 changes/issue-2011-10-19L |   28 ----------------------------
 changes/issue-2011-10-23G |    9 ---------
 3 files changed, 26 insertions(+), 38 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 18505dd..355948c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,4 +1,4 @@
-Changes in version 0.2.3.6-alpha - 2011-10-??
+Changes in version 0.2.3.6-alpha - 2011-10-26
   o Major features:
     - Implement a new handshake protocol (v3) for authenticating Tors to
       each other over TLS. It should be more resistant to fingerprinting
@@ -7,6 +7,26 @@ Changes in version 0.2.3.6-alpha - 2011-10-??
     - Allow variable-length padding cells to disguise the length of
       Tor's TLS records. Implements part of proposal 184.
 
+  o Privacy/anonymity fixes (clients):
+    - Clients and bridges no longer send TLS certificate chains on
+      outgoing OR connections. Previously, each client or bridge
+      would use the same cert chain for all outgoing OR connections
+      for up to 24 hours, which allowed any relay that the client or
+      bridge contacted to determine which entry guards it is using.
+      Fixes CVE-2011-2768. Bugfix on 0.0.9pre5; found by "frosty_un".
+    - If a relay receives a CREATE_FAST cell on a TLS connection, it
+      no longer considers that connection as suitable for satisfying a
+      circuit EXTEND request. Now relays can protect clients from the
+      CVE-2011-2768 issue even if the clients haven't upgraded yet.
+    - Directory authorities no longer assign the Guard flag to relays
+      that haven't upgraded to the above "refuse EXTEND requests
+      to client connections" fix. Now directory authorities can
+      protect clients from the CVE-2011-2768 issue even if neither
+      the clients nor the relays have upgraded yet. There's a new
+      "GiveGuardFlagTo_CVE_2011_2768_VulnerableRelays" config option
+      to let us transition smoothly, else tomorrow there would be no
+      guard relays.
+
   o Major bugfixes (hidden services):
     - Improve hidden service robustness: when an attempt to connect to
       a hidden service ends, be willing to refetch its hidden service
@@ -29,6 +49,11 @@ Changes in version 0.2.3.6-alpha - 2011-10-??
       found by Sebastian Hahn. Bugfix on 0.2.1.13-alpha; fixes bug 4212.
 
   o Major bugfixes (other):
+    - Bridges now refuse CREATE or CREATE_FAST cells on OR connections
+      that they initiated. Relays could distinguish incoming bridge
+      connections from client connections, creating another avenue for
+      enumerating bridges. Fixes CVE-2011-2769. Bugfix on 0.2.0.3-alpha.
+      Found by "frosty_un".
     - Don't update the AccountingSoftLimitHitAt state file entry whenever
       tor gets started. This prevents a wrong average bandwidth
       estimate, which would cause relays to always start a new accounting
diff --git a/changes/issue-2011-10-19L b/changes/issue-2011-10-19L
deleted file mode 100644
index b879c9d..0000000
--- a/changes/issue-2011-10-19L
+++ /dev/null
@@ -1,28 +0,0 @@
-  o Security fixes:
-
-    - Don't send TLS certificate chains on outgoing OR connections
-      from clients and bridges.  Previously, each client or bridge
-      would use a single cert chain for all outgoing OR connections
-      for up to 24 hours, which allowed any relay connected to by a
-      client or bridge to determine which entry guards it is using.
-      This is a potential user-tracing bug for *all* users; everyone
-      who uses Tor's client or hidden service functionality should
-      upgrade.  Fixes CVE-2011-2768.  Bugfix on FIXME; found by
-      frosty_un.
-
-    - Don't use any OR connection on which we have received a
-      CREATE_FAST cell to satisfy an EXTEND request.  Previously, we
-      would not consider whether a connection appears to be from a
-      client or bridge when deciding whether to use that connection to
-      satisfy an EXTEND request.  Mitigates CVE-2011-2768, by
-      preventing an attacker from determining whether an unpatched
-      client is connected to a patched relay.  Bugfix on FIXME; found
-      by frosty_un.
-
-    - Don't assign the Guard flag to relays running a version of Tor
-      which would use an OR connection on which it has received a
-      CREATE_FAST cell to satisfy an EXTEND request.  Mitigates
-      CVE-2011-2768, by ensuring that clients will not connect
-      directly to any relay which an attacker could probe for an
-      unpatched client's connections.
-
diff --git a/changes/issue-2011-10-23G b/changes/issue-2011-10-23G
deleted file mode 100644
index 45f8675..0000000
--- a/changes/issue-2011-10-23G
+++ /dev/null
@@ -1,9 +0,0 @@
-  o Security fixes:
-
-    - Reject CREATE and CREATE_FAST cells on outgoing OR connections
-      from a bridge to a relay.  Previously, we would accept them and
-      handle them normally, thereby allowing a malicious relay to
-      easily distinguish bridges which connect to it from clients.
-      Fixes CVE-2011-2769.  Bugfix on 0.2.0.3-alpha, when bridges were
-      implemented; found by frosty_un.
-



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits