Commit graph

13 commits

Author SHA1 Message Date
xiphon
23ba69ec88 epee: fix SSL server handshake, run_one() can block, use poll_one() 2019-10-18 18:32:33 +00:00
xiphon
4371791977 epee: implement handshake timeout for SSL connections 2019-09-17 22:21:16 +00:00
moneromooo-monero
a62e072571
net_ssl: SSL config tweaks for compatibility and security
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.
2019-05-07 10:01:42 +00:00
moneromooo-monero
5e0da6fb68
change SSL certificate fingerprint whitelisting from SHA1 to SHA-256
SHA1 is too close to bruteforceable
2019-04-26 11:37:15 +00:00
Lee Clagett
2e578b8214 Enabling daemon-rpc SSL now requires non-system CA verification
If `--daemon-ssl enabled` is set in the wallet, then a user certificate,
fingerprint, or onion/i2p address must be provided.
2019-04-07 13:02:43 -04:00
Lee Clagett
d58f368289 Require manual override for user chain certificates.
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.
2019-04-07 00:44:37 -04:00
Lee Clagett
eca0fea45a Perform RFC 2818 hostname verification in client SSL handshakes
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.
2019-04-07 00:44:37 -04:00
Lee Clagett
0416764cae Require server verification when SSL is enabled.
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.
2019-04-07 00:44:37 -04:00
Lee Clagett
21eb1b0725 Pass SSL arguments via one class and use shared_ptr instead of reference 2019-04-07 00:44:37 -04:00
Lee Clagett
a3b0284837 Change SSL certificate file list to OpenSSL builtin load_verify_location
Specifying SSL certificates for peer verification does an exact match,
making it a not-so-obvious alias for the fingerprints option. This
changes the checks to OpenSSL which loads concatenated certificate(s)
from a single file and does a certificate-authority (chain of trust)
check instead. There is no drop in security - a compromised exact match
fingerprint has the same worse case failure. There is increased security
in allowing separate long-term CA key and short-term SSL server keys.

This also removes loading of the system-default CA files if a custom
CA file or certificate fingerprint is specified.
2019-04-06 23:47:06 -04:00
Howard Chu
b8c2e21cba
Fix startup errors with SSL cert generation
Use SSL API directly, skip boost layer
2019-03-08 15:15:24 +00:00
Martijn Otto
057c279cb4
epee: add SSL support
RPC connections now have optional tranparent SSL.

An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.

SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.

Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.

To generate long term certificates:

openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT

/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.

SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
2019-03-05 14:16:08 +01:00
moneromooo-monero
2456945408
epee: add SSL support
RPC connections now have optional tranparent SSL.

An optional private key and certificate file can be passed,
using the --{rpc,daemon}-ssl-private-key and
--{rpc,daemon}-ssl-certificate options. Those have as
argument a path to a PEM format private private key and
certificate, respectively.
If not given, a temporary self signed certificate will be used.

SSL can be enabled or disabled using --{rpc}-ssl, which
accepts autodetect (default), disabled or enabled.

Access can be restricted to particular certificates using the
--rpc-ssl-allowed-certificates, which takes a list of
paths to PEM encoded certificates. This can allow a wallet to
connect to only the daemon they think they're connected to,
by forcing SSL and listing the paths to the known good
certificates.

To generate long term certificates:

openssl genrsa -out /tmp/KEY 4096
openssl req -new -key /tmp/KEY -out /tmp/REQ
openssl x509 -req -days 999999 -sha256 -in /tmp/REQ -signkey /tmp/KEY -out /tmp/CERT

/tmp/KEY is the private key, and /tmp/CERT is the certificate,
both in PEM format. /tmp/REQ can be removed. Adjust the last
command to set expiration date, etc, as needed. It doesn't
make a whole lot of sense for monero anyway, since most servers
will run with one time temporary self signed certificates anyway.

SSL support is transparent, so all communication is done on the
existing ports, with SSL autodetection. This means you can start
using an SSL daemon now, but you should not enforce SSL yet or
nothing will talk to you.
2019-02-02 20:05:33 +00:00