This is a feature removal: we no longer fake any ciphersuite other
than the not-really-standard SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
(0xfeff). This change will let servers rely on our actually
supporting what we claim to support, and thereby let Tor migrate to
better TLS ciphersuites.
As a drawback, Tor instances that use old openssl versions and
openssl builds with ciphers disabled will no longer give the
"firefox" cipher list.
The function is not guaranteed to NUL-terminate its output. It
*is*, however, guaranteed not to generate more than two bytes per
multibyte character (plus terminating nul), so the general approach
I'm taking is to try to allocate enough space, AND to manually add a
NUL at the end of each buffer just in case I screwed up the "enough
space" thing.
Fixes bug 5909.
These include:
- Having a weird in_addr that can't be initialized with {0}
- Needing INVALID_HANDLE_VALUE instead of -1 for file handles.
- Having a weird dependent definition for struct stat.
- pid is signed, not unsigned.
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
It appears that when OpenSSL negotiates a 1.1 or 1.2 connection, and it
decides to renegotiate, the client will send a record with version "1.0"
rather than with the current TLS version. This would cause the
connection to fail whenever both sides had OpenSSL 1.0.1, and the v2 Tor
handshake was in use.
As a workaround, disable TLS 1.1 and TLS 1.2. When a later version of
OpenSSL is released, we can make this conditional on running a fixed
version of OpenSSL.
Alternatively, we could disable TLS 1.1 and TLS 1.2 only on the client
side. But doing it this way for now means that we not only fix TLS with
patched clients; we also fix TLS when the server has this patch and the
client does not. That could be important to keep the network running
well.
Fixes bug 6033.
Conflicts:
src/test/test_util.c
Merge the unit tests; I added some when I did this branch against
0.2.2, and then the test format changed and master added more tests.
Conflicts:
src/common/compat.h
Conflict was between replacement of MS_WINDOWS with _WIN32 in
master, and with removal of file_handle from tor_mmap_t struct in
close_file_mapping branch (for bug 5951 fix).
It turns out that if you set the third argument of
__attribute__(format) to 0, GCC and Clang will check the format
argument without expecting to find variadic arguments. This is the
correct behavior for vsnprintf, vasprintf, and vscanf.
I'm hoping this will fix bug 5969 (a clang warning) by telling clang that
the format argument to tor_vasprintf is indeed a format string.
The parent of "/foo" is "/"; and "/" is its own parent.
This would cause Tor to fail if you tried to have a PF_UNIX control
socket in the root directory. That would be a stupid thing to do
for other reasons, but there's no reason to fail like _this_.
Bug found by Esteban Manchado Velázquez. Fix for bug 5089; bugfix on
Tor 0.2.2.26-beta. Unit test included.
* It seems parse_http_time wasn't parsing correctly any date with commas (RFCs
1123 and 850). Fix that.
* It seems parse_http_time was reporting the wrong month (they start at 0, not
1). Fix that.
* Add some tests for parse_http_time, covering all three formats.
We've been only treating SW_SERVER_HELLO_A as meaning that an SSL
handshake was happening. But that's not right: if the initial
attempt to write a ServerHello fails, we would get a callback in
state SW_SERVER_HELLO_B instead.
(That's "instead" and not "in addition": any failed attempt to write
the hello will fail and cause the info callback not to get written.)
Fix for bug 4592; bugfix on 0.2.0.13-alpha.
This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.
See bug #5861. We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.
For uname-based detection, we now give only the OS name (e.g.,
"Darwin", "Linux".) For Windows, we give only the Operating System
name as inferred from dw(Major|Minor)version, (e.g., "Windows XP",
"Windows 7"), and whether the VER_NT_SERVER flag is set.
For ticket 2988.