- postpone initial sleep until the first getdata is received
- also sleep when received a getdata request for an object that hasn't
been advertised to the other node yet
There was a report that by quickly asking a large number of nodes if
they have an ACK object (which the attacker knows but it is injected
into the network by the recipient of the message), it can estimate how
an object propagates through the network, and eventually pinpoint an
originating IP address of the injection, i.e. the IP address of the
message recipient.
This patch mitigates against it by stalling when asked for a nonexisting
object (so that the attacker can't spam requests), and also upon
connection before sending its own inventory list (so that reconnecting
won't help the attacker). It estimates how long a short message takes to
propagate through the network based on how many nodes are in a stream
and bases the stalling time on that. Currently that is about 15 seconds.
Initial connection delay takes into account the time that already passed
since the connection was established.
This basically gives the attacker one shot per a combination of his own
nodes and the nodes he can connect to, and thus makes the attack much
more difficult to succeed.
When advertising nodes and when establishing connections, private IP
range checks were not done. This could cause private IPs to be
advertised across the network. Also, some of the checks weren't
IPv6-aware.
Fixes Bitmessage#768
Flood mitigation was done both in the ObjectProcessorQueue as well as
receiveData threads. This patch removes the mitigation in receiveData
threads and cleans up the one in the ObjectProcessorQueue
Fixes#118
- changed almost all "print" into logger
- threads have nicer names
- logger can have configuration in "logger.dat" in the same directory as
"keys.dat", and the logger will pick the one named "default" to replace
the "console" and "file" that are in PyBitmessage otherwise
Example file for logging to syslog:
[loggers]
keys = root,syslog
[logger_root]
level=NOTSET
handlers=syslog
[logger_syslog]
level=DEBUG
handlers=syslog
qualname=default
[handlers]
keys = syslog
[handler_syslog]
class = handlers.SysLogHandler
formatter = syslog
level = DEBUG
args=(('localhost', handlers.SYSLOG_UDP_PORT),
handlers.SysLogHandler.LOG_LOCAL7)
[formatters]
keys = syslog
[formatter_syslog]
format=%(asctime)s %(threadName)s %(filename)s@%(lineno)d %(message)s
datefmt=%b %d %H:%M:%S
Python < 2.7.9 does not support anonymous SSL server through
ssl.wrap_socket, so we have to disable it. Works fine as client.
Try to prefer secp256k1 curve (again, requires python >= 2.7.9)
Bitmessage will now notify you if it encounters someone with a newer
version. Takes into account that it should not recommend switching from
stable to unstable and vice versa. Also, temporarily treats 0.5 as a
mailchuck fork.
Fixes#43
Demote payloadLength from class instance variable to processData local variable as no other function was using it
Improve processData:
-Utilise shared.Header
-Use a memoryview to reduce memory overhead
-Clean up variables before a recursive call
-Strip null bytes from command
Refactor sendData
Various functions:
-Use shared.CreatePacket to generate packets
Fix typo in _checkIPv4Address
It will now listen on an IPv6 socket if possible or fall back to IPv4
if that doesn't work. It will no longer filter out all IPv6 addresses
and instead it will only filter out those that point to the local
network.
It looks like the DNS bootstrapping should just automatically work
because getaddrinfo already returns IPv6 addresses from the AAAA
record.
In order to convert from the ASCII representation of IPv6 addresses
and back we need inet_ntop and inet_pton. Python 2 doesn't currently
provide these for Windows so instead this patch provides a hot patch
to the socket module which wraps WSAStringToAddress and
WSAAddressToString using ctypes.
If this option is specified in keys.dat then Bitmessage will connect
to the host specified there instead of connecting to the hosts in the
list of known nodes. It will also stop listening for incoming
connections and the timing attack mitigation will be disabled.
The expected use case is for example where a user is running a daemon
on a dedicated machine in their local network and they occasionally
want to check for messages using a second instance of the client on
their laptop. In that case it would be much faster to catch up with
the messages by directly downloading from the dedicated machine over
the LAN. There is no need to connect to multiple peers or to do the
timing attack mitigation because the daemon is trusted.
The host is specified as hostname:port. Eg, ‘192.168.1.8:8444’.
Until now many parts of the code assumed that IP addresses are
unique for peers. However, more than one Bitmessage instance might
be running with a given IP address due to multi-user systems or
firewalls.
This allows other clients to insert headers in extra lines of text between
the Subject and Body fields of the message, as discussed on the 24x7 mailing
list. The PyBitmessage client was never able to meaningfully display
multi-line subjects, so this does not break anything. The extra lines are
thrown away and never stored anywhere, so this also protects against
watermarking attacks.
As per http://docs.python.org/2/howto/sockets.html#using-a-socket it's
possible that a socket recv() call returns 0 bytes if the remote closes
the connection. In that case, recv() does not obey settimeout(): it
just doesn't block and returns zero bytes immediately, which in this
case results in an infinite loop if the transmission was incomplete.
