Nick Mathewson [Tue, 10 Jun 2014 15:11:47 +0000 (11:11 -0400)]
Avoid illegal read off end of an array in prune_v2_cipher_list
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.
Nick Mathewson [Sat, 26 Apr 2014 16:45:34 +0000 (12:45 -0400)]
Stop leaking memory in error cases of md parsing
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.
Nick Mathewson [Thu, 17 Apr 2014 14:23:18 +0000 (10:23 -0400)]
Elevate server TLS cipher preferences over client
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.
Nick Mathewson [Mon, 14 Apr 2014 18:10:05 +0000 (14:10 -0400)]
New sort order for server choice of ciphersuites.
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.
Nick Mathewson [Tue, 8 Apr 2014 15:31:48 +0000 (11:31 -0400)]
Update ciphers.inc to match ff28
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.
Nick Mathewson [Mon, 10 Mar 2014 19:01:27 +0000 (15:01 -0400)]
Update ns downloads when we receive a bridge descriptor
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.
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.
"""
Sebastian Hahn [Thu, 13 Feb 2014 07:25:08 +0000 (08:25 +0100)]
gcc/clang: Mark macro-generated functions as possible unused
clang 3.4 introduced a new by-default warning about unused static
functions, which we triggered heavily for the hashtable and map function
generating macros. We can use __attribute__ ((unused)) (thanks nickm for
the suggestion :-) ) to silence these warnings.
There is no WSAEPERM; we were implying that there was.This fixes a
bug in e0c8031516852143fb82d8fee91a0f4c576c7418, which hadn't yet
appeared in any released Tor.
Nick Mathewson [Fri, 7 Feb 2014 22:36:11 +0000 (17:36 -0500)]
Survive fedora's openssl in our benchmarks
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.
Nick Mathewson [Thu, 6 Feb 2014 22:08:50 +0000 (17:08 -0500)]
Discard circuit paths on which nobody supports ntor
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.
Nick Mathewson [Sat, 21 Dec 2013 15:15:09 +0000 (10:15 -0500)]
Fix a logic error in circuit_stream_is_being_handled.
When I introduced the unusable_for_new_circuits flag in 62fb209d837f3f551, I had a spurious ! in the
circuit_stream_is_being_handled loop. This made us decide that
non-unusable circuits (that is, usable ones) were the ones to avoid,
and caused it to launch a bunch of extra circuits.
Nick Mathewson [Wed, 18 Dec 2013 16:49:44 +0000 (11:49 -0500)]
Never allow OpenSSL engines to replace the RAND_SSLeay method
This fixes bug 10402, where the rdrand engine would use the rdrand
instruction, not as an additional entropy source, but as a replacement
for the entire userspace PRNG. That's obviously stupid: even if you
don't think that RDRAND is a likely security risk, the right response
to an alleged new alleged entropy source is never to throw away all
previously used entropy sources.
Thanks to coderman and rl1987 for diagnosing and tracking this down.
projects / thirdparty / tor.git / log
