fcbf7b3 p2p: propagate out peers limit to payload handler (moneromooo-monero)
098aadf p2p: close the right number of connections on setting max in/out peers (moneromooo-monero)
new cli options (RPC ones also apply to wallet):
--p2p-bind-ipv6-address (default = "::")
--p2p-bind-port-ipv6 (default same as ipv4 port for given nettype)
--rpc-bind-ipv6-address (default = "::1")
--p2p-use-ipv6 (default false)
--rpc-use-ipv6 (default false)
--p2p-require-ipv4 (default true, if ipv4 bind fails and this is
true, will not continue even if ipv6 bind
successful)
--rpc-require-ipv4 (default true, description as above)
ipv6 addresses are to be specified as "[xx:xx:xx::xx:xx]:port" except
in the cases of the cli args for bind address. For those the square
braces can be omitted.
add two RSA based ciphers for Windows/depends compatibility
also enforce server cipher ordering
also set ECDH to auto because vtnerd says it is good :)
When built with the depends system, openssl does not include any
cipher on the current whitelist, so add this one, which fixes the
problem, and does seem sensible.
It can allocate a lot when getting a lot of connections
(in particular, the stress test on windows apparently pushes
that memory to actual use, rather than just allocated)
When closing connections due to exiting, the IO service is
already gone, so the data exchange needed for a gracious SSL
shutdown cannot happen. We just close the socket in that case.
An override for the wallet to daemon connection is provided, but not for
other SSL contexts. The intent is to prevent users from supplying a
system CA as the "user" whitelisted certificate, which is less secure
since the key is controlled by a third party.
This allows "chain" certificates to be used with the fingerprint
whitelist option. A user can get a system-ca signature as backup while
clients explicitly whitelist the server certificate. The user specified
CA can also be combined with fingerprint whitelisting.
The former has the same behavior with single self signed certificates
while allowing the server to have separate short-term authentication
keys with long-term authorization keys.
If the verification mode is `system_ca`, clients will now do hostname
verification. Thus, only certificates from expected hostnames are
allowed when SSL is enabled. This can be overridden by forcible setting
the SSL mode to autodetect.
Clients will also send the hostname even when `system_ca` is not being
performed. This leaks possible metadata, but allows servers providing
multiple hostnames to respond with the correct certificate. One example
is cloudflare, which getmonero.org is currently using.
If SSL is "enabled" via command line without specifying a fingerprint or
certificate, the system CA list is checked for server verification and
_now_ fails the handshake if that check fails. This change was made to
remain consistent with standard SSL/TLS client behavior. This can still
be overridden by using the allow any certificate flag.
If the SSL behavior is autodetect, the system CA list is still checked
but a warning is logged if this fails. The stream is not rejected
because a re-connect will be attempted - its better to have an
unverified encrypted stream than an unverified + unencrypted stream.
Using `verify_peer` on server side requests a certificate from the
client. If no certificate is provided, the server silently accepts the
connection and rejects if the client sends an unexpected certificate.
Adding `verify_fail_if_no_cert` has no affect on client and for server
requires that the peer sends a certificate or fails the handshake. This
is the desired behavior when the user specifies a fingerprint or CA file.
Currently a client must provide a certificate, even if the server is
configured to allow all certificates. This drops that requirement from
the client - unless the server is configured to use a CA file or
fingerprint(s) for verification - which is the standard behavior for SSL
servers.
The "system-wide" CA is not being used as a "fallback" to verify clients
before or after this patch.
luigi1111