| Age | Commit message (Collapse) | Author |
|---|
|
fixes bug 8387; fix on 0.1.1.11-alpha (code), or on 0.2.4.10-alpha (behavior).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/or/microdesc.c
|
|
The 0.2.5.x warning is the one that might help us track this down; the
warnings in stable are just annoying users over and over and over.
|
|
|
|
|
|
on #9686, gmorehose reports that the 500 MB lower limit is too high
for raspberry pi users.
This is a backport of 647248729fa65f0e51d062e2af8f4e8b38592bf5 to 0.2.4.
Note that in 0.2.4, the option is called MaxMemInCellQueues.
|
|
|
|
When clearing a list of tokens, it's important to do token_clear()
on them first, or else any keys they contain will leak. This didn't
leak memory on any of the successful microdescriptor parsing paths,
but it does leak on some failing paths when the failure happens
during tokenization.
Fixes bug 11618; bugfix on 0.2.2.6-alpha.
|
|
Fixes bug 10849; bugfix on 0.2.1.1-alpha (I believe)
|
|
|
|
Fixes the surface behavior of #11553
|
|
The server cipher list is (thanks to #11513) chosen systematically to
put the best choices for Tor first. The client cipher list is chosen
to resemble a browser. So let's set SSL_OP_CIPHER_SERVER_PREFERENCE
to have the servers pick according to their own preference order.
|
|
Conflicts:
src/or/circuituse.c
|
|
Fixes bug 11519, apparently bugfix on 0.2.3.11-alpha.
|
|
Conflicts:
src/or/routerlist.h
|
|
|
|
(I need a list of actual signing keys to blacklist.)
|
|
Back in 175b2678, we allowed servers to recognize clients who are
telling them the truth about their ciphersuites, and select the best
cipher from on that list. This implemented the server side of proposal
198.
In bugs 11492, 11498, and 11499, cypherpunks found a bunch of mistakes
and omissions and typos in the UNRESTRICTED_SERVER_CIPHER_LIST we had.
In #11513, I found a couple more.
Rather than try to hand-edit this list, I wrote a short python script
to generate our ciphersuite preferences from the openssl headers.
The new rules are:
* Require forward secrecy.
* Require RSA (since our servers only configure RSA keys)
* Require AES or 3DES. (This means, reject RC4, DES, SEED, CAMELLIA,
and NULL.)
* No export ciphersuites.
Then:
* Prefer AES to 3DES.
* If both suites have the same cipher, prefer ECDHE to DHE.
* If both suites have the same DHE group type, prefer GCM to CBC.
* If both suites have the same cipher mode, prefer SHA384 to SHA256
to SHA1.
* If both suites have the same digest, prefer AES256 to AES128.
|
|
The major changes are to re-order some ciphers, to drop the ECDH suites
(note: *not* ECDHE: ECDHE is still there), to kill off some made-up
stuff (like the SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA suite), to drop
some of the DSS suites... *and* to enable the ECDHE+GCM ciphersuites.
This change is autogenerated by get_mozilla_ciphers.py from
Firefox 28 and OpenSSL 1.0.1g.
Resolves ticket 11438.
|
|
Fixes bug 11437; bugfix on 0.2.4.7-alpha.
Found by coverity; this is CID 1198198.
|
|
We are searching @CONFDIR@ before $HOME, but the documentation
implied otherwise.
I screwed this up in f5e86bcd6c06d43ff3af5acd8135bd8b577bc3, when I
first documented the $HOME/.torrc possibility.
Fix for bug 9213; bugfix on 0.2.3.18-rc.
|
|
This is a fix for 9700, which we already fixed in 0.2.5.x, but which
got left in 0.2.4.x.
This is a partial backport of a0a855d586d99540277014ccd3
|
|
This prevents long stalls when we're starting with a state file but
with no bridge descriptors. Fixes bug 9229. I believe this bug has
been present since 0.2.0.3-alpha.
|
|
This is a fix for 9393; it's not a bugfix on any Tor version per se,
but rather on whatever Tor version was current when we reorganized the
wiki.
|
|
|
|
|
|
See 1d2179bc900f1646a5491b65294e78b175e70056 in master for details.
"""
Fall back to registered country if necessary.
When extracting geoip and geoip6 files from MaxMind's GeoLite2 Country
database, we only look at country->iso_code which is the two-character ISO
3166-1 country code of the country where MaxMind believes the end user is
located.
But if MaxMind thinks a range belongs to anonymous proxies, they don't put
anything there. Hence, we omit those ranges and resolve them all to '??'.
That's not what we want.
What we should do is first try country->iso_code, and if there's no such
key, try registered_country->iso_code which is the country in which the
ISP has registered the IP address.
In short: let's fill all A1 entries with what ARIN et. al think.
"""
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's now redundant with the inserted_time field in packed_cell_t
Fixes bug 10870.
|
|
It can happen because we sent something that got an ENETUNREACH
response.
Bugfix on 0.2.4.8-alpha; fixes a part of bug 10777.
|
|
Found by cypherpunks; fix for a part of bug 10777; bugfix on 0.1.0.1-rc.
|
|
|
|
Apparently fedora currently has ECDH but not P224. This isn't a huge
deal, since we no longer use OpenSSL's P224 ever (see #9780 and
72c1e5acfe1c6). But we shouldn't have segfaulting benchmarks really.
Fixes bug 10835; bugfix on 0.2.4.8-alpha.
|
|
Right now this accounts for about 1% of circuits over all, but if you
pick a guard that's running 0.2.3, it will be about 6% of the circuits
running through that guard.
Making sure that every circuit has at least one ntor link means that
we're getting plausibly good forward secrecy on every circuit.
This implements ticket 9777,
|
|
|
|
late; fixes bug 9602
|
