| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Those used to be normal to receive on hidden service circuits due to bug
1038, but the buggy Tor versions are long gone from the network so we
can afford to resume watching for them. Resolves the rest of bug 1038;
bugfix on 0.2.1.19.
|
|
|
|
Roger spotted this on tor-dev in his comments on proposal 221.
(Actually, detect DESTROY vs everything else, since arma likes
network timeout indicating failure but not overload indicating failure.)
|
|
This makes FastFirstHopPK an AUTOBOOL; makes the default "auto"; and
makes the behavior of "auto" be "look at the consensus."
|
|
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
|
|
|
|
When specified, it overrides our default of 3 entry guards.
(By default, it overrides the number of directory guards too.)
Implements ticket 12688.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(See discussion on #9553)
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Now it only has dannenberg
|
|
Conflicts:
src/or/circuituse.c
|
|
Fixes bug 11519, apparently bugfix on 0.2.3.11-alpha.
|
|
Conflicts:
src/or/routerlist.h
|
|
|
|
I used a list of certificate files from arma, and a little script,
both at 11464.
|
|
(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.
|
|
|
