The warning message of validate_pluggable_transports_config() is
superseded by the changes in the warning message of
connection_or_connect() when the proxy credentials can't be found.
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.
Manually removed range 0.116.0.0 to 0.119.255.255 which Maxmind says is
assigned to AT. This is very likely a bug in their database, because
0.0.0.0/8 is a reserved range.
From what I can tell, this configuration is usually a mistake, and
leads people to think that all their traffic is getting proxied when
in fact practically none of it is. Resolves the issue behind "bug"
4663.
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.
This feature can make Tor relays less identifiable by their use of the
mod_ssl DH group, but at the cost of some usability (#4721) and bridge
tracing (#6087) regressions.
We should try to turn this on by default again if we find that the
mod_ssl group is uncommon and/or we move to a different DH group size
(see #6088). Before we can do so, we need a fix for bugs #6087 and
Resolves ticket #5598 for now.
These stats are currently discarded, but we might as well
hard-disable them on bridges, to be clean.
Fix for bug 5824; bugfix on 0.2.1.17-rc.
Patch originally by Karsten Loesing.
This code shouldn't have any effect in 0.2.3, since we already accept
(and handle) data received while we are expecting a renegotiation.
(That's because the 0.2.3.x handshake _does_ have data there instead of
the renegotiation.)
I'm leaving it in anyway, since if it breaks anything, we'll want it
broken in master too so we can find out about it. I added an XXX023
comment so that we can come back later and fix that.
This fixes a DoS issue where a client could send so much data in 5
minutes that they exhausted the server's RAM. Fix for bug 5934 and
6007. Bugfix on 0.2.0.20-rc, which enabled the v2 handshake.
