mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 22:03:31 +01:00
fold in changes entries
This commit is contained in:
parent
2dec6597af
commit
0eaebebffa
27
ChangeLog
27
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:
|
o Major features:
|
||||||
- Implement a new handshake protocol (v3) for authenticating Tors to
|
- Implement a new handshake protocol (v3) for authenticating Tors to
|
||||||
each other over TLS. It should be more resistant to fingerprinting
|
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
|
- Allow variable-length padding cells to disguise the length of
|
||||||
Tor's TLS records. Implements part of proposal 184.
|
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):
|
o Major bugfixes (hidden services):
|
||||||
- Improve hidden service robustness: when an attempt to connect to
|
- Improve hidden service robustness: when an attempt to connect to
|
||||||
a hidden service ends, be willing to refetch its hidden service
|
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.
|
found by Sebastian Hahn. Bugfix on 0.2.1.13-alpha; fixes bug 4212.
|
||||||
|
|
||||||
o Major bugfixes (other):
|
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
|
- Don't update the AccountingSoftLimitHitAt state file entry whenever
|
||||||
tor gets started. This prevents a wrong average bandwidth
|
tor gets started. This prevents a wrong average bandwidth
|
||||||
estimate, which would cause relays to always start a new accounting
|
estimate, which would cause relays to always start a new accounting
|
||||||
|
@ -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.
|
|
||||||
|
|
@ -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.
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user